The Philosophy of World Class Commercial Software Devs

What’s the difference between software developers that are great and those that are ordinary? One of the things that I have noticed and tried to emulate, as if some of these great software developers and other problem solvers were my coaches, is to have an understanding and philosophy behind the code. This is one reason I think I always gravitated toward learning a new technology or coding technique by having a project to use it in. I wanted to apply a new technique as quickly as I could.

Feynman is a famous physicist that has a great video from long ago on the difference between knowing and understanding. A lot of developers are at the stage where they know what to do. They “can” solve a problem using X technique. To get to the next level, they might know 3 or 4 techniques of solving the problem. Then there’s a level beyond this that doesn’t just respond to a problem with a range of solutions, but brings understanding to the table.

What I have observed world class software developers do differently when making commercial software is they have a philosophy that helps frame their toolbox and communication. One part of the philosophy is world class software developers design the problem and solution.

A second part of what makes world class software developers different is they ask two sets of questions, instead of the one most common set of questions. The common thing to do is be given a problem or task and you start right away by breaking it down in to parts, working on each part and then integrating the parts back in to a whole. The uncommon world class thing to do is first ask two questions, instead of one. Ask “what are the parts?”, but also ask “what is this a part of?” You need to manage up as much as you manage down. Taking a US car apart will show you that it is built for the driver to sit on the left side. But the car won’t tell you why the driver is sitting on the left. Ordinary engineers need to build the driver seat and steering wheel on the left to sell their car in the US, but they don’t need to know why. World class engineers need to know why and with that understanding they can approach making a car in a different way. That different understanding might lead to the same result in some cases and different results in others. Don’t deny the problem solver their ability to make sense of things and understand things. Unfortunately, this is what a lot of management and compliant software developers do when they regulate engineers to the “back-offices” so they can be worked without interuption. They don’t want to be interrupted by the customer as John Seddon would say.

A third part of what makes world class software developers different is they see events where other people see nouns/attributes. An example of this is where one person sees a thing or focuses on the main interaction and the world class software developer sees a lifecycle. He might understand you don’t just start moving things around in the system, but you have to first enter things in to the system and when the system becomes too full or noisy you might need to remove items. Adding, moving and removing items would be an example of a lifecycle. I’ve personally seen many times where a large project started with certain assumptions and one or two parts of a lifecycle were completely overlooked by everyone on the project. Take the time and do the rigorous work to understand the lifecycle of things. Otherwise you might have a super productive way of editing items, but have to insert them through a completely ad-hoc way you develop at the last minute, which makes your whole system horrible.

There’s more differences, but those are three obvious ones I’ve seen over the years.

Watch the Feynman video below and see how he describes the concept for physicists, but it just as readily applies to software developers and software entrepreneurs.