Re: Programmers with network engineering skills

[Scott Helms <khelms () ispalliance net>]

Owen,

    I'd say that everyone's PoV on this is going to be experience 
driven.  I've seen both approaches work (and both fail) and IMO the 
determining factor was matching the "right" approach with the project.  
I don't believe that you can develop a large scale project (large scale 
being a team of 12 or more full time developers working for more than a 
year on the same project) with people who primarily want to be network 
engineers.  Its not a matter of skill set so much as it as what 
interests each group and they are very different.

Today I manage network engineers, Unix/Linux System Administrators, and 
Java (and Flex) developers and while there are tasks I can move from one 
group to another there is usually a best home for a specific project.  
Where I usually run into trouble is when I put a project into a 
non-optimal group usually because of deadlines.


On 3/5/2012 3:29 PM, Owen DeLong wrote:
> Given my experience to date with the assumptions made by programers about networking in the following:
>
>         Apps (iOS apps, Droid apps, etc.)
>         Consumer Electronics
>         Microcontrollers
>         Home Routers
>
> I have to say that the strategy being used to date, whichever one it is, is not working. I will also note that the 
> erroneous assumptions, incorrect behaviors, and other problems I have encountered with these items are indicative of 
> coders that almost learned networking more than of networkers that almost learned software development.
>
> Owen
>
> On Mar 5, 2012, at 9:53 AM, 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
> >
> > --
> > Scott Helms
> > Vice President of Technology
> > ISP Alliance, Inc. DBA ZCorum
> > (678) 507-5000
> > --------------------------------
> > http://twitter.com/kscotthelms
> > --------------------------------


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