Programmers with network engineering skills

Mon Mar 5 19:27:05 UTC 2012

Scott, I fully agree with you. In fact, I was just commenting on *my*
experiences and never implied that they would / should apply the same
for everyone.

cheers!

Carlos

On 3/5/12 3:53 PM, Scott Helms wrote:
> I've played on both sides of the fence of this one, but I think the
> key piece is that you have to get enough software engineering for your
> tool to fit the life cycle it needs to follow and enough domain
> specific knowledge to for the tool to do what it exists to do.  If you
> lack *either* of those you're going to suffer either through a tool
> that doesn't do what its supposed to or a tool that does everything it
> should right *now* but can't be efficiently expanded when the project
> scope suddenly expands.  The real challenge is understanding what the
> scope of your project is and what it will likely be in ~4 years.  If
> its not going to change much then the need for professional software
> engineering methodologies & practices is much lower than if you're
> going to have to add new features each quarter.  Your target audience
> also has a big impact on what you need to do.  Most internal projects
> have little need for a professional UI designer, but if you have a
> project that's going to touch thousands of people using a range of
> PC's and other devices you had better spend a lot of time on UI.
>
> tl;dr I don't think there is a *right* answer to be found because it
> depends on the project.
>
>
> BTW, just replying to Carlos in general not in specific.
>
> On 3/5/2012 11:08 AM, Carlos Martinez-Cagnazzo wrote:
>> Never said it was *perfect*. But you probably haven't a good (in CV
>> terms at least) prorgrammer assigned to you but didn't know the
>> difference between a TCP port and an IP protocol number. Or the
>> difference between an Ethernet and an IP address.
>>
>> For me at least (and I grant you that everyone's mileage may vary), it
>> has been a lot easier to teach networkers to program than the other way
>> around.
>>
>> I remember (not very fondly) the time when I was assigned to the team
>> which was going to write a DNS provisioning system, which was going to
>> be used by clients to get x.tld domains, and which had to periodically
>> generate the zone.
>>
>> A team of programmers, fully into the maintainability, lifecycle,
>> corporate IT thing was created. They didn't know what a DNS zone was, or
>> a SOA record, or a CNAME record for that matter. The project failed
>> before I could bring the matter of AAAA records up. Several tens of
>> thousands of dollars were spent on a failed project that could have been
>> saved by a different choice of programmers.
>>
>> The same problem was solved some two years later by a team composed
>> mainly of network engineers with one or two corporate IT programmers who
>> were in charge of ensuring lifecycle and integration with business
>> systems.
>>
>> And a programming engineer (even if he/she is by default an
>> electrical/network engineer) is a far cry from a script kiddie. Sorry to
>> differ on that.
>>
>> cheers!
>>
>> Carlos
>>
>> On 3/2/12 8:35 PM, Randy Bush wrote:
>>>> In my experience the path of least resistance is to get a junior
>>>> network engineer and mentor he/she into improving his/hers programming
>>>> skills than go the other way around.
>>> and then the organization pays forever to maintain the crap code while
>>> the kiddie learned to program.  right.  brilliant.
>>>
>>> Always code as if the guy who ends up maintaining your code will be a
>>> violent psychopath who knows where you live. -- Martin Golding
>>>
>>> randy
>>
>
>