Programmers with network engineering skills

I typically recommend either Intercal, or one of various assembler languages that are out of date (well, not really out of date, but out of date for mainstream computing. My old TRS-80 Z80 assembler skills come in handy when playing around with certain DVD drives' firmware, since a Z80 variant is used in many such drives). Make 'em do something in 6502 that absolutely has to use page zero stuff, or in Z80 where a block instruction would be the best way to accomplish a task. Or maybe handcoded ia64, or MIPS, the 6502's godgrandchildren....

Object shmobject, let me see the bytes!

And if they choose to try it in Intercal, they have to use at least two COME FROM statements. In a 'Hello World' type program (of course, 'Hello World' in Intercal is, well, interesting, and reads like an obfuscated perl contest entry. The point being, if you can make something useful happen in Intercal, you can probably do something useful in a sane language.

The skills I'm looking for are simple: be able to think sideways, and on your feet, with unfamiliar tools if necessary. That is, be a quick study who doesn't cringe at any language, tool, toolkit, or technique that might need to be used.

There's a difference between the TS/SCI clearance - and SCI
compartmentalization security model for secure projects or information
- and whether you need a generalist programmer / network programmer to
solve the problem within the compartment or a specialist.

One can have very generalist problems within a very narrowly defined
security compartment.

One of my main hobbies, if done as a day job, would require TS/SCI
clearance plus an additional level; it requires about 8 or 9 major
scientific and engineering disciplines to master.

John Mitchell wrote:

<rant>

I would wholeheartedly agree with this, but I believe its worse than

teaching process is one of learning to program like a monkey, monkey see monkey do. People are no longer taught to think for themselves, but instead taught to program in a specific language (PHP, Java, rarely C or C++ any more, C#, or VB) and that is all they know. I don't believe this is a failing with the lecturers but with the fundamental change in attitudes to programming.

The story of Mel comes to mind (one of my favourite):

http://www.catb.org/jargon/html/story-of-mel.html
http://www.catb.org/jargon/html/R/Real-Programmer.html

Brainfuck - Wikipedia ) since this gives people a chance to show they can program rather than being able to tell me "I know PHP" or "I know C", suprisingly very few newer programmers can

I think someone being able to quickly understand brainfuck and write usable code in it may be smart, but I don't think it's necessarily a sure sign of a potentially productive employee that "fits well in the team".

Greetings,
Jeroen

I would hope that the working with the team aspect would have been have been handled BEFORE you spend time on this. Let HR do it, then check if they did it right because they screw it up at times. I have been overridden twice in hiring decisions over the years by my boss. Both of them lived to regret that action. Both were unsuitable because the person had character and personality flaws that made them unsuitable for any job except working more than 20 miles from Ted Kaminski.

Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone +1 717.506.0802
FAX +1 717.506.4358
Email Ralph.Brandt@pateam.com
5095 Ritter Rd
Mechanicsburg PA 17055

Jamie Bowden wrote:

Hey now...the time from zero to TS/SCI has gone from over half a decade to a mere quarter decade. You can totally pay these guys to sit around doing drudge work while their skills atrophy in the interim. Of course, if you need a poly on top, add some more time and stir continually while applying heat.

I didn't know what TS/SCI exactly stood for. So I did some thorough research (read: wikipedia, so if I am wrong please correct me :slight_smile: and I found this:

"In general, employees do not publish the individual compartments for which they are cleared. While this information is not classified, specific compartment listings may reveal sensitive information when correlated with an individual's resume. Therefore, it is sufficient to declare that a candidate possesses a TS/SCI clearance with a polygraph."

That sparked my interest. Did I miss something? One can lie about TS/CSI clearance and be believed as long as one can fool a lie detector? How safe is that? That strikes me as a bit odd.

"Polygraphy has little credibility among scientists.[22][23] Despite claims of 90-95% validity by polygraph advocates, and 95-100% by businesses providing polygraph services,[non-primary source needed] critics maintain that rather than a "test", the method amounts to an inherently unstandardizable interrogation technique whose accuracy cannot be established"

That sparked my interest. Did I miss something? One can lie about
TS/CSI clearance and be believed as long as one can fool a lie
detector? How safe is that? That strikes me as a bit odd.

Yeah, you missed something. TS/SCI w/polygraph means that you underwent a Special Background Investigation *and* you passed a polygraph during an interview which is generally used to detect if you are being deceptive in your answers to questions, not so much to find "the truth".

And you can lie about the TS/SCI until it comes time to actually be cleared for work. The "powers that be" will discover your lie before you ever emerge from the "leper colony" and your hopes of ever getting one at that point are headed down the drain.

Is clearance the problem, or the ability to obtain clearance due to
something in their background? �If your work requires it, you should have
some recourse for applicants to obtain the required clearance, no?

My understanding is that while primary and subcontractor companies can
put people in the sponsoring organization's clearance granting queue,
it takes so long to get someone through the queue that for high-level
positions they essentially make having the clearance already a
prerequisite.

Things have gotten a lot better than they used to be. My
understanding is that these days a DoD collateral TS is routinely
completed in < 6 months.

-r

I'm definitely in that camp as well :slight_smile:

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.

s2

C.

In my experience the path of least resistance is to get a junior network
engineer and ...

agree, where the end goal is to increment the facility's scripting
capable administrators. been there, done that.

disagree, where the end goal is to create a coherent distributed
system with a non-trivial lifecycle, release schedule, documentation,
i18n/l10n capabilities and deliverables, resembling an operating
system product. been there, done that.

where i'm looking at gray is platforms built atop of platforms. for
mpi, pvm and similar (b) is the better choice. for grid computing, i
suspect (a) may answer.

-e

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

> 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.

+1 Although, I've seen the opposite where a brilliant developer writes

wonderful code, leaves and you are left with a similarly difficult
situation since there are no more programmers in the department and no
brilliant developers willing to do programming that requires in depth
knowledge of networking.

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.

+1 Although, I've seen the opposite where a brilliant developer writes
wonderful code, leaves and you are left with a similarly difficult
situation since there are no more programmers in the department and no
brilliant developers willing to do programming that requires in depth
knowledge of networking.

that was not a brilliant developer. that was a clever developer.

    Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it. -- Brian W. Kernighan

and, if the department was not willing to invest in long-term software
capability, then they were foolish to enter the game in the first place.

go find an open-source solution or buy commercial. and if none fit your
needs, and you are not willing to invest in softdev, then you have a
problem in your business model.

randy

That pretty much the path that I took. I found a lot of value in automating tasks, which eventually grew into a configuration backup system that was used company-wide. I could have deployed one of several configuration management systems, but I wanted to build one from the ground up. While the code I wrote wasn't exactly pretty, it worked. No
doubt there was a lot of room to do it better, and one of my long-term goals was to re-write the whole thing in a language that was better suited to the task at hand, I ended up moving on to a new gig before that came to pass.

I still have the code (previous employer was OK with that), and I still tinker with it from time to time. It taught me a lot more about some of the nuts-and-bolts aspects of both coding and SNMP that I ever would have encountered, had I not written that system.

I think I would also add to the wish list for "the perfect candidate" is some database experience. Sometimes data is much easier to work with in the SQL world than 'live'.

jms

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

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.

Global NAPs seemingly shutdown all tandem services last week and it is causing major congestion issues with routing calls. Anyone have more information on this mess as it seems to be in it's 4th day?

Thanks

Mark Stevens

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

Seems some carriers ignored the fact GNAPs was shutting down and are still trying route calls to them which then causes a serious post dial delay while route advancing is taking place. I hope some carriers read this thread and check their routing.

Mark

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

>>> 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.
>
> +1 Although, I've seen the opposite where a brilliant developer writes
> wonderful code, leaves and you are left with a similarly difficult
> situation since there are no more programmers in the department and no
> brilliant developers willing to do programming that requires in depth
> knowledge of networking.

that was not a brilliant developer. that was a clever developer.

   Debugging is twice as hard as writing the code in the first place.
   Therefore, if you write the code as cleverly as possible, you are,
   by definition, not smart enough to debug it. -- Brian W. Kernighan

It's not so much that the code was too clever to troubleshoot, just that we
were fresh out of developers.

and, if the department was not willing to invest in long-term software
capability, then they were foolish to enter the game in the first place.

If I said this was the first time I saw a large corporation do something
foolish I'd be lying... I was consulting on a project that created a need
to modify the existing code. I probably could have tackled it but I have a
day job and didn't want to become the "house developer". Watching people
try to explain to upper management why their band of merry router jockeys
should have a developer was interesting. Sometimes it comes down to
convincing the business side to invest time and money into creating the
development position for code that hasn't been touched in years.. If you
just look at the technical bits, the need is usually obvious.

go find an open-source solution or buy commercial. and if none fit your
needs, and you are not willing to invest in softdev, then you have a
problem in your business model.

Agreed... but I was consulting. My business model was satisfied when I
walked through the door. I'm not saying there shouldn't be developers on a
team of network engineers, it's was just interesting to see what happens
when the one-eye'd man leaves.