What's the hands down best book for a mid level start up software engineer that wants to become a great senior engineer.
Posted by michaelcosmos@reddit | ExperiencedDevs | View on Reddit | 86 comments
I'm 30 percent of the way through the Staff Engineer book by Will Larson and it's filled with great advice for seniors wanting to become staff, but it doesn't seem that useful for this lower level transition. Any recommendations?
Claude and Google seem to only recommend books with similar titles. I don't want to spend the money and time on such a book, just to realize 1/3 of the way through that it's a premature read.
Mind you, I think system design and software engineering fundamentals are strong but could still be improved so I was thinking about just putting in the time to finish Designing Data Intensive Applications instead. Any recommendations would be appreciated.
disposepriority@reddit
A book really won't make you a senior, I have seen many times mid-level developers with a higher "coding skill" than some seniors.
In most companies that have a serious number of developers seniority is very much related to your ability to speak to stakeholders, create coherent and succinct writeups, train/mentor people and you surely see how there's a pattern where all of this is leaning on the communications side of stuff.
Obviously, you will occasionally get the ultra savant nerd who barely speaks to people but is responsible for some extremely critical piece of (overengineered) software, especially at startups.
That being said, the the book you mentioned is an excellent read (and reread) so it's definitely a go. The best advice that I've been given many years back was to think about the seniors you interact with, some of them probably stand out more than others and are "good seniors" in your book. Think about the qualities that make them stand out to your and try to emulate them or at least get a direction from that.
Cute_Activity7527@reddit
After working with hundreds of ppl over past two decades at f500 companies and not only I can with 100% confidence say that „good seniors” are extremely rare. People who can do the job and do it are plenty. Great engineers are like albino ppl. It will be an amazing story to tell if you meet two in your lifespan.
MathmoKiwi@reddit
Yeah if a person wants to work on all their non-technical skills then I recommend checking out Ethan Evans who I've been listening to lately:
https://youtube.com/@ethanevansvp
Imoa@reddit
Getting continuously better that skills that get a junior hired are just counterintuitively not the skills that get promoted to senior or past that point.
It really does take a talented savant or critical business dependency on a person to neglect that development and keep progressing.
Lechnerin@reddit
DDIA while doing bug tracing. I started reading this when Claude started working lol 😂
Cute_Activity7527@reddit
„How to live an exceptional life”, to become truly great you need something more than just being good at your work.
Visa5e@reddit
Code Complete, Pragmatic Programmer.
HyperDanon@reddit
justUseAnSvm@reddit
"Moral Mazes" or something else about organization psychology.
Senior -> Staff is way more about navigating the system around the code, then the code itself. Yes, you need to be very good technically, but that's not enough.
michaelcosmos@reddit (OP)
I was asking for a recommendation for the mid level to senior transition.
justUseAnSvm@reddit
you should read moral mazes anyway.
The book is what you get when you take a sociologist and point them at a corporation, way more useful than the internal language we all use to describe business, and much higher utility than the cynical takes we read all the time.
Working_on_Writing@reddit
Moral Mazes is really interesting, a lot of it is like reading Game of Thrones. It is a bit long winded however. I'm reading (well audio-booking) Power by Jeffrey Pfeffer at the moment, which covers the same ground in a much more focused way.
justUseAnSvm@reddit
Nice, I'll check out "Power"!
Yea, game of thrones has a couple of plot lines that get really close to the ideas in Moral Mazes, like Ned losing his head by acting honorably, there's a story about a Nuclear Engineer losing their job for raising issues in a way that doesn't land with corporate.
To me, moral mazes is says the quiet part out loud: why people act the way they do, what behavior is actually acceptable, and the differences between performing values and acting on the incentives.
Working_on_Writing@reddit
Yeah that's a lot of what Power is about, thought it's focused around leveraging that to gain power. At times it's pretty uncomfortable reading/listening. It's a really dead eye'd look at the world. But there's interesting stuff in there which is career relevant.
WildWinkWeb@reddit
Pragmatic Programer!
slouchingbethlehem@reddit
My recommendation is to always be reading a technical book. But here are some suggestions:
- Fundamentals of Software Architecture
- The Philosophy of Software Design
- The Pragmatic Programmer
- Building Evolutionary Architectures
It also depends on what you do specifically. There are a lot of great timeless books, like the ones above, but one of the most impactful for me personally was Fluent Python, and as a scientific software engineer, it’s something I’ll be returning to for years.
There’s also a great podcast called Book Overflow, hosted by two guys who read a new technical book every week. That’s a great place to get new books to read, especially if you have an O’Reilly subscription.
Ddog78@reddit
Oh man the podcast sounds interesting! Thank you!
poggendorff@reddit
How do they have the time to read a new one each week?!
slouchingbethlehem@reddit
They also break 200+ page books into multiple weeks. The book/week thing is mostly marketing.
SolidDeveloper@reddit
They don’t read it aiming for full comprehension and retention. They do a cursory read, enough to form an opinion and write down some talking points for the podcast.
campbellm@reddit
Indeed, they read for their podcast, not as OP would need to.
talldean@reddit
Debugging Teams. Not code, but soft skills around the job. Would recommend.
Pragmatic Programmer. Older, but still quite good, more into the code.
Code Complete. Much more hands-on into the code.
someone_3lse_@reddit
Is debugging teams cross-culture, so to speak? Or is it a book for Americans?
talldean@reddit
A quick summary:
"Debugging Teams by Brian Fitzpatrick and Ben Collins-Sussman focuses on improving software productivity by fostering collaboration, emphasizing "HRT" (Humility, Respect, and Trust) to replace bad habits. Key themes include treating software development as a team sport, cultivating a healthy, non-poisonous culture, servant leadership, and navigating organizational bureaucracy"
Mostly cross-cultural, although not 100%, depending on where ya are.
WizardofRaz@reddit
Does the team translate well to audiobook format? I want to read more books about software engineering, but so many of them require that you are actually looking at the book and sometimes I don’t have time for that lol.
nonasiandoctor@reddit
It's not debugging Microsoft teams? :p
talldean@reddit
Debugging Teams would make an excellent audiobook. It's not about code, it's basically a book that was originally based on a set of talks that Ben and Fitz gave years ago. Or, it was originally spoken, not written, so that'd work.
WizardofRaz@reddit
Awesome! I figured based off the name, but I appreciate having a firsthand review. Also thanks for understanding my intention from my poor initial comment lol
mrmigu@reddit
Did you manage to find it on audiobook?
dacydergoth@reddit
Agree, soft skills are important.
(So is hanging an Etherwhip in your office)
Veloxious@reddit
ah, the cat5 o' nine tails eh? that'll keep the keyboard warriors in line.
nonasiandoctor@reddit
I think we're up to cat6e
Icy_Accident2769@reddit
I gift a copy of Code Complete to every intern/junior that starts with us. Very good hands on book 100% recommend. Pragmatic Prgramming is a solid one as well 👍
humanguise@reddit
Understanding Distributed Systems, Designing Data-Intensive Applications, and Fundamentals of Software Architecture. Computer Systems: A Programmer's Perspective if you're serious about your craft.
ryan42@reddit
To the people saying soft skills, the current iteration of soft skills required is this
Yes I use AI and I like it very very much, oh yes
Ask manager questions about human decisions or discussions or opinions on process, project or task: - ask Claude, I'm sure Claude can help
Substantial_Ad252@reddit
for me the transition from mid to senior happened due to a deep specialized knowledge and skill in my chose niche, which was java and spring. so that + architecture / code quality is where most of the reading happened. so whatever you specialize in: become an absolute expert in that, care for quality, form an opinion and take more and more ownership.
one of my favorite books is "long lasting software architectures" from dr. lilienthal
campbellm@reddit
Add "Lean Software Design" to the list.
And as you read these, get into as many projects with as much variation as you can; frontend, backend, "devops", different languages, different domains. Whore yourself out to any group that'll have you.
You'll end up working with a lot of different people at different levels and start seeing what the commonalities are. When you can start going above the tech itself to the point where it's just a way to get your job done, things will be a lot easier.
TheTacoInquisition@reddit
Fundamentals of software architecture, pragmatic programmer and the product minded engineer.
The first to get a decent grasp of the things that effect how you can work on a codebase, the second for gaining some insight into how and why things happen in the software lifecycle (it's a little outdated, but still relevant IMO), and the last for thinking in a product engineering way, which is quickly becoming recognised as the fastest way to ship things that matter, which is the whole point of doing the job.
actionerror@reddit
“How to Win Friends and Influence People” by Dale Carnegie
As you climb the ladder, of course technical skills are important, but convincing others to become your advocate and work collaboratively with you will lay down the path towards senior to staff and beyond.
Dazzling_Cherry_6513@reddit
Is it actually a good book though? I’ve wanted to read it but heard mixed things and some say more or less it teaches you when speaking to someone keep saying their name directly or some shit
weirdly_foreign@reddit
it's a good book. you can sum it up as "be nice to people to people and they will like you" which sounds ridiculous, but the book is full of actual examples of how to do that (not in a manipulative way), and reading it will make you notice those opportunities in your day to day, meaning you will be more capable of actually being nice to people. so yes, while the premise is basic, the book actually helps.
Dazzling_Cherry_6513@reddit
that’s a good way to put it! thanks
Zimon112@reddit
I listened to the audio book a few years ago, and it felt incredibly dated. To me it felt like a lengthy book that basically just told me not to be an asshole. Maybe the content was applicable in an era of bossy bosses and tyranni. But today all these things are a given.
Dazzling_Cherry_6513@reddit
basically exactly what I heard lol
Droma-1701@reddit
So many skills "needed" depending on what role you're aiming for and what you already know.. Accelerate by Nicole Forsgren (getting hard to find) for how to build effective engineering teams in a tool and domain context agnostic way. Domain Driven Design by Eric Evans for how to decompose large systems. Head First Design Patterns for standard building blocks for solving common problems. The 30 Day MBA by Collin Barrow on how businesses work at a structural level, as you move away from "code monkey" toward "people leader" you need to understand the goals of those you will work with (and potentially against!). Code Complete for coding best practice Pretty much anything from Martin Fowler's series Same goes for Robert C. Martin... So many more depending where you're focussing and what your team's and company's problems are, but these are where I always point people toward!
Ok_Grape_9236@reddit
No book can teach you what building software in your free time will. The act of solving real problems, ones you chose, ones that matter to you, shapes an engineer in ways no curriculum can replicate.
Always ask: what actually solves the problem? That instinct separates good engineers from great ones.
A senior engineer is someone a team genuinely trusts and respects. I’ve seen both kinds. The ones who speak with authority but say nothing, impressive in the moment, empty in hindsight. And the ones who cut through the noise, pick up the problem, and move. Their solution might be messy. It might not be elegant. But it ships, it works, and the business moves forward. These are often the engineers who get quietly criticised and quietly leave too early.
What you become is your choice.
Start with Designing Data-Intensive Applications. Don’t read it once and shelve it. Read it, build things, hit a wall, and go back. Let a real problem pull you to the right chapter. That’s why it’s considered a holy grail. Not because it’s comprehensive, but because it becomes more true the more experience you bring to it.
Decent_Muffin_7062@reddit
There's a great site called progression.fyi which lists competencies for various levels.
Look at the competencies list for seniors across various orgs.
Eligriv@reddit
For me, you become a senior dev when you understand two things : how to write easy-to-change code and how to help juniors and mid levels on their path to senior.
Easy to change code is the whole point of your role as a dev : at one point you should figure out that it's not about making it work, it's about being able to keep your pace while constantly updating your code. If you don't know what you're doing, you'll end up with a shitty and brittle code base that will make everything take longer and longer.
The way to create easy to change code hasn't really changed since the 2000's, it's not dependent on your stack or anything. So i'd recommand you read the agile guys' writings from 2000-2010, like Kent Beck, Martin Fowler, Micheal Feathers etc.
A lot of things changed with AI-coding, but not this fundamental thing, you'd just have to adapt what you read to the new normal.
VictoryMotel@reddit
Maybe try practice and work instead of looking for easy answers.
TheIdentityRefactor@reddit
I’ve spent 24 years in the defense sector, and I see this 'Gap' all the time. Most books teach you how to be a manager or how to be a staff engineer, but they skip the Identity Refactor required to move from 'implementer' to 'system owner.'
You mentioned Designing Data-Intensive Applications—that's great for the code, but you need a manual for the Social Architecture.
My recommendation: Stop looking for 'Management' books and start looking at 'Systems' books applied to people. I actually just finished a Manifesto on this exact 'Mid-to-Senior' transition logic because I got tired of seeing good engineers stall out. Happy to DM you the link if you want to see the frameworks I used for my teams.
jmfsn@reddit
I'd recommend 3 different non-technical ones: The ropes to skip and the ropes to know, The goal, 7 habits of highly effective people.
Also, focus on incident reports reviews. Any intelligent person starts noticing the failure patterns after seeing enough of those if they are reasonable enough.
SSJxDEADPOOLx@reddit
Modern Software Engineering. Its a required reading for each of my direct reports regardless of rank. Dave Farley is bloody brilliant
throwaway_0x90@reddit
Impossible to say right now since what it means to be a "senior swe" is being redefined.
johny_james@reddit
Just to mention here, senior swe is not someone who understands distributed systems, that does not make you a senior.
michaelcosmos@reddit (OP)
If AI redefining our career wasn't a factor, what would you recommend.
anotherleftistbot@reddit
Job hopping
michaelcosmos@reddit (OP)
I just started at this company as a midl level engineer. I didn't ask this question because I thought I deserved a senior position already. I was asking because I would like to learn what type of work I should take and what I should focus on to become ready for a senior engineer position.
Conscious_Trust5048@reddit
Job hopping isn't the wrong answer though. You learn a lot from seeing different problems and how different teams handle them
Deaths_Intern@reddit
You learn more by sticking around somewhere long enough to see how the consequences of your own decisions impact the business's bottom line.
anotherleftistbot@reddit
I agree. Job hop the shitty jobs. Learn. Stay for a good one. Learn more.
Deaths_Intern@reddit
Yeah exactly. You gotta find the one worth sticking with first
skidmark_zuckerberg@reddit
AI removes the need to code. What’s left? Systems design and project management if I had to guess. Which is sorta what a senior role entails now anyway. Idk about anyone else, but as a Senior less than 30% of my week was coding. The other 70% was requirements gathering, demos, scrum meetings, code reviews, aligning goals with other teams, and defining and refining a litany of things with a PO.
BringBackManaPots@reddit
I mean like 80% of the job is left after coding. Even more if you're leading people or product design
throwaway_0x90@reddit
Hmm.... well assuming AI did not exist, IMHO a senior SWE is not married to any particular tech stack or programming language. They just solve problems abstractly. They don't need to have all the answers memorized, but they should know where to go find the answers.
And there are many kinds of software engineers that could demand a very different skill set.
So I don't think there's any one book to be honest.
dacydergoth@reddit
This is why I recommend books on the meta - how to think about thinking. Those are all distilled wisdom, but distilling wisdom is also a learnable skill
udontaskdumbquestion@reddit
What books would those be?
dacydergoth@reddit
"Use your head" by Buzan would be one.
The docs on Capability Maturity Models also
MVanderloo@reddit
I think the cost/benefit of different operations is changing, but the fundamentals stay the same. I believe books that approach concepts from first principles will remain just as valuable
irishfury0@reddit
Code Complete 2
Diagnostician@reddit
DDIA, good birdseye view and very helpful when coming from start-ups
AI Engineering by Chip Huyen, ai isn’t going anywhere, ride the wave
x-jhp-x@reddit
I think the best answer is: all of them! Keep learning! I still am!
If you haven't read it, 'Numerical Recipes in C' is maybe my most referenced book. The license is terrible, as is the code, but:
1) The ideas and some of the logic behind it is amazing
2) Because the license was so terrible, there's now a better implementation of everything in that book, but almost all of them and the related papers will cite Numerical Recipes in C. I suppose it is much easier to do research now with chatgpt, but it was nice to have a centralized item to search for when looking for papers on certain algorithms.
I've spent a lot of time both learning about different ways to decompose matrices & implementing those algorithms for different reasons, and the book goes over that too. It's definitely great for image processing, and it is pretty central to a lot of graph theory as well, if you do any work in that area. I've used wavelet filters at a few different jobs too, although I have a couple of other textbooks for that...
"The Art of Electronics" by Horrowitz and Hill is considered essential for EE, and if you read it cover to cover, you can easily jump into something like KiCad & make your own PCB.
Knuth's "The Art of Computer Programming" is also a classic if you haven't read it yet. I had a lot of difficulty with the original, but everything started to click for me when I tried the new // abridged version with MMIX (the 64 bit arch). It was a lot of fun to muse through some of the examples throughout the day.
sharpcoder29@reddit
The book is called working in your job and paying attention.
michaelcosmos@reddit (OP)
Such a strange and vindictive response to someone who might want to read a book in addition to doing those things.
Normal-Humor2220@reddit
I did not enjoy Larson's Staff Engineer book at all. Too much narrow advice specific to the org structure of a certain type of company. Very little about actual engineering. As an experienced engineer in startups, I found myself wondering what planet the the guy was from; it felt alien to me and I could not relate.
I liked "The Missing README" by Chris Riccomini and Dmitriy Ryaboy much better. It's advertised as a book for new engineers but I found it useful even with two decades of experience.
suborder-serpentes@reddit
My copy just came today, but a more senior than me senior engineer recommended a book called Adaptive Software Development by Highsmith. He said that this book even changed his views toward politics, let alone team dynamics.
bestjaegerpilot@reddit
there is no book --- just do
CriticalOfBarns@reddit
That’s kind of a non-answer but also probably the most accurate. I commonly equate it to being a musician: you can learn to play an instrument by yourself, but you’re never going to learn to play in a band without other people. Obviously you can learn to “code” alone, and sure some solo devs have made insanely impressive things; but, for the majority of us, you’ll improve your skills much faster and broader by surrounding yourself with more skilled people.
bestjaegerpilot@reddit
so do with other people
i can count with my fingers the number of software engineer books that were relevant. For most, "those that can't do, teach" applies---either cash grabs or riddled with errors
montdidier@reddit
Donkey Developer, Unicorn Engineer.
ramenAtMidnight@reddit
Depends on where you work. If you’re in a big tech with many teams and internal products, read A Philosophy of Software Design by Ousterhout. If you’re at a startup, just read Product/Business books relevant to your company and keep doing what you’re doing.
Larson’s Staff Engineer is cool but I don’t think you would get much leverage out of it *yet*. Designing Data Intensive Applications is also cool, but very limited in terms of practice. If you’re not alread a Senior in a big tech, you won’t get to do all that stuff either.
ziksy9@reddit
You need to just experience a breathing software machine. A book isn't going to teach you that.
It gets bigger, you replace things. You keep it running while you do open heart surgery.
A system that you are afraid to change is already broken. You must have tests, it must cover the change, and it must be able to run in production side by side to prove it without a glitch.
Then you swap it.... Slowly. Migrate traffic.
The book might have some basic ideas, but it's your job to know how they apply.
Then you cut the edges... Drop support for random shit. Make it a client lib and version it.
Harden your core proposition, and push the rest aside. You are there to make money for the company.
The books gloss over this mostly. It's one of the most important parts of your job.
Then the process begins again. That's a living, breathing, supported core domain.
This is experienced devs right?
28y+ seeing this working. Decade in FAANG, 5+ F500, plus contracts, etc.
If it's not "breathing" it's dead.
moreVCAs@reddit
i was gonna suggest DDIA after reading the post headline, so that’s one vote from me.
dbxp@reddit
Designing Data Intensive Applications is a nice overview of a bunch of enterprise technical topics however I don't think the separation between mid and senior is so much on the technical side.
Maybe have a look at The Clean Coder, it's more on the soft skills side which I tend to find is more of the differentiator between mid and senior. It's all about weighing up priorities, risk etc. Working Effectively with Legacy Code may be worth a look too, whilst it is technical it's all about managing risk in a live system not some theoretical or greenfield system.
dacydergoth@reddit
Use your Head by Tony Buzan
It makes you think about thinking
dacydergoth@reddit
Also read up on the Capability Maturity Model for software teams.
CMMs in general are interesting ways to think about problems.
michaelcosmos@reddit (OP)
I appreciate the recommendation. Sounds interesting.