Software Developer Priorities

Reading threads on Twitter, it’s a telling sign that almost all discussions from software developers/engineers I follow revolve around code, software architecture and technical stuff.

Very few think to mention customers or the greater impact on people from what do.

My priorities are:
1) People. Our customers.
2) Security and data privacy.
3) People. Our customers.
4) Code.

(The only reason security isn’t #1 is because without people, security isn’t a concern in the first place.)

But to be clear, I do spend a hefty amount of time thinking about code and software architecture. They’re just not my priority.

Dark Matter Software Developers

Let’s not forget, for every software developer who is active on social media, blogging or the speaking circuit – there are at least 100,000 developers working 9-to-5 jobs and keeping the world running. People you’ve never heard of and don’t have open source projects.

These people are the backbone of our economy.
They do their best while living full, balanced lives.
And a lot of them are as wise, if not wiser, than the big names and voices in our industry.

Let’s also consider: there are no Einstein’s in software development yet – only people who have written books, made their name on social media, or got lucky building a publicised software company.

Software development is an industry founded primarily on collaboration, incremental development, and more failure than success.

So, remember the quiet person who does their contractual hours every week and contributes to a product that affects thousands of people.

These are the people we must celebrate.

“Doing Cloud Software” – Since Before It Was Fashionable

I’ve been doing “cloud software” since 2007 – the year I registered my first domain.

I built and hosted my first website on
And I’ve since built WordPress websites that run in cPanel on system managed by

I’ve never had to create a network or a virtual machine.
Every software product I’ve designed and build has run on platforms other people mange, and service I can just deploy into. gave me an ASP.NET platform and SQL Server.
Digital Pacific gave me PHP, WordPress and MySQL.

I never had to worry about infrastructure – just my application code. The rest was APIs.

Since then I’ve moved to Microsoft Azure and used only their serverless offerings – what is now Azure App Services, Azure SQL, Functions, Table Storage, Blog Storage and now Cosmos DB.
All “API” based.

I’ve never had to worry about infrastructure or anything I couldn’t access and control via a dashboard.

And to be honest, any time someone talks about Docker or Kubernetes, I can’t help but think “that sounds like too much work”.

.NET Linq .Select() often means “project”

I’m old school so I haven’t worked much with Linq (Language-Integrated Query (LINQ) (C#) | Microsoft Docs) – beyond the absolute basics – until this year.

One of the methods I’ve needed to use quite a bit is the Enumerable.Select Method. Which has been hard to wrap my head around until I realised something:

The method name doesn’t fit my mental model.

And the reason is in the first line on the Microsoft documentation page:

Projects each element of a sequence into a new form.

The key word being “projects” (as in, a “projection”). Which in cody-cody speak means “take the data I’m giving it and turn it into something else”.

See, when I see “select” I think of SQL “SELECT”, and in most cases we’re just picking data columns you want to return. Though, to be far, now I think about it you can also “project” with it.

But still, when I think “select” in the context of data it’s “you’re going to give me some data, and I’m going to pick the bits I want”. Whereas with “project” – particular in the context of the code I’m working with – means we’re “transforming” the data and often pulling in other data peripherally linked to it (in a way acting as a join). This is often doing by calling another method that takes the current item in the data and does something with it – e.g. used some value from it to lookup or generate other data structures.

The Microsoft docs page Projection Operations (C#) | Microsoft Docs start with the following which explains it well:

Projection refers to the operation of transforming an object into a new form that often consists only of those properties that will be subsequently used. By using projection, you can construct a new type that is built from each object. You can project a property and perform a mathematical function on it. You can also project the original object without changing it.

So what I need to do in a lot of cases for the code I’m dealing with is mentally swap .Select( x => x. ... ) for .Project( x => x. ... ) and it makes much more sense.

My “Days in Each Month” Mnemonic

The “well known” mnemonic to remember the number of days in each month is:

Thirty days hath September,
April, June, and November,
All the rest have thirty-one,
But February’s twenty-eight,
The leap year, which comes once in four,
Gives February one day more.

But I have a shit memory, especially for nouns, so after 40 years in this world I still don’t remember it. Fuck it, I don’t even try.

But I have another mnemonic I made up many years ago that’s much shorter:

4, 6, 9, 11 have 30.

Yeah, it’s that simple.

So, here’s how it works for me.

  1. February is easy pickings to remember. I know it has 28 days, and 29 in a leap year. I’m not going to forget that. So I basically ignore it because it’s easy.
  2. “30” means 30 days. Therefore, all the rest have 31 days.
  3. “4, 6, 9, 11” are the numbers of the months with 30 days (April, June, September and November).

The thing about 4, 6, 9, 11 is:
4 + 6 = 10.
9 + 11 = 20.
Both are divisible by 10. Which I easily remember. (I’m probably a bit better with numbers and number patterns).
So that makes the first pair (4 and 6) and the second pair (9 and 11) easy to remember for me.

But this is a very personal thing.
The numbers and the divisions and the bits I can remember… they all work together in my brain.

It’s not for everyone. But if you have trouble remembering the days in each month then maybe this will help you trigger a way to remember something that is personal to you.

And that’s all it needs to be.
You don’t need to remember the common mnemonic at the top.
You just need to find something that works for you.
That’s what I did (and created).

Presumptions vs Questions

I’m re-watching “Godzilla: King of the Monsters” and (spoiler) came to the scene with the sunken city.

Having not thought about it before I searched “godzilla king of the monsters is that atlantis”.

And then I realised my mistake.
I started with a presumption rather than a question.

What I should have – and subsequently did – search is “what is the sunken city in godzilla king of the monsters”.

This highlights what I believe most of us to a lot of the time: start with a presumption before we ask a question.
In other words: it’s a leading question, looking for a response that supports a preconceived position.

True discovery comes from asking questions without any presumption.

Advice for business people working with software developers (understanding what developers actually mean)

As a veteran software developer who understands both how software developers think and operate, as well as the positioning of business folk, I often seen the following situations arise and the disconnect that never seems to be addressed.

This article is written for business folks who work with software developers.


When a software developer says something is “easy”.

Software development is not easy. Ever!

It is a complex, complicated, time consuming process. This is the truth.
Any developer who disagrees with it is either a savant genius (doubtful), lying (not very likely), doesn’t yet have enough experience to understand (likely), or hasn’t “stepped out of their shoes” to properly think about it (most likely).

So when a developer says something is “easy”, what they really mean is:

Based on what you’ve told me, it sounds like I need to do something I’ve previously done, or it’s something I’ve learnt about, which I’m confident I can do without a much extra learning or mental effort.
And I’m just going to ignore for now anything that can trip me up in the process.

A couple of things to know about the “common software developer” and the software development process:

  • Developers are optimistic. Personally I think it’s part of the nature that makes them a developer. It’s a “can do” and “anything is solvable” attitude that drives them to find solutions and innovate.
  • There many of unpredictable things that can, and quite often do, go wrong. Such as:
    • A single character typo that takes half a day or a good night’s sleep to find.
    • A software dependency changes and breaks everything.
    • What seemed like a simple approach doesn’t work.
    • Implementing it is more complex than first thought.
      There are many, many more variables and conditions that need to be considered than were evident in the initial brief.
    • After building the thing it doesn’t work as expected. Or performance is nothing like expected.

And we also have to keep in mind if the person saying “it’s easy” is also the person who has to do the actual work.
Are you asking an architect with 20 years in the industry (and who may also be out of touch with the actual tooling and development process) while a developer just out of university is the one tasked with implementation?
Conversely, are you asking junior developer without experience yet?

Finally, many developers don’t like to say “no”, disappoint a boss/senior, or appear to not know what they are doing.
Many developers also fear for the security of their jobs, and by extension saying something is “not easy” can show weakness in their ability.

It is my belief that “it’s easy” is one of the primary reasons software development projects fail, in part because the question of “how hard is it?” is also the foundation for my next point.


When a software developer gives you a time estimate.

The golden rule of software development estimation is:

Multiple by 2.5

This is not in any way a joke or exaggeration.

Software developers are optimistic, shit at estimates (see the discussion above) and, my personal belief, we very quickly learn to estimate based on what we learn the business “wants to hear” vs what we really know to be true (let’s face it, most of the time the business is going to be pushing for an externally driven deadline regardless).

I’ve been estimating for 20 years and I still regularly get it wrong. Estimation is hard. There are so many unknowns and unpredictable external influences we have to contend with.

Unless you are absolutely confident the person you ask padded the estimate, then as a business person any estimate you receive from a developer should be multiplied by 2.5 for an accurate idea of how long it will take to implement.

Now, a crucial point on this is the word “implement”, which means “the time required to spend working on the task” (i.e. working hours).
It does not mean “it will be finished in that amount of time after it is started”.
It is not a delivery time.

When working on a task, a huge chunk of software development is more than just writing new code. It is:

  • Thinking.
  • Scrapping or changing what’s already been built.
  • Integrating into a larger project (and often having to make cascading changes across the project).
  • Testing.
  • Researching.
  • Discussing with colleagues.

A note on “testing”: Developers will not factor in time for testing in estimates, almost guaranteed.

On top of that, anything but the smallest task cannot be completed in one sitting.
Even a task that can be finished in 4 hours will need to split split over multiple days, to take into account time to think, time to test (especially if other teams are involved), general interruptions, and meetings that come with working in a business.

One final tangential but related point is around asking for progress updates.
There are a few of things to think about when asking for an update:

  • Be clear about whether you are asking “how much of the expected time is taken” vs “how much of the feature is complete“?
    Unless you ask specifically for a time based answer, assume the answer will be in terms of feature completeness and expressed as a relative value, either a percentage (e.g. 80%) or a vague “almost done”, “half way”, “only just started”.
  • A percentage of feature completeness is not proportional to the time taken.
    • A task that is 80% complete does not mean “80% of the time is used”.
      Nor does it mean the remaining work should take only 25% more time (math lesson: 20% of 100% is 25% of 80%).
      Many tasks can reach 80% complete in just 20% of the estimated time (and some can take 250% of the remaining time to complete).

Above all, NEVER hold a software developer to an estimate!

Dr Evil: We'll ask for estimates and treat them as deadlines.

It’s a well known joke in the industry, but it’s also a reality (I’ve been subjected to this many times over my career) and it is, to put it quite bluntly, a fucking toxic approach at will destroy your credibility with the very people you rely on.

Hopefully by now you realise why an estimate cannot be considered a deadline.

On the matter of estimates vs deadlines, here’s the best approach to take:

If you have a deadline that must be met, set it upfront and only use estimated for approximate planning.
Estimates are otherwise worthless in this scenario.
Instead, make a call on “feature completeness”, “quality”, resources working on the solution, budget, and what other work can be dropped.
And always assume when hitting deadlines developers are going to work at least 25% more hours than a standard work day.
(The only think more stressful to a developer than an estimate, is a deadline.)

Otherwise, if you want an estimate then treat is as a “rough idea”.
Assume the plan and schedule will change.
Don’t create any business critical plans against it.
And ensure the work is not part of something that has deadlines.


Bonus: How many hours can a software developer work behind a keyboard?

Software development is hard work.
It’s mentally and physically exhausting and requires a lot of stamina, especially over a long term, and especially of a term of sustained effort.

My rule of thumb is:

In a standard 8 hours work day, assume a maximum of 6 hours behind the keyboard.

That’s an absolute maximum. It’s not going to be every day. And that’s if you want quality work.

Remember to factor in things that take people away from the keyboard:

  • Meetings
  • Planning sessions (eg. at a whiteboard).
  • Coffee breaks and water cooler chats (essential for workplace productivity, and often a source of ideas and inspiration).
  • General break to clear the mind.

But software development is not about being behind a keyword and writing code. A huge percentage of it is thinking and learning/research.

Software development is not factory line work and cannot be thought of the same way in terms of output. It is creative and analytical.

And not every day is going to be the same.
Some days a developer will be in “flow” (a mental state when they are churning out code in a easy, satisfying way).
Some days personal life may be making them a bit flat.
Some days they will be battling technology gremlins.
Some days in their flow they will punch out a solid 10 hours of work.
The next day they’re fried and admin tasks or a bit of learning is the best you can hope for.

Software developers are people.
Not machines.
Not “resources”.
People with brains and bodies and lives like everyone else, who have the same ebbs and flows and worries and energy as everyone else.