The single most valuable advice I can offer to new software developers

When starting out in software development or even learning a new language as an experienced developer, the most likely cause of most ‘I don’t know why this code isn’t working’ type questions is pretty simple:

What you think your code should be doing is often not what it’s actually doing.

This seems like an obvious observation, but it’s easy for even an experienced developer to get caught up in what they think their code is doing, and they forget to look at what it’s actually doing.

Next question: “ok, so how do I find out what my code is actually doing at runtime?”

Answer: you use a debugger. You step through your code and you compare what you think each line should be doing with what it’s actually doing. At some point you’ll find a line where you assumed the code was doing one thing but it’s actually doing something else. It could be the variable of a value that you were assuming to be a particular value but actually it’s something different and it results in a result that’s different from what you were expecting. It could be a condition you were assuming to be true is actually false. It could be a block you were assuming would always get executed but never is. There’s many reasons.

Learn how to use your debugger:

  • Practice stepping through your code
  • Learn how to set breakpoints
  • Learn how to set conditional breakpoints (break when a certain value or condition is met)
  • Learn how to inspect value of your variables
  • Learn how to change values at runtime – what happens when this value is 1 instead of 2?
  • Learn to break on an error
  • Learn how to step backwards to a previous statement (not all debuggers do this but it’s a useful feature)
  • Learn how to change code while you’re debugging

Knowing how to use a debugger is an incredibly valuable skill. It’s seems a given that as a developer you would learn to use and use a debugger as an integral part of your development, but all too often though when asked ‘why is this code not working’, if you ask ‘have you stepped through in a debugger to see why it’s not working?’ the answer is ‘no’.

Learn to use your debugger!

The Pragmatic Programmer: 1st edition vs 20th anniversary edition – what are the major changes?

I might come back and do a more thorough look at each of these differences later, but I wanted to get a rough idea of what were the main changes to each of the chapters in the recently released 20th Anniversary Edition of the classic book, The Pragmatic Programmer.

There’s probably plenty more other changes even in the sections that are common between both editions, but this is a high level overview of the major differences in each chapter, summarized as:

  • New sections added
  • Sections with major changes
  • Sections removed

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?

Why code is hard to test

Junior Developer: I can’t write a test for this code, it’s too hard to test

Senior Developer: Who wrote the code?

JD: I did

SD: You’re saying the code you wrote is hard to test. If you wrote the code, who made the code hard to test?

JD: I guess I did

SD: Right, so can you restructure the code to make it easier to test?

JD: Yes, looking at it again, I could break it down into smaller methods that would be easier to test individually

SD: Great! In future, how can we write the code so make it easier to test?

JD: Well if I think about how I’m going to test the code as I write it, then I can definitely write it in a way that would make it easier to test

SD: Great! And if you write your tests before you write your code, that would help even further with that approach, right?

JD: Yes, I guess it would.

TDD is not rocket science.