There are a few concepts/principles in software engineering that are over-emphasised and prioritised without enough actual thinking.

• Time to first byte
• DRY
• A really amazing to read commit history

Teams will introduce elaborate software development process, stop all conversations & thinking, bring weird and wonderful tech choices all to accommodate these things.

They do have some value but people love to obsess over them without ever thinking about the costs.

Time to first byte

This is very important, we want our websites to respond quickly when our user first reaches them.

What happens

• Build an SPA with a framework released last month so that we can continue to shovel 12mb of useless resources at a user.
• Website still performs terribly but at least something appears quickly!
• Endless rewrites, messing around with build/packaging tools
• Website doesn't work without Javascript.

What you should do

The performance of your website is more complicated than just one metric and by over-emphasising time to first byte you could be harming everything else.

Think about:

• Total number of requests
• Size of resources
• CPU impact of executing JS
• How cacheable it is

DRY

DRY (don't repeat yourself) is when you take some repeated code and refactor it into a function/class/interface/whatever so it can be re-used elsewhere.

Repeating code is annoying and can be wasteful. If you want to fix a bug and you have repeated code that would be sad.

What happens

• Weird Frankenstein functions/classes with optional arguments or boolean flags passed in to concepts that are loosely related, but are not really.
• INTENSE COUPLING

What you should do

• If a concept is shared by more than 2 things, you can probably safely refactor. Just hold off. Someone clever said bad abstractions are worse than none. Wait until it is clear that there is something really there to DRY up.
• If you end up adding flags to functions to make them behave differently, that is a red-flag.
• When making a simple change, do lots of tests fail? Lots of compilation problems? That's usually an indicator of tight-couping and that is often born from engineers worrying too much about making DRY code.
• Acknowledge that making re-usable code is difficult and risky. Multiply this by 10 for re-usable services.

A really amazing to read commit history

We want it so that people can look at a git history to have an idea of the motivations behind the changes in a project.

We will typically not accept changes directly into master but instead insist on carefully crafted pull requests that get evaluated before being merged.

What happens

• Actually shipping software becomes an insane discussion full of bike-shedding. Pull requests lasting days, weeks for the most trivial of changes that should've been released yesterday.
• Job ads still hilariously saying that they practice continuous integration, meanwhile the devs have a tremendous time dealing with merge conflicts or just flat-out scared to change the code because of competing pull requests.
• Still no one has any actual hope of understanding the code base just from looking at the git history, because of course you cant. You understand a code base by reading it and changing it.

What you should do

• Good, descriptive tests.
• Pair programming.
• Try out ADRs.
• Actually talk to each other, build a team.

There are caveats to this. For a distributed team pull requests make sense as they aid conversations etc. You acknowledge that the constraints on this kind of approach means you will iterate slower than other teams.

If you are in a colocated team who want to build and iterate on a product quickly this kind of approach is extremely wasteful. Just push to master as quickly as you can and talk to each other.