Re: Programmers with network engineering skills

[Carlos Martinez-Cagnazzo <carlosm3011 () gmail com>]

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