You already write great code, and can figure out the latest frameworks. This book isn't about that - it's about everything else. As such, there's very little code inside, meaning everyone from PHP hackers to hardcore embedded C programmers will get a lot out of it.
This book covers 10 topics crucial to being an amazing developer:
Focus on Delivering Results Fix Bugs Efficiently and Cleanly Add Features with Ease Deal With Technical Debt and Slop Play Well With Others Make Technical Decisions Bootstrap a Greenfield System Learn to Write Interview Potential Co-Workers Lead a Team
David Copeland is a programmer and author. He wrote "The Senior Software Engineer" and "Build Awesome Command-Line Applications in Ruby", and has over 16 years of professional development experience. He's managed high-performance, high-traffic systems at LivingSocial, helped build the engineering team at Opower, and worked consulting gigs both large and small. Currently, he's a lead engineer at fashion start-up Stitch Fix, building a platform that will change the retail shopping experience.
The book has some good advice about being a software engineer. Some of them are actually easy to learn or capture if you worked in a well established team with senior engineers. One must keep in mind that every developer is different, teams and companies are different as well.
Unfortunately, this book is riddled with typographical errors and was not sufficiently proofread.
The basic errors, missing words, and in some cases mangled phrases such as "This is a false economy" as opposed to the intended "This is a false dichotomy" increase in frequency in the second half of the book and are common enough to distract from the content itself.
The content itself is occasionally insightful, but most of its recommended practices will be familiar to even junior engineers with a few years of real world work experience.
Overall this book was very helpful as a Junior dev trying to learn how to become more adept at my job. It was succinct and had some very useful ideas and practices that I could easily start incorporating into my career.
Brought it down to 4.5 stars because there were some spelling/grammatical errors which should've been caught before publishing, and I believe this was originally a web-hosted textbook so it had some vestiges from that (i.e. hyperlinks that aren't clickable because it's ink on paper).
All developers should read this, not just Senior Software Engineers. It's written by an engineer for engineers and it's full of great tips for good practice. It's less a coding book and more a "How to be an awesome developer and a great asset to your team" job without being too douchey.
I was tempted to knock off one star though because for how much he goes on about editing and polish in the section about writing, his book has a lot of typos and word mistakes.
I decided to read this after stumbling upon timeline-lang.com, which I thought was chock-full of excellent ideas. Unfortunately the book is extremely basic at best (describing Agile or basic branching strategies), misguided at worst: we're still advising people to read Martin's Clean Code? Eek. We're still advising radicalized devotion to TDD? Oof. There are a few great ideas peppered throughout (I like his categories of slop v debt) but I would skip this one.
This book has a mix of good (while usually obvious) advice, like making code reviews about code, not about a developer, importance of communication, etc. with quite strange announcements. E.g. "if you have unit and acceptance testing you should not (generally speaking) have bugs" -really? Or "deploy the system without QA validation". It seems that the author did a lot of custom coding for a particular customer vs. creating products for many customers.
This book contains a decent amount of insights that also resonate with my experience as a lead engineer. While I think there are some aspects that idealize what a process for releasing features should look like, it sets a pretty good foundation for those that still lack the experience.
Unexpectedly, this book goes over a wide variety of elements to consider and for that I believe it is a good reference for new engineers, and a good reminders for those who are more experienced.
I was pretty surprised at how useful I found this book. I would for sure recommend this to any engineer who is trying to figure out how to go from a junior to senior engineer. Most books in this genre are highly repetitive, but this actually kept a good pace, and was not hitting you over the head with the same idea over an over again.
Majority of the practices mentioned in the book are expected out of all software engineers, not just the senior engineers in the team. Although the practices listed are very familiar, it does not hurt to get reminded of it once in a while.
Sometimes, it is useful to sit back and think, "What am I doing right?". If you can not find that answer yourself, reading the book helps you get an idea.
I’ve read this book being first team lead developer and I must admit, I found a lot of great information for myself. I strongly believe that this is the book every developer should read.
"The difference between general managers and tech leads is that tech leads write code."
While the book seems to be tailored for developing applications for companies who are directly serving its users, it does provide an excellent mindset for software development in general that can be adapted to any project, team, or workflow. It's a practical and realistic "training manual" that describes how aspiring senior software developers or technical leads can efficiently and confidently do their BEST work. The best thing about it is that it's written for developers by a developer who sounds like he really knows what he's talking about and which makes the book easy to relate to.
It tackles both the "hard" skills (ex. TDD, clean coding, workflow conventions, collective ownership, bootstrapping an app, code reviews, deployment, etc.) and the "soft" skills (ex. communicating with non-technical people, project planning, progress reporting, working with a team, writing, etc.), which are both essential to becoming an effective technical lead. It also clearly emphasizes the concept that developing software has two parts: "getting it to work" and "doing it right".
[UPDATED] The only reason I'm not giving it 5 stars is that the 2nd half of the book has some grammatical and spelling errors (which is unfortunate since a chapter of the book is dedicated to improving writing skills). Nonetheless, it's a MUST read for any software engineer. (It seems the errors I found were due to some conversion/formatting glitches of the .mobi format when loaded on an Amazon Kindle Paperwhite. There's no reason now to not give it 5 stars.)
If you are a mid-level developer aspiring to become a senior developer you should read this book.
It is written by the developer and for developers. It explains some essential skills for those of us, who want to become better software developers. The book teaches you e.g. (I will mention here things that I found most valuable for me): *the importance of focusing on delivering results: I always knew this but now I e.g. when discussing my progress with my boss I try to mention only things that are of business value to him. I don't brag about working hard if it doesn't translate into tangible results *how to fix bugs efficiently: It stresses the resemblance of this process to Test Driven Development. It was a known subject to me but now I see how important is the first step of debugging: deeply understanding the problem before getting to fix it *what process to follow (with detailed steps mentioned) when you want to add a feature to your application: The process explained very clear. I even used it before but what I learned was how important it is to not only understand the problem but also understand the system before moving on to other steps of adding a new feature. Until reading the book I didn't discern those 2 steps so clearly. I treated them as one step what caused some problems. *how to deal with technical debt: interesting distinction between technical debt and slop and when to fix each one *how to communicate with others, especially nontechnical employees: great analogy of communicating with nontechnical people to exposing API *how to start a development of a new system: now I see how complex this process is
If anything I mentioned rings a bell with you, read this book.
The Senior Software Engineer is a great handbook for engineers looking to grow more into a senior role. It's chock full of tips and tricks and even workarounds to improve not just your life, but the lives of those working around you as well. As expected, it's much less about coding practices than it is about being a better person when working on a project with a team. It was a great, (somewhat) quick read for me, and definitely is a highly recommended book, but I chose three stars because it didn't feel too special to me. As I got through more and more chapters, Copeland's writing seemed to me like he was droning on a bit. Despite all that, I still stand by the statement that this book is a very important read for any engineer!
The book left me with mixed feelings. It does offer some good advice, but also at times feels vague or too abstract. Often I felt like I would have grasped the concepts with less repetition – maybe it could have used more copyediting? "Before deploying into production, it might be a good idea to involve the QA team. If the changes are not crucial, the QA team might not be needed. It might still be a good idea to involve someone from the QA team in the mail loop", etc. It's absolutely not a bad book, but at the same time I feel like it could have been much more. Perhaps with an approach more along the lines of "I know this stuff - do this, don't do that unless you're stupid".
it's a must-read for every software engineer who wants to do a better job. just the needed best practices that we must learn by experience and trial and error, nicely summarized.
The book enlists and explains a set of desirable behaviors for a senior software engineer. The behaviors will make the engineers highly effective in their work. I agree with most of the points in the book. But I did not find anything new to learn from this book. As a software engineer moves from junior to senior level, his experience teaches him a lot. The author has captured all his experiences in the book. If you are a software developer with 5-7 years of work experience, then you should have already learnt these behaviors. If you are a senior software engineer, then you should have already demonstrating these behaviors. If you are just starting out, then you may not be able to appreciate all the desired behaviors. The intended audience for this book is a tiny minority of developers who have worked for a couple of years, but yet to master all the skills required to move to the next level. If you are a senior developer, then you will find nothing new to learn from this book. The author could have also done a better job in enriching the content. If you are a fast reader, you can easily cover the book in a few hours.