Heuristics and Aphorisms from a Decade in Software Development

The code you will find most jarring to review is your own, six months from now.

There are two types of code review, short blocks of code, which you will analyse and critique, and large blocks of code, to which you will give a cursory glance and say ‘looks good’.

Always refuse to review large chunks of code. Anything over 50 lines sees rapidly diminishing returns.

The more a developer is obsessed with displaying deep knowledge of a language, framework, or philosophy, the less likely he is to be a good developer.

The importance of testing is understated. The belief in testing is overzealous.

Prioritise testing the parts of the codebase that never fail, over the parts that fail frequently. That is where the tail risk hides.

Great code and great software are not the same thing.

Customers / stakeholders will always change their minds. Always. Always. Always. Accept this as a fundamental fact of life.

Don’t over optimise your code, unless your product is extremely mature, or solves a single, specific problem — and even then, don’t over optimise your code.

All developers need to learn the basics of UI and UX — even backend developers

You should always be thinking about the user.

Good UI design isn’t always about making things simple and shiny. Expert users may want complexity.

A steep learning curve is not necessarily a bad thing, if it allows an expert user to get things done quickly when learnt.

Instead of learning the latest library or language, most developers would be better served learning sales.

Think a good developer is expensive? They are an order of magnitude cheaper than a bad one.

It amazes me how many software developers I see take a shitty or superior attitude with stakeholders in other parts of an organisation. If you are a developer, you are in the customer service business first and foremost.

To a user, time has an elasticity. The first few seconds of a loading screen go by quickly, the new few seconds take an eternity.

No new page or view should take longer than five seconds to load.

Have a conversation with a fellow developer in which you both pause for five seconds each time you give a response. You will discover a new appreciation for the frustration of loading times.

Coding tests during interviews are pointless. Far better to give candidates a stakeholder test. Offer competing and conflicting requirements for a piece of software and watch closely how they respond.

People who say ‘just read the documentation’, haven’t read the documentation.

The number of bugs a user encounters vs. how irritated they become, is not linear. The first couple of bugs will be met with mild annoyance, the third and fourth with utter contempt.

Good developers never complain to the end client. Great developers never complain.

If a requirement is intractable, or impossible to deliver, always have an alternative suggestion lined up before communicating it to the client.

Any challenges you encounter are more convincing to the client when you DON’T use technical language to explain them.

Wait until a language, library or framework has been around for at least five years before learning it. If you have to use it before then, just learn enough to get by.

The vast majority of a software developer’s career is learning just enough to get the job done. The myth of the all-knowing developer is just that, a myth.

Depending on what type of person you are, time constraints will either kill creativity or enhance it.

Every developer thinks the code they inherit is shitty code. The developer who comes after you will think your code is shitty too.

Software development is one of the most cult-ish industries around. Avoid fads in methodology, language, or design like the plague.

Every organisation has their own definition of ‘agile’. None of them are correct.

Over time, technical jargon seems to morph into management jargon. Be careful not to conflate the two.

99% of software projects do not need a CI pipeline.

Don’t waste time trying to create the perfect deployment process, it is a form of technical masturbation.

Your users don’t care what programming language you use.

It is more important to understand different programming paradigms, than a large number of languages.

Keep your functions and class methods short. Under 50 lines, and in most cases far less.

Requirements gathering should be like sculpting a statue. Start with a rough outline, and use iteration and feedback to refine and polish.

Don’t be afraid to recycle code.

Do not bother to deliberately memorise large amounts of syntax that is easily available as an online resource. Save that capacity for more abstract concepts.

During requirements gathering, what is not said can be more important than what is said. Politics, Organisation culture, and other intangibles matter. Account for them when creating your product.

The more developers that are assigned to a delayed project, the longer that project will take to deliver.

Functionality and aesthetics are more closely related than may think.

95% of SaaS businesses can be replaced with a spreadsheet.

If you only have enough time to make the design great or the architecture great, choose the former. Users are much more forgiving when they love the look and feel of a product.

Under promise and over-deliver.

Decentralise your architecture as much as possible, even at the expense of efficiency

The only start-up you should be working for is your own.

The meaning of the word start-up has become so diluted as to become meaningless. If you’re not worried if you’re going to go bankrupt next month, you’re not working for a start-up.

If you’re a developer, It is better to work for managers who are non-technical. Technical managers will concentrate on what they know best (technology), vs. outcomes. This lends itself to endless (pointless) debates over the tech stack and architecture.

An average developer who is a great communicator will be far more successful than a great developer who is an average communicator.

The last ten years have been about big data, AI, processing power, and storage. The next ten years will be about perfecting human computer interaction to enable users to generate insight from it.

It takes far more effort to write simple code, than it does to write complex code.

Context switching is cancer to productivity.

Have the courage to keep your daily stand-up comments brief. Resist the urge to ‘pad out’ what you are doing.

Most of the team aren’t listening to your daily stand-up, they’re thinking about what they are going to say, or have already said.

Most of your career will be spent developing CRUD apps, in one form or another.

If you’re writing a feature that has to interact with another system within your organisation, increase your time estimate by a factor of four. If you work in the financial sector, increase it by a factor of eight.

For every database table you create, add ‘created’ and ‘updated’ timestamp fields. This will future proof the queries you make.

Reduce database tables to the smallest atomic unit possible. If you’re re-using a selector frequently, create a new table for it and use a foreignkey.

It is better to store irrelevant data in a table, than it is to prune data you don’t think is relevant, only to add it later. Data storage is cheap. Development time is not.

100% of projects need version control. Develop the discipline to use it well.

You are a truly great developer when you remove more lines of code than you write.

Software is easy. People are hard.

Never disable Copy / Paste in your app.

Debugging code is twice as hard as writing it. Therefore, don’t try to make your code too clever.

UX is the art of misdirection. And a beautiful UX will misdirect beautifully.

Not every developer is a designer, but every developer should treat the user as their compass.