Programmers with network engineering skills

Mon Mar 5 16:08:39 UTC 2012

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