“Programmer” is the New “Author”: How Misperception is Polluting an Industry
I'm an author! Me too! And me!
Often, when meeting and networking with new people, one of the first questions people ask each other is what they do. It is one of those simple, polite questions that often goes a long way to exposing deeper topics and leads to finding common ground and similar interests. Typically, it will result in a response indicating what the person does for a living: that they are a doctor, or a teacher, or etc. Occasionally, though, people will answer with what can only really be defined as a hobby or passing interest. Something they aspire to, but haven't quite reached. The most common example of this is the fledgling author.
It is not terribly uncommon to hear someone introduce themselves as an author, despite the fact that, upon digging deeper, it turns out that they have written very little save the essays they turned in to professors before graduating. You’ve probably heard someone profess that they are working on their first piece - as they have been for several years - and that things would really take off if only they could sort out that introduction or first chapter. No doubt, many of these people are in fact honest to goodness paid writers that, through skill and the dedication to put forth the time and effort necessary, truly do make a career of writing. Those for which this is not the case, however, are undeniably abundant.
Similarly, I frequently hear people talk about their son, niece, sister-in-law, etc., who “programs” web pages using WordPress; or a friend that, once, back in high school, wrote a tic-tac-toe game in JavaScript. All too often these people, who have spent less time actually developing software than it will have taken to read this article, go about calling themselves software developers, programmers, and web designers. I myself was guilty of this during my teens. Surely, I thought at the time, the “Hello, World” and “Magic Eight Ball” applications I had under my belt meant I was a real programmer. This invalid association tends to come from a view of programming as simply “writing code”. It is looked upon as something that anyone who can remember some syntax rules can do. In truth, much like the difference between being able to write a simple sentence and being able to pen a complex, cohesive story that draws in and captivates the readers, there exists a vast gap between being able to write a simple control structure and being able to create a flexible, maintainable, and reliable piece of software.
Is this misperception really all that harmful?
When it comes to authorship, the truth is that the misperception that anyone can be an author, despite the immense amount of skill, passion, and dedication true authors possess, really isn’t that harmful. In the end, the only real harm is the possibility that a few papers or books may be banished to the realm of creative abandonment, never to be published by their so-called authors. This is, in large part, because of the simple fact that getting something formally published typically requires a completed product that can be reviewed and assessed by the publisher. As such, two major hurdles must be overcome in order for someone to make it into the writing industry: actually dedicating the time to produce a piece and getting that product passed publishers.
For software developers and programmers, on the other hand, the hurdles are far smaller. For one, most entry level programmers are not expected to have produced any significant work that can be reviewed and analyzed to prove competence. Rather, such projects are generally looked at as bonuses that separate a few candidates from the majority. Second, because the management teams that typically control the hiring tend to have their view of how much actual skill and creativity programming takes tainted by the aforementioned misperceptions, there is often quite a bit of pressure to hire “someone” without taking the time necessary to properly interview and evaluate candidates. This makes it nigh impossible to consistently determine if candidates are genuinely capable of proper development. As a result, it is far more common for people that are not truly skilled at programming to break into the industry, even if they don’t possess the most basic knowledge and skills necessary. As evidence for this, consider the following terrifying fact: I once had a member of a development team I was on ask me what an array is. To put that into perspective, the question would be akin to an auto mechanic asking what a car’s air filter is for. It is a fundamental component of every piece of modern software, and yet a paid member of a development team was completely oblivious to it.
To be fair, I can place the full blame for that individual’s unqualified presence on a software team on neither the team member nor the human resources department that did the hiring. After all, the developer in question held the necessary accreditation, a degree in Information Technology from a local college. Of course, that fact itself exposes quite well just how deep the problem goes. Even today’s colleges don’t entirely understand the skills and knowledge required to actually develop software. Instead they give students minimal exposure to development processes and walk them through writing the most basic bits of code. Consider, for example, that, during the entirety of the time I was working towards my bachelor’s degree, I was not required to independently author a single piece of code larger than one function, the equivalent of a short paragraph. Even more surprising is that the university in question is reputed to have above average programs in both computer science and information technology. That’s not to say the program and those of other institutions aren’t immensely educational, they simply don’t focus on the types of things professional developers need on day one. Instead, the expectation for most graduates is that they will enter the work force as junior developers and spend the first year or two of their career learning the most basic elements of their trade.
Consider for a moment how that would go over in any other industry. Imagine how much more terrifying air travel would be if we knew that the plane’s design process likely included an electrical engineer who knew all about different design documents, terminology, and standard aviation materials, but didn’t know that an ohm is the standard unit for measuring resistance in a circuit. That is the sad state of the software industry. Developers are taught all about the history of software, the different types of sorting algorithms, and what the software lifecycle looks like, without ever being exposed to standard design practices or asked to evaluate a problem to determine a practical software solution. Meanwhile, employers go on blissfully unaware that their software efforts are being hampered by the indiscriminate hiring of ill-prepared programmers.
Lifting the Fog
Because the problem rests at the fundamental level of understanding what knowledge and skills a software developer needs to be successful, solving the issue will not be simple. The software industry must push harder to legitimize and standardize the development profession, specifically with regard to the common understanding of what standards and methodologies separate professional developers from hobbyists. To that end, a lesson needs to be taken from other professional industries and the practices that are foundational to successful software development need to be codified, taught to students before they are introduced to the workforce, and strictly enforced by software teams.
In terms of codifying standards, several organizations have made great strides. The Project Management Institute, though not I.T. specific, is consistently pushing the management side in the right direction with their project management certifications, and it is continuously gaining traction in the software industry. From the design and development perspective, we as an industry, have been less successful. While certifications exist, they tend to be highly focused on specific technologies rather than the fundamental concepts and methodologies necessary to develop software successfully. Even Microsoft’s catalog of certifications, which includes the MCSD certification, pushes developers into specific knowledge areas like Windows Store apps and ASP.NET MVC. Not one of their certifications looks at the real core of what makes a professional developer: understanding of and ability to apply fundamental design patterns and practices. This gap needs to be filled by defining a core body of knowledge that covers the various patterns and practices that lead to high quality software, why they exist, and how to properly apply them.
Additionally, with regard to individual companies, two primary changes need to occur. First, senior members of development teams need to be more diligent in making sure their existing team members live up to industry standards and best practices. For a great many teams, this will start with actually defining and documenting the standards that must be followed by every developer on the team. Once the standards are in place, certain quality assurance tools, such as code and design reviews, can be used to ensure that the standards are followed. Second, software managers and key I.T. executives need to be more active in using their positions as thought leaders to both empower team leaders to enforce standards, as well as help define recruitment and hiring practices that ensure their companies are picking qualified, effective developers. The practice of hiring just anyone that has written HTML or can recognize a basic control structure must end.
