Programming Languages are tools. Learning a tool doesn’t make you a developer.

If you learn how to use a saw and a hammer, that doesn’t mean you are able to build a house. Saws, hammers, screwdrivers – these are all tools. How you apply them to solve a problem (when and where) are techniques. There are multiple techniques you need to learn in order to understand how to build a house. While you still need to know how to use your tools, there’s fundamental concepts that you need to learn first, such as carpentry, masonry, and plumbing. Similarly, learning a programming language like JavaScript does not make you a programmer. You need to learn techniques for how to apply the tool to solve problems, not just learning the tool.

Tools can help you apply techniques and concepts, usually either in saving time or effort, or making a task easier than performing the task with your bare hands. Without a knowledge of these fundamental concepts you could certainly attempt to build a house (“I know what a house looks like so I know how to build one, right?”) and while you might end up with an end result that looks like a house, it will probably won’t be safe to live in. After the first winter storm you’ll probably find your roof leaks and you’ll be lucky if it’s still standing after being subject to strong winds.

Practice Makes Perfect

Knowledge of tools, concepts and techniques still does not mean you can apply them competently. Following with the house building analogy, if you read a book on house construction, could you successfully (and safely) build a house? Maybe. If you get your first job on a construction site and get some experience in house building and learn how to apply the techniques you’ve picked up from studying your house building book, it’s more likely for your next construction job you’ll be able to apply the knowledge and skills you’ve learned. Over time you’ll get advice, see what works and what doesn’t work, pick up tips and techniques that can save you time, growing your experience and competency.

Software development is no different. To improve your skills you need to get feedback on your work, you need to get advice on areas where you can improve, but just as importantly you need to practice your skills.

There’s commonly quoted advice that it takes 10,000 hours of practice to become and expert at anything. This has to be deliberate practice with the goal of improving your skills. For software development, spending 10,000 hours writing the same line of code over and over is not going to help you at all in becoming a better developer.

Don’t get caught up in comparing the pros and cons of different languages, or wanting to learn a specific language because you read it’s the ‘best’. Once you’ve learnt one you can more easily learn others. Spend time learning techniques and approaches to solve common problems. Learning a tool can be beneficial, but it’s not particularly useful if you don’t know how to apply it effectively.

As an industry we do a poor job of teaching new developers how to develop software

This is not a criticism of any specific school course, bootcamp or on the job training, it’s merely an observation over the years: early Spring and late Autumn/Fall there is always an increase online of very basic developer questions. These questions always include things like: “why doesn’t my code work”, “can someone debug this for me”, “why does this code not produce the result I’m looking for”, and even the flatout “please help me with my homework – here’s the assignment”

These points in time coincide with the start of a new term as new students are starting to learn a programming language, I guess it’s pretty much expected that we would see the number of these types of question increase during these times of the year. My point though is that these types of questions appear again and again every year. Every. Year.

Why have we not progressed past the point where new developers don’t need to ask basic questions as they are starting out? Why are software development courses not equipping new developers with basic problem solving skills to help them trouble solve basic problems for themselves?

Most of these questions and problems could easily be solved by the developers themselves if they stepped through their code in a debugger in their IDE and looked at what happens in their code step by step up to the point where something goes wrong usually because of a simple logic error.

Other problems could easily be solved by applying basic problem solving and software development core techniques:

  • breaking a large problem down into smaller parts
  • writing unit tests to test each smaller part of the app in isolation to confirm each part works by itself
  • testing with a range of valid and invalid values to find what works and what doesn’t work
  • using log statements to trace execution through an app
  • identifying what changed since it was last working, incrementally backing out last changes to find the point where a change was added that broke something
  • using a debugger

There’s too much emphasis on learning a programming language to write code, and not enough focus on techniques to develop software. None of things I listed above are new ideas or concepts, experienced developers have applied these concepts daily for decades. It seems we’re failing short in training new developers if we’re missing out the basics.

What is the ‘main thing’ in software development?

Software development is about solving problems. It’s about solving problems in an effective way that adds value. It isn’t about programming languages and writing code. Programming languages are tools. We use tools like Cloud compute to run our solutions, and we build solutions with tools like programming languages and frameworks.

It’s all about solving problems.

If you’re getting started in software development as a career and are putting all your effort into learning a programming language, remember that’s just a tool. It’s how you use it to solve problems which is the important part.

Is the software development industry trapped in a cycle of being ‘perpetually immature’?

A while back an xkcd comic on Voting Software attracted a lot of attention on Twitter for it’s alarmist comparison of the attitudes of the software development industry to other engineering disciplines and in particular, this statement:

“our entire field is bad at what we do, and if you rely on us, everyone will die”

From: https://www.xkcd.com/2030/
Voting Software
From: https://www.xkcd.com/2030/

This was widely shared and quoted on Twitter, and even shared by industry leaders such as Grady Booch:

https://twitter.com/Grady_Booch/status/1027291830101016576

There was one comment in reply to Booch’s tweet that particularly resonated with me:

https://twitter.com/Joerg1968/status/1027417862422573057

“I fear that perpetual adolscence is our curse and our gift – (we’re) always chasing the next shiny thing”

Joerg Muller-Kindt

This thought that as an industry we’re stuck in “perpetual adolescence” caught my attention. As an industry we struggle to advance. What’s unusual when you think back over the past 20 years and even further back looking at the history of our industry, there are developments and ‘movements’ where groups of individuals come together to champion an idea that at first seems to make a positive improvement to our industry as a whole, and then over a few more years the ideas fade away and seem to be forgotten. Some are even occasionally rediscovered again by another group of like-minded individuals years later.

The ‘perpetual adolescence’ of our industry as I see it is not that we’re stuck at a particular point in our industry’s growth and unable to progress, we do progress and advance. This growth however, appears to be in short cycles where we move forward, but then we go back to what we were doing before, and we’re stuck in a cycle of discovery and rediscovery. It’s not as bad as one step forward, two steps back, but it does appear to be something like one step forward, one step back. We’re never continually advancing, occasionally we move forward but we end up going backwards again. The progress of our industry never seems to be continually moving forward. Maybe this is typical of any industry in its infancy.

Examples:

  • The ‘software crisis‘ of the 1970s
  • Structured Analysis and Structured Design
  • Formal methods
  • 4GL development tools focused on developing specific styles of application (e.g. PowerBuilder, and client/server type systems)
  • The hype of Object Oriented languages
  • Fred Brooks seminal article “No Silver Bullet
  • CASE (Computer Aided Software Engineering) tools and code generation – mid 1990s
  • UML, Rational Unified Process (RUP)
  • The Agile Manifesto
  • The cycle of centralized vs decentralized (distributed) systems
  • The hype of Functional languages
  • Strongly typed vs dynamic languages
  • Platform independence vs platform dependence (of languages and technologies)
  • Software development as an engineering discipline or an art, and everything in between
  • Serverless, as the solution to all problems

There’s plenty of other ideas and concepts that could be part of this list, and I’m not highlighting anything in my list to say these ideas good or bad, but when you look back it’s interesting how ideas come and go over time. People come and go too, some noticeably bringing new ideas and passion with them, sometimes rediscovering ideas again from the past. Sometimes as champions leave the industry their ideas no longer have a voice and their ideas disappear with them too.

If our industry is still in its infancy, is this cyclical, repetitive behavior just the industry trying out new ideas to see what sticks? Or is it that the people actively involved in championing ideas come and go too, bringing ideas in and sometimes taking ideas with them when they move on? Does this mean that as an industry as experienced developers leave the industry and new generations of developers come in, are we doomed to continually repeat our mistakes of the past?