In my career, I have consumed a lot of content on writing maintainable code, career tips, object orientated programming and DevOps. Some of the resources I have even revisited. This list contains the ones worth recommending.
Assumed Knowledge
To get the most out of these resources you should be comfortable with at least one object orientated programming language and be interested in a career developing software.
If you feel you need to brush up on some of your Java skills for some of the resources I would recommend Learn Java with these Resources, which are the resources I used and recommend.
Resources
The following resources can be consumed at any time and in any order.
Clean Code - Bob Martin
One of the classics, this book gets you thinking in the right direction when it comes to designing software that is reusable, maintainable, flexible and scalable. I found the explanation of TDD to be particularly useful.
- Type: Book
- Length: ~250 pages
- Language: Java
- Note: I skipped chapters >= 16
- My key take-aways:
- later = never
- comments tend to a lie after a while
- unit tests make our code more flexible
- write dirty code and then clean in
Clean Code Video Series - Bob Martin
After reading Clean Code I can highly recommend watching the video series to make the lessons more concrete, especially the videos on TDD.
- Type: Video
- Length: ~1 hour per video with 10+ videos
- Language: Java
- Note: I skipped the astronomy segments at the beginning of each lesson and the episodes on architecture and BDD.
Clean Coder - Bob Martin
This book gives you a great insight into the Bob Martin’s professional life as a software engineer and is a fun book to read. Full of handy tips for a career in software development.
- Type: Book
- Length: 210 pages
97 things every programmer should know
I enjoyed reading this book and although I didn’t I agree with all of the tips, some of them were really useful. You could read this book over 97 days and it wouldn’t be a problem.
- Type: Video
- Length: 258 pages
- Favourite tips:
- The boy scout rule
- Fulfil your ambitions with open source
- Hard work does not pay off
- Keep the build clean
- Learn foreign languages
- Make the invisible more visible
- Pair program and feel the flow
- Reinvent the wheel often
Head First Design Patterns - E. Freeman et al.
This is a great book for learning about design patterns, design principles and object orientated programming. I wrote my own examples on GitHub to help me consolidate the material.
- Type: Book
- Length: 638 pages
- Language: Java
Accelerate: Building and Scaling High-Performing Technology Organizations - Nicole Forsgren et al.
Want to know what differs high-performing software-delivery teams from low-performing ones? This book answers this question.
- Type: Book
- Length: 257 pages
- Key take-aways:
- Branches should be less than a day’s work
- Highest performing teams have the shortest integration times. Branches typically last hours or a day. Low performers have branches typically lasting days or weeks
- Deployment pain correlates with low performance and low satisfaction
- Gender diverse teams perform better
- Teams that have space to experiment and learn perform better
- Queue theory: As utilisation approaches 100% the speed at which work is completed (lead time) approaches infinity
The Phoenix Project - Gene Kim et al.
This is one of the most exciting books I’ve ever read. It reads like a novel and it is uncanny how realistic it is.
- Type: Book
- Length: 354 pages
- Key take-aways:
- Theory of Constraints: any improvements made anywhere besides the bottleneck are an illusion
- Left unchecked, technical debt will ensure that the only work that gets done is unplanned work
- Until code is in production, no value is actually being generated
- Every industry and company that is not bringing software to the core of their business will be disrupted
The DevOps Handbook - Gene Kim et al.
- Type: Book
- Length: 437 pages
- Key take-aways:
- Interrupting technology workers is easy because the consequences are invisible to almost everyone
- We can introduce tension into our systems by reducing deployment lead times. Introducing tension forces us to improve
- The leader’s role is to create the conditions so their team can discover greatness in their daily work
- 20% of an iteration should be allocated to create positive, user-invisible value (eg. paying down tech debt)
- Do whatever it takes to keep the build green
- Feature branches delay feedback
- Feature toggles enable the decoupling of code deployments and feature releases
- Business metrics should be defined at the earliest stage of feature definition
- If we are not performing user research, the odds are that two-thirds of the features we are building deliver zero or negative value to our organization
- Out-experiment the competition
Timeline:
- August 2020: Added ‘The DevOps Handbook’
- July 2020: Added ‘Accelerate’ and ‘Phoenix Project’
- March 2019: Extracted from Learning Material - Software Development
