Help me choose future topics?
Which theme resonates most with you, and which would you eagerly anticipate reading?
Hey there! I need your help to pull myself out of the TDD rabbit hole (~2 essays left). It’ll be great to see what topics you’re interested in learning or reading about next.
Following my goal to dive more into small yet impactful steps, below are the themes that float around in my head (some might overlap).
Comment with your thoughts or multiple themes; if short on time, take the poll. Your input is invaluable. Thank you!
The Power of Naming
We name things all the time without knowing what good or bad naming would look like. I’m not talking about not using acronyms as variables; this theme is beyond that. Naming has powers, it influences boundaries and could determine trajectories. This may come primarily from stories to start with. I hope to create a framework for naming at some point that may benefit us.
Task Decomposition Patterns
Many software engineers I work with love to work on small steps but struggle to break big things down into < 1/2 day work. Sometimes, I show them how to break it down, and they have a moment of revelation. May connect to productivity improvements, pomodoro, flow state, etc.
Initiative, Influence, Introverts
This theme is about turning that big cloud into raindrops (bigger task than previous theme). Many great engineers I met have high expectations for their team but get frustrated to make the change. Some attribute this to their introversion. I’ll share some of my stories, and case studies, about what works and doesn’t work, broken down into small steps.
Minimal Momentum
I attribute many of my learnings to what I do outside of work, such as reading or working on a pet project, whether reading or shipping. Many engineers I spoke to feel they can’t finish their pet projects. In other words, they have big motivation but they lose their momentum. With the right technique, we can work on something decent with just 10 - 30 minutes a day.
Deliberate Expertise (Research Insights)
Many found their expertise by accident, we can do better by making it deliberate. I’m self-studying some topics and will try to tie this back to our work as software engineers. To give some colour to this theme, this is what I’m currently studying:
Cognitive Psychology. I’m studying a university book and am currently deep in Zettelkastening it. Lots of insights on how to learn and work better.
Science of Expertise: How did I learn TDD? What’s deliberate practice? (lots of misunderstanding out there).
I might tie this back to
‘s Mastering Programming.Science of Habits: What habits? Which bad habits? How do we build/undo it?
: “I'm not a great programmer; I'm just a good programmer with great habits.”Cynefin: Which practice, when, and where?
Expert’s Aside
As I wrote the last theme, I realised I believe in the idea of ‘competency over career’. This means I’d prefer to use the language of novice to expert, rather than junior/grad to lead/staff, etc. This is ironic because the idea of competency is often discussed in the context of a career. More ironically, I also associate the word ‘expert’ with this hilarious video: