Programmers with network engineering skills

Mon Mar 5 17:53:34 UTC 2012

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
>

-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------