Ask HN: Reading material on how to be a better software engineer?
I’ve gotten to be quite good at the actual coding part after a decade or so of programming. I’m not looking for better code practices, although I’ll obviously still learn and grow there.
What I’m seeking is reading material regarding how to manage project scope, be better team member, converting asks to deliverables, managing expectations from management, enabling team members by opening communication channels across teams, time management, etc.
Any suggested reading material? Preferably books, but excellent blog posts are welcome.
133 comments
[ 3.9 ms ] story [ 216 ms ] threadhttps://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...
https://www.elidedbranches.com/
I don't know if I had recommended these specific books, but they're certainly relevant.
To bring this back to the main topic: For persuasion/negotiation, I prefer Stuart Diamond's "Getting More". For negotiation & communication with a power differential, I'd go for "Nonviolent communication" by Marshall/Rosenberg. (For finding an organization scheme, IDK. GTD is not the worst book. I know of none significantly better, but I also question the nature of a work environment where we drown in tasks. So, maybe Cal Newport's books instead)
“I agree, let's focus on discussing the topic at hand and not constantly bring up ChatGPT in every discussion. There are many other interesting and relevant topics to discuss. Let's keep the conversation diverse and engaging for everyone.”
Peopleware
https://staffeng.com/guides
The Effective Engineer by Edmond Lau - Covers how to focus on what you work on based on the leverage it provides you. http://www.effectiveengineer.com/
+1. Also, Rapid Development, by McConnell[0]. I would say that it's even better than Code Complete.
It would be considered "quaint," these days, but Writing Solid Code[1], by Steve Maguire, was a seminal book in my education. I still use many of the techniques he mentioned.
And I cannot say enough about The Design of Everyday Things, by Don Norman[2]. That book changed my life. I would consider it required reading, for anyone that develops anything that will be used by other humans.
[0] https://www.microsoftpressstore.com/store/rapid-development-...
[1] https://writingsolidcode.com
[2] https://jnd.org/the-design-of-everyday-things-revised-and-ex...
Krug's "Don't Make Me Think", while more UI / UX is a solid compliment to "Everyday Things."
Re: Communication, this book starts there and builds upon that foundation. It’s targeted at line managers, but anyone in a leadership position can and will benefit. For example, I don’t do one-on-one’s with my team. I do “Project Management 1:1’s” or “Weekly project status updates.” I don’t always give feedback the way they prescribe (because the team doesn’t formally report to me). I do, however, go out of my way to say “Just to let you know, when you do X, Y happens.” And from the book, learned that there’s a 10:1 ratio of positive to negative feedback to strive for.
Side note: Manager Tools has a great podcast series that is arranged into a “map of the universe” [1] which shows a huge list of topics, and how to discuss everything from good or bad performance, dealing with various types of conflict, to even how to structure emails or how to address a personal scent issue (which I’ve actually used).
[1] https://www.manager-tools.com/map-of-the-universe
How did that play out?
One of our colleagues took aggressive advantage of the ping pong tables at the office (in the before times) every afternoon after lunch. I’d noticed as had some others. I had a short talk with that person about the fact that in a shared office environment he was essentially showing up post-workout for the balance of the afternoon. I actually don’t recall what changed - but we stopped noticing the issue. I think they just started playing toward the end of the day then just went home after.
https://www.abebooks.com/products/isbn/9780201006506
https://web.mit.edu/6.001/6.037/sicp.pdf
https://nostarch.com/missing-readme
“The Missing README fills in that gap—a distillation of workplace lessons, best practices, and engineering fundamentals that the authors have taught rookie developers at top companies for more than a decade”
Get it just for the “Design Doc” template!
Assorted Non-Book Readings:
- https://randsinrepose.com/dont-skip-this/
- http://www.stilldrinking.org/programming-sucks
- https://sysadvent.blogspot.com/2019/12/day-21-being-kind-to-...
- https://donellameadows.org/archives/leverage-points-places-t...
- https://grugbrain.dev/
- https://changelog.com/posts/rich-hickeys-greatest-hits
- https://github.com/papers-we-love/papers-we-love/blob/master...
- http://www.cs.unc.edu/techreports/86-020.pdf
Books:
- The Phoenix Project: Gene Kim, Kevin Behr, George Spafford
- Deep Work: Cal Newport
- The Art of Leadership: Michael Lopp (Rands)
- Extreme Ownership: Jocko Willink and Leif Babin (once you get through the ho-rah stuff it's a fantastic read)
- Time Management for System Administrators: O'Reilly (fantastic for interrupt driven work)
- Elements of Clojure: Zachary Tellman (not just for Clojure devs)
Deep Work: Cal Newport
What you need to know from this book is that to write good software (both quality and quantity) you need to go deep. You need to fully absorb and understand the problem in your mind, BEFORE you begin writing code. And then, you need quiet undistracted time to map the thoughts in your mind, to code on paper.
This process of turning a mental model in your mind, into a well designed code model, takes more focus than you think (if you want to do it well). Give yourself a quiet room with no visual distractions. Just you, and your code. Set aside a few hours.
Most importantly of all - Remove the possibility in your mind, that a distraction could happen. I cannot emphasize this enough. Your mind will not go deep if, even on a subconscious level, you think a distraction could come. A text message, a spouse walking in, a co-worker asking a question, etc. These all need to be (as reasonably as possible) NOT possible so that your mind can go quiet, and you can take on the work.
Overall, it is also my recommendation, in that when you develop a good habit of churning out quality work, it enhances your contributions to the team.
Of course my all time favorite is The Mythical Man-Month. But that’s already mentioned elsewhere in this thread.
I haven’t read “Drive: The Surprising Truth About What Motivates Us” but some of the concepts it talks about are also of interest (on how to ensure workers are motivated and I’m not talking about “the beatings will continue until morale improves” :) )
For everyone else, I think I've created an interesting backlog of topics, but I'd love any advice about additional topics that would interest folks, how to kickstart an initial audience, what platform to use, how to moderate without losing my mind, and anything else that'd be useful to know doing this kind of thing.
My main topic of interest is how much has changed over time and perhaps what the next 20+ years hold. Such discussions can be eye opening when considering what direction to take, for example, when adopting frameworks and methodologies.
Looking forward to your content.
What are your goals? Just to get your stuff read, help other folks be better engineers, to build a consulting business, to build a recruiting pipeline, something else?
Your goal affects any advice I'd give.
https://youtube.com/@ALifeEngineered
Substack is a popular platform if you want to go longform writing route - see the pragmatic engineer
Even better is learning from people better than me. Video tutorials can help too, especially where seeing output is important.
> Its like reading about math without doing the exercises
But you do learn math from reading and then you practice it to improve your understanding with exercises. It's not an either or. It's both. You should be reading about software development as well as actively improving your code in practice. I don't think you'd get even half as far if you only did one of the two things.
This is such a bizarre point of view that I'm seeing increasingly. "Reading does nothing". Since when?
I am self taught in how to write good code by reading books, watching videos, and reading recommended open source code. I was never in an environment with other great coders who reviewed my code. HN was my guide in how to learn to write better code.
It is possible to be self taught at writing good code.
Code reviews will get you through the start of your career. But as an intermediate software developer, you should be reading and considering new paradigms and practices in relation to your own organizations' practices, and be willing and able to discuss and, if necessary, champion new ideas. And as a senior software developer, or development manager, you should be thinking about how to cultivate a healthy coding culture where those kinds of discussions can and do take place.
The way we code has changed dramatically since the dawn of the PC era, as has the way we manage software development. And it will continue to do so. Even as a junior programmer, you should be cultivating the habit of continuous professional development, seeking reliable sources of professional coding culture on the internet, and reading important new books as they become available.
It's like inventing new math instead of just doing it.
https://web.stanford.edu/~ouster/cgi-bin/book.php
Righting Software
https://rightingsoftware.org/
* Extreme Programming Explained by Kent Beck
* Clean Code and The Clean Coder by Robert C. Martin
* Soft Skills by John Sonmez (1st edition)
* Pragmatic Programmer by Andrew Hunt and David Thomas
* Working Effectively with Legacy Code by Michael Feathers
* The Mythical Man-Month by Frederick Brooks
(Selfish plug) Additionally, I wrote my own book concerning the entire industry, from just starting out to becoming a self employed consultant when you get sick of fulltime work - all soft skills from my decade or so of the industry, as well - https://www.amazon.com/dp/B0B43V1JJW
https://qntm.org/clean
As someone who also recommends against improving developers reading Clean Code, I think the arguments in that piece are generally on point.
There is apparently a large group of people who hate everything he does and also, seemingly, him personally. Everywhere he (or any of his books) is mentioned, the haters come out, with their vague “it’s all bad” and the old standard “I don’t know where to begin”. Serious criticism can be found (if you look for it), and he himself welcomes it, but the constant vague hate is scary to see.
there is a subset of 'clean code' fanatics who treat his work as religious text and tend to produce some of the most bloated unmanagable code bases I've run into
I wouldn't even say his work is valueless but it's a horrible starting point and shouldn't be a destiation
And people misinterpreting and doing bad things (which he would agree is bad), is that his fault?
It's not at all software related but it will make you a better teammate, partner (i.e., client relationship), manager and/or leader.
Technology is the easy part. People, that's the difference between average and above.