Software Development isn’t Math — it’s Communication

Many software developers start their career by obtaining a degree in computer science or engineering. These degrees typically start with a very strong mathematical foundation but focus much less on written communication. This is a mistake!

Now, before I get a bunch of nasty comments telling me math is the most important thing in the world — let me explain. Software development obviously involves a significant amount of abstract analysis and requires the ability to understand mathematical and engineering concepts. Without these skills, we end up with brittle software that performs poorly..

But, my experience  has taught me these skills are only useful if a developer also has the ability to communicate their ideas effectively.

The most important skill for a software developer is the ability to communicate abstract concepts in concise, logical and structured ways

In case you missed it, the last half of the above statement is also a good definition of higher-order programming languages. We could still be writing code in 0’s and 1’s. But, we’re not — because it’s much more difficult to understand binary than higher-order languages. In fact, we even call them — wait for it — ‘languages’.

If a developer’s only intent was to communicate instructions to the computer / operating system — binary or machine code would be sufficient.

Whether they realize it or not, all developers are writing code for three audiences:

The Computer, the Developer and the Maintainer

I know, it sounds like a C.S. Lewis book. But, just like a good writer knows his audience, all developers should consider their audience as they design and write code.

For any given software program, there is an infinite number of ways to design a solution. How you make use of things like composition, polymorphism and other design patterns indicates to other developers and maintainers how you intend the system to be used, modified and extended.

Take a break, look at your code through someone else’s eyes

For any real, meaningful project, your code will never run in a vacuum. Someone is going to modify it. Someone is going to integrate with it. It’s not enough just to make it possible–you need to make it as easy as possible. Specifically, you need to make it easy to extend the right way — and hard to modify the wrong way.

What do you think? Have you known someone who came up with viable solutions that no-one could understand? Are communication skills vital for software developers?


Two Traps all Software Developers Must Avoid (A.K.A. Ned Ludd is the Devil)


Software development is a challenging task–one where the velocity of change is staggering.  Practices, ideas, technologies and languages that are considered best practice today may be relegated to the trash heap tomorrow.

However, at its core, good software development doesn’t really change that much.  That’s because, at its core, good software development isn’t about software development at all.  It’s about understanding a problem domain, finding ways to facilitate an activity in that problem domain and then breaking down the tasks and ideas involved in that activity into loosely coupled, well defined conceptual chunks.

There are two major traps all software developers should avoid at all costs:

Don’t become a ludditefactory

The Luddites were 18th century English textile workers who protested against industrial revolution technologies such as the spinning frame and power loom.  Software developers that refuse to investigate new technologies, languages or tools are similar to Luddites.

While it may come as a surprise, I’ve known many developers (particularly in the enterprise world) who have many years of experience in a particular tech stack and refuse to develop in anything else.  The rationales are varied but the crux of their argument always returns to: I can do it the way I’ve always done it and I know it will work.

This is, of course, true.  But the argument is specious.  You can write a modern web-app in assembly but you won’t be providing a very good return on investment to whoever’s paying for the development.  Ultimately, software developers are employed because they provide good return on investment–they create a better product, faster, than someone without their education and experience.

Over the years, we get better at decomposing things and assembling them in more useful ways: we create general patterns (e.g. the factory pattern, the singleton pattern, etc.) that help us identify common ways of decomposing ideas. We create new technologies that allow us to share components more effectively (e.g. NPM, Nuget, Maven, etc.).  And, we develop new languages that help us assemble things more quickly, allowing us to better leverage new patterns and tools.

Refusing to make use of these improvements is tantamount to dereliction of duty.  Exactly which tools, when and how you leverage them depends upon the project’s demands and constraints.  However, it’s your job to stay up-to-date and take appropriate risks to improve the quality of your product.  If you’re not willing to research, learn and experiment, you shouldn’t be a software developer.

don’t paint the duckbabyduck

Okay, I’m mixing metaphors here.  “Painting the bike shed” refers to an inordinate focus on trivialities.  The “duck technique” is when a developer throws in a sacrificial feature they don’t mind getting rid of to distract management from the features they feel strongly about.

“Painting the duck” is when a development team becomes hyper-focused on trivial features.  Yes, the color gradient of the help button is important.  No, you shouldn’t spend three months on it.

It’s surprisingly easy to become focused on the wrong things.  This can be due to a lack of clarity from management, lack of communication with the users, poor process or even a well-intentioned desire to make the best product possible.  A product that ships with a 90% solution is better than a 100% solution that gets canceled because it’s late and over-budget.


Keep learning.  Take risks.  Be pragmatic.