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