As someone involved in software development on the requirements, testing, and project management side, that was the best summary I have ever read about the entire process. I recognize all of the examples of failures/learning experiences and how they can be avoided.

Just a great read, thank you!

Off to see if I can get a few coworkers to read it.

Write things down. It seems like a stupid chore, tedious, boring, and archaic, but it’s the way organizations remember.

I want to add: write things down in a place where everybody can access. For example, make a habit to write issues in GitHub when decisions are made.

Simple, obvious code is easier to write, easier to get to work, easier to understand, and easier to change without breaking it.

Sometimes the simplest code is not immediately obvious. There are often cases where you start to work on what you think is the simple solution, but it turns out it’s more complicated than you initially estimated. At this point, you should know when to take a step back, and try to find alternatives. You might have overlooked a better solution first time around.

I’ve seen this in action too many times in both myself and coworkers. In the worst case a coworker spent many weeks on trying to get a solution to work, when a simple 15 minute solution was available all the time.

As developers team lead I want to sign under every word.

Except GTD. It isn’t working when you became manager, context switching between tasks is a real pain and I recommend to start using outliners with tasks functionality. Every note should be a big task (e.g. epic) with all timelines, links to followup notes and subtasks on it. Only in that case context switching will be a breeze - you just open a note or followup note (or email, whatever) and here you go, after 2 minutes you’re ready to rock!

And don’t forget that new task will fly in every hour or another!

Just try to use Joplin or Obsidian with tasks plugin for that.