The Pragmatic Programmer by Thomas & Hunt - notes on the book (part 2)
Evergreen notes, strategies for moving between projects, feature focus, learning, connection with peers, asking questions, second-order thinking, effective communication
See the first portion of my notes on the book is here.
I’ve discovered Andy Matuschak’s notes recently and ended up copying his knowledge management system almost verbatim. The system is described in a web of densely interlinked, atomic, concept-oriented evergreen notes, often framed as imperative statements.
I use Notion which is a decent substitute for Andy’s own system. I don’t want multiply entities, so the logical consequence is that I won’t copy notes anymore to Engineering Ideas, but will just post direct links to the actual notes in Notion, in the spirit of working with the garage door up.
I will be manually making notes accessible for everyone on the web prior to posting. If you find that some content linked from Engineering Ideas is not accessible, it means I slipped, please let me know and I’ll open the note.
Now, back to ideas from the “The Pragmatic Programmer”.
Strategies for moving between projects and focus areas
Don't spoil a perfectly good program by over-refinement. Move on and let your code work in production for a while.
Implement only top 20% features: Beware of feature bloat. Keep software focused.
Consider learning new and promising technology. Future payoff may be huge. To me, seems like a dubious idea. May be better to focus on new and promising work direction (Solve users' problems, not technology problems)
Practice new programming language or technology to learn it:
Don't learn just from reading. Learn to practice new programming language or technology (e. g. ML). Experiment with different IDEs, OSes. Detour in other domains: UI, cloud ops, ML.
Connect with colleagues outside your company: Participate in a local user group, don't stay isolated.
Examine the architecture with value stream mapping: Whose is the benefit?
Second-order thinking (Optimize the machine, not a cog in it):
What will happen? What will happen after that?
Why this is a problem? Is there an underlying model? How does this model work?
Consider their needs, interests, and capabilities. Ask them afterwards if you assessed their needs well.
Adjust the volume to the listener's preferences.
Proactively invite feedback: ask for questions. Look at non-verbal queues.
Plan what you want to say:
Plan what you want to say in a document, talk, meeting. Ask yourself whether the output communicates the ideas well.
Know the best time to deliver something
Presentation is important:
A document should be good-looking, a presentation well prepared. This increases the chance to get ideas across.
Seek first to understand, then to be understood:
Listen to people first if you want them to listen to you. Turn one-way communication into a dialogue to better make a point.
Thank you for reading!
You can subscribe to new Engineering Ideas via RSS (e. g. using Feedly) or e-mail.