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.
With context switching - I use a hybrid of GTD, instead a single system for all your tasks I have a separate GTD for each project.
Part of the reason I do that is privacy. If I’m hit by a bus, all my projects won’t die with me. They’ll just be handed over to someone else… and it would really help if that other person has access to all my notes. But I don’t want them to have access to literally all my notes, just the ones relevant to them.
I’ve never been hit by a bus, but I have occasionally decided to stop managing a project before it’s finished. And being able to simply hand everything over to another person has allowed me to do that in situations where I would have otherwise been compelled to keep working on something I don’t want to work on. For me, the ability to hand off a project easily is critical.
Just try to use Joplin or Obsidian with tasks plugin for that.
Those are far too restrictive. Outlines are a great tool, but they are not the right tool for every job. The best thing about GTD is flexibility - you can do whatever works for you and the project at hand.
Personally I use a folder. Sometimes that’s a digital folder on a cloud service, or sometimes it’s a dead-tree folder.
Restrictiveness depends on page content and tasks realisation. I’ve tried different GTD software and always end up with outliner with tasks functions. Because you can’t pass whole context in task name only (which sometimes also limited in char count).
Currently I collect all my tasks from various JIRAs, Redmines and other trackers in Joplin, with repeating todos plugin it also helps me to track tasks like “check mitre for new cves in used software weekly”. I have good template for such task notes that keep all needed context for me when task repeats, e.g. a note to check on next repeat specific software for update. Agenda plugin shows (over)due tasks in sidebar so they’re always on track. You can do similar with Obsidian also, I just do not like it’s editor :).
BTW this is exactly why managers love JIRA and Confluence with their integration in each other. Feature’s wiki page will eventually contains links to tasks for neccessary context information.
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.
Add comment