TL;DR It's a semi-autobiographical fiction book about a software architect who is involved in programming, debugging, releasing, testing, organizing, team work, and management issues.
Yegor is a CEO at Zerocracy, a software platform for management; a VC at SeedRamp.com; a regular blogger at a proud holder of PMP and OCMEA certifications; a hands-on Java developer and a lead architect of Rultor.com and Takes.org. Yegor lives in Palo Alto, CA and Moscow, Russia.
Amazing book, I learned a lot from it. I might not agree with everything in it, but it makes you think a lot about software development, quality assurance. I really enjoyed reading this book, and I'm looking for the second volume of the book. I'm going to read this book a second time since there are so much knowledge and philosophy to learn and digest.
A very well written and concise book. It reads like a well-researched essay mixed with a bit of novel fiction. It provides you with a plethora of additional resources. I recommend it to anyone that writes code for a living or works with people who write code.
It is a must read! It changes your mind. I liked it very much. There are ideas how to create better processes for your organisation and how to build your career in software development. Development, testing, deployment piplines, delivery - done right. I especially liked the architect role section.
You don't have to agree with everything, but it's very interesting perspective that author shares.
I didn't give this book a review but after some time I decided that the book worth review.
It is very fun and close to the ground explanation of how most companies in the software industry work. You may think, oh, I am not from this book. You are lucky then.
This book put me on fire, made me reconsider our release cycle and continuous integration pipeline. In simple words, it shows how some companies work in the software industry, how to fight with not against the team in the company of 30+ people. It describes certain considerations and forces think hard about testing and why to do. It also shows the right approach for people who are in the industry for a couple of years: to be more pragmatic, to be greedy, to be the professional.
I rarely recommend books but this one, I presented to my CEO, so he could understand why software is not about how fast be in production, but how long will remain in there if leave your software without maintenance (The point being, if put high-quality software in a production it would require little to no maintenance, compared to low-quality analogs). It definitely won't change you but push you to think and reconsider day to day decisions you do as a tech-lead, developer, etc.
"Code Ahead" is an excellent, thought-provoking book. It challenges the current state of software development and suggests interesting alternative. I've been supporting the rationalism of #XDSD and #Zerocracy since the beginning. Great job, Yegor! Keep writing!
And it doesn't matter if you won't agree with some thoughts in this book. It will definitely make you think!
I think it's a good read. I found it very relatable for developers and testers, portraying the industry's best and worst, in a variety of topics from Hiring, Team structures and hierarchies, Project architecture, Quality, Testing. It's not perfect, there are parts that I didn't like and I felt a bit bored, but the way all the inner workings of the industry was captured is very enjoyable. It sets a mood and a story very similar to what we've all been through, or are currently at, in different points in our career in software business.
Even for people who are not fond of the author, I still think for them it's a good read: it's THAT relatable. I do agree that the price is a bit prohibitive, but for me personally it was worth it.
Written in an easy-to-understand way of narration, in the form of one software architect story, who has just joined a new company. From his fresh perspective, he identifies a broad range of issues in management and project organizing, which should be familiar to everybody involved in software development nowadays. Topics like motivation, teamwork and quality are covered as well. The book contains a huge amount of references to other related materials, and, thus, can be considered as an essence of its content filtered through the author's personal opinion and experience. I highly recommend it to all software engineers and testers. It will make you laugh at some points when you realize how typical some situations can be. I am looking forward to the next volume.
The hero of the book is psychopatic son of a bitch and I wish every single one in the industry would think and act like him. 10 Nietschze quotations out of 10.
A great book for programmers. It is actually a "guide" book for programmers, but the way it was done through storytelling and not just stating the solutions to problems is genius and definitely more engaging. By using multiple characters the author also had the option of contradicting what he is presenting through conversations and therefore challenging his opinions and statements. It goes through a lot of different problems a programmer is faced in their careers: interviews, negotiations, onboarding, interpersonal conflict, code quality, code delivery, testing, etc. What I didn't like about the book is that in some areas the author takes a very pessimistic outlook on day-to-day work which I see as demotivating in an otherwise highly educating book. I liked that a lot of the statements found in the book are followed by references to other works of literature and science (a refreshment from some other guide books). I still found some of them unnecessary, and some of them did not even uphold the statement made in the text. (as an example: the fact that in the past year 35% of developers changed work, does not mean that the developers change jobs once a year). Overall, a recommended read. I am looking forward to the next volume as described in the Epilogue.
- Too radical, although have to admit it takes courage to go under well-established rules. Could easily motivate someone to quit his job after reading this book ). - Either we live in a completely different universe, or this is how things are in the US/California, but I hardly worked in any company which didn't have unit/integration testing in place, so seems too unrealistic to describe the case where Dennis was not aware of unit testing at all. But again this is from my experience, maybe Yegor had the different one (unless it has been made just to fit into the story/plot) - References are actually indeed helpful (maybe even more than the text) - I found a few contradictions where in one place it says one thing, and in another one the completely different one, so this puzzles a bit (assuming I understood it all correctly), so the reason one star less - Characters I think are well built, i.e. they look very much familiar to the people in the same positions I met over my career, which is fun ) - Overall this is the compilation of Yegor blog posts, but rather formalized in the fictional story. So if you already read his blogs, you might not find very much new information, so for me reading references was actually is equally or more valuable than the story itself
Still yet to think what could be the immediate actions I can apply from this book?
No es un libro para todos. Habla de muchos temas, es la opinión del autor fundamentada en el estudio y parece que la lectura de muchos otros libros y recursos, sobre el desarrollo de software en general.
Presenta una visión cÃnica del mundo, en el que no deberÃas confiar en las intenciones de las personas y en la que deberÃas buscar trabajar con alguien egoÃsta y ambicioso antes de con alguien que parezca que le importa lo que tú estás haciendo.
1. El proyecto es el patrón, no las personas. 2. Debe haber una persona responsable del diseño del proyecto: esta persona sufrirá las consecuencias por las malas decisiones. Si no hay, alguien responsable nadie tiene incentivos reales para hacer las cosas correctamente. 3. El proyecto se debe proteger a sà mismo contra el mal código: para eso es el pipeline de entrega, las pruebas unitarias y toda la estructura alrededor de esto. 4. Los testers deberÃan ser personas más experimentadas y hábiles que los desarrolladores. Su responsabilidad es *encontrar defectos*, porque probar que el software está libre de errores es imposible. 5. Un área administrativa fuerte es la clave para lograr un buen proyecto. 6. No deberÃas esperar trabajar con "rockstars" para lograr tus metas, debes establecer objetivos y sistemas para que el proyecto logre lo que necesita incluso con trabajadores no tan hábiles.
Tiene muchos otros consejos que pueden ser útiles. Sobre todo, las referencias y recomendaciones son muy valiosas. Si quieres aprender una forma fuerte de trabajar y un lado radical del desarrollo de software te recomiendo mucho este libro.
Yegor es alguien que podrás llegar a odiar, pero por lo menos causará una opinión en ti.
This book reminds me books called The Phoenix Project and The Unicorn Project by Gene Kim in terms of format. I've learned a lot from this book about management and confirm my view about technical decisions, pipeline and quality enforcing tools. I will definitely recommend this book for my software developer, devops, architect friends and my manager as well. Already waiting for volume 2.