Software engineering topics I changed my mind on

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.

I never cease to be surprised when an otherwise intelligent person lays judgment on something they likely do not understand. At larger companies, these types of roles are invaluable. I'm going to charitably that this isn't referring to product management - it's dumb either way though.

Test driven development requires you to have a spec upfront.

When you already have a testable spec, test driven development seems to be a net positive. It can be a good way to explore the spec before building the implementation. At the same time, you shouldn't force yourself to write all of the tests up front; additional tests will typically occur to you as you build the implementation.

If you don't have external factors forcing a spec, I feel that test driven development is a net negative. Forcing a spec up front often requires making decisions before you fully understand the problem. Once you have tests, you have invested in the decisions and are less likely to reconsider them when encountering things that should have influenced the design. On a related note, most interfaces, particularly internal interfaces, should be influenced by the implementation to keep the implementation simple. Building a simple yet comprehensive solution typically requires a full understanding of the problem.

> I grew up with digital tools only.

This implies that you exclusively use digital tools, so my first question would be: have you tried using pen and paper for things?

It's really hard to give compelling examples of where pencil/pen and paper are going to be better than digital tools because everyone is different. If you want to try it out, I recommend simply keeping a pad and a pen at your desk and when you're stuck on a problem try writing something down. Whether it's mapping it out, quickly jotting down some assumption or thing you noticed etc. It won't be suitable for everything but there's something... visceral about writing with a pen that I find indescribably helpful in working through complex problems. This was how I got started with this process, at least.

For a more concrete example, I spend a lot of time in my current role thinking about high-level solutions to problems. Things that need to serve multiple different teams' needs, replace existing solutions (aiming to solve their most obvious pain points), sometimes have non-obvious simple solutions, legacy complex solutions that everyone is used to and just kind of accepts etc. These designs come from months of discussions with different people, thinking, theorising, research into existing solutions etc, but one thing I have found absolutely invaluable throughout this process is the pen and paper on my desk. My notebook is full of unorganised notes that I jotted down when a lightbulb came to me one day, rough sketches or mappings of solution ideas, brainstormed lists of features etc. Most of these don't see the light of day, but as they get refined they move to more permanent, collaborative (as necessary) mediums. I do this progressively by flipping back through my physical notes and reviewing/extending/transferring them as necessary.

I am not sure where you work, but I am surprised that with such a lackadaisical attitude towards attending a meeting, any work gets done at all.

If you have a meeting at 11 AM in the morning, people are supposed to show up on time. Do all your meetings run late? Or does only the standup get this treatment?

Sidenote: if somebody's late > 2 mins, they can join midway or miss the standup altogether, just as is the case with any other meeting.

At the standup, strictly speaking, we give each developer a minute, else the master calls time on them. In a team of 7, that makes the standup 7 minutes long. Typically, people tend to keep their updates short as a way to share what they did yesterday and what they will do today. For any conversations longer than a minute, we take it offline. I have been in companies where this is done via an official master, and other places where we just follow the process ourselves as adults and don't go overboard with updates.

You get back to your desk in I am no standup aficionado, and can't claim to know where you've worked to know the reality virtually everywhere with such confidence, but anybody aware of the process will help you fix it. It appears you've not met such people.

I don't understand this claim of readability. If it were true, then you wouldn't be able to read a code base with a different code style. In truth, the switch takes about 10 seconds for me to get used to. Which is about 10,000 times less that the time I've wasted debating code style with other developers that insist that "consistency" is a useful goal without justification.

There is exactly one concrete goal that I have found. Keeping people's editors from fighting each other in editing the same file. Other than that, just let it go. I've switch everything I can find to the automated formatters so that I never have to listed to someone complain about formatting again.