[150809] in North American Network Operators' Group
Re: Programmers with network engineering skills
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Mar 5 15:32:54 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4F54FD9E.2020606@ispalliance.net>
Date: Mon, 5 Mar 2012 12:29:36 -0800
To: Scott Helms <khelms@ispalliance.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> tl;dr I don't think there is a *right* answer to be found because it =
depends on the project.
>=20
>=20
> BTW, just replying to Carlos in general not in specific.
>=20
> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> cheers!
>>=20
>> Carlos
>>=20
>> 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.
>>>=20
>>> Always code as if the guy who ends up maintaining your code will be =
a
>>> violent psychopath who knows where you live. -- Martin Golding
>>>=20
>>> randy
>>=20
>=20
>=20
> --=20
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
>=20
