Don’t believe the non-programming hype


This will be a shorter, less-polished post than usual.  It’s really just a way to start to bring a bit of structure to my thoughts.  Feel free to add some comments or weigh in on the linked Twitter thread.

I came away from a recent PacketPushers episode, “Don’t Believe The Programming Hype” a bit disappointed that the discussion didn’t get to the heart of the matter.  Then there was this tweet from  which kicked off some interesting discussion about the place of programming:

Why shouldn’t we believe the non-programming crowd?

So here are my propositions (and some corresponding anti-propositions):

  1. Programming isn’t hype; programming is a fundamental IT skill.  If you don’t understand the basics of computer architecture (e.g. CPU instruction pointers, registers, RAM, stacks, cache, etc.) and how to create instructions which make computers do useful things (i.e. coding), you’re not an IT professional.
    • This doesn’t mean you must understand exactly how every computer architecture works, or know how to code in assembly language (or directly in hexadecimal like Mel the Real Programmer).  But it does mean that if you’re confronted with a problem, you know enough fundamentals to peel back the layers, and work through the elements in each layer methodically (with the help of the documentation) to determine the component in error.
  2. There is no fundamental distinction between scripting and programming.  Both are designed to accomplish basically the same things, at different levels of abstraction.  Suggesting that someone who writes scripts to automate his or her infrastructure is not a programmer confuses the issue and does not progress the discussion.
    • This doesn’t mean that vendor-originated code isn’t better than in-house scripts (sometimes it is; sometimes it isn’t), but it does mean that the value of the local process and infrastructure knowledge contained within in-house scripts mustn’t be sidelined.  No off-the-shelf software “just works” without configuration or customisation of some sort, so in-house scripts are fundamentally necessary.
  3. The above distinction is probably just a specific instance of the generalisation that there’s a difference between builders and non-builders.  This is also a non-real distinction.  Every enterprise IT organisation is building something, whether they use code they’ve written themselves or rely solely on vendors.  You can’t compile a data centre contract into existence or code up a WAN link; working IT systems are built both by those who create the individual components, and those who build on those components.  It’s turtles all the way down; not many software vendors assemble their own motherboards or run their own chip fabs…

How did we get here?

So how did we get to this point where the concept of learning programming seems so intolerable to networking folks?

In my mind the main factor is the normalisation of proprietary software – that is, the widespread acceptance that it’s OK for software to be closed to scrutiny and not fully controlled by those who depend upon it.  (On the contrary, I hold that Open Source is essential for the operational safety of functioning IT systems.)  The dominance in their respective markets of Microsoft Windows on the corporate desktop & server and Apple iOS on consumer devices are no doubt the most common examples of this, but other, more egregious examples pop up routinely.

This has led to a generation of IT folks for whom the fundamentals were something akin to magic.  “If I press here it does this…”  The pushback against programming is only one example of this.  (Another is the cargo-culting/guessing troubleshooting culture that many of us in operational roles have encountered.)

My plea to those who are pushing back against the programming trend is simply this: have a go!  Programming is just building things – like you already do – just at a different level of abstraction.  You might find that you like it, and it opens up a whole new range of possibilities for you.


I recognise that I write this from a biased perspective:

  1. When I started in IT, there were no “IT” qualifications.  When I went to university, the course was still called Applied Science with a major in computing.
  2. My first job (while still in uni) was a programmer.  After that, I was a Unix sysadmin.  Back then, Unix sysadmins were expected to know C in addition to the usual scripting tools.  Network engineering was a relatively late addition in my career; I didn’t start being the primary networking resource in my job until 2003, and didn’t get my CCNA until 2012.  So I always approached networking from a slightly different perspective to the “average” network engineer who did his/her CCNA straight out of school.
  3. I’m a Free Software “true believer”; I first installed Linux from floppy disks with a distro which used kernel version 0.97.  I’ve been using Linux on the desktop for almost 20 years.  You can’t survive that long in the Open Source world without being able to compile (and sometimes fix!) software on a semi-regular basis.


Feel free to discuss!  Either in the comments below, or shoot me some thoughts on Twitter.

5 Replies to “Don’t believe the non-programming hype”

  1. Just to continue what I consider the good natured back and forth from Twitter, here are a few more rando opinions.

    I think we agree that the skill set needed to be a decent IT professional is different today and in the future than it has been in the past. This is especially true in Networking where decision making about hardware and software bas been essentially stagnant for 10+ years.

    Even today people think a network upgrade is upgrading a Cat 6500 SUP card in the same chassis, as a component of the same, tired three tier network architecture. Each box is handled individually with CLI. Spine/leaf, automation, and similar concepts are not even on the radar for many.

    I’d say, though, the new skill set doesn’t necessarily need the knowledge of stacks, registers, and so on that Paul mentions. So what does the new skill set look like?

    First, there are soft skills. The Networking group needs to get out of their silo/office and start participating in understanding the business problems that development is being asked to solve. Then, they need to be able to communicate resource needs and constraints to the rest of the team, especially addressing technical debt and possible mitigation.

    As part of this, Networking needs to understand enough of the Dev stack so they can properly design a compliant architecture, which is likely to be different than what’s in place. Lots more could be said here.

    Next, there are hard skills outside the classic skill set one associates with Networking. Here I’d say that the skills include the path to automation, consistent with what Dev is using. If Dev isn’t using anything, that’s an area for collaboration along with other Ops folks. Also, version control like basic Git literacy. I’d also include testing, consistent with Dev practices, assuming they were rational.

    The problem I have with a lot of the commentary, especially on podcasts, is that traditional Networking people are freaking out about upgrading from two fingered CLI to expectations of being required to be Python wizards. Understanding Python syntax and control structures would be great, but most Networking groups are so far removed from really basic understanding of the modern context, for instance the use of version control, that a roadmap to Python is not really the main issue.

  2. To clarify further (hopefully), what I’m not trying to do here is define what the skill set for networking people (or all IT professionals) should be – everyone will have a slightly different view on that, and it will vary depending on the organisation and exact role. What I am questioning is whether computer architecture and programming are foundational to all those other skills. I maintain that they are, and that every IT professional, whether a “traditional network engineer”, a PeopleSoft developer, a Windows sysadmin, or an iOS App developer, needs to know those basics. Obviously, the aforementioned roles will differ in depth and breadth of understanding of the basics from, say, a Linux kernel developer, but they are still our basic literacy — our alphabet.

  3. yet, most of them have some combination of perl, python, tcl, and bash scripts they have written to help them get stuff done in their daily duties. When has system administration ever not required some amount of programming skill?

  4. @cloudtoad: This is where I think there’s a divide between those who cut their teeth on Free Software (or at least on old school Unix) and those who started out on proprietary systems.

  5. Sorry I stopped reading at:

    “Programming isn’t hype; programming is a fundamental IT skill. If you don’t understand the basics of computer architecture (e.g. CPU instruction pointers, registers, RAM, stacks, cache, etc.) and how to create instructions which make computers do useful things (i.e. coding), you’re not an IT professional.”

Leave a Reply to paulgear Cancel reply