29 docs tagged with "learning"

by Mike Cohn

This book is great for those coming from Monolithic architectures (pretty much everyone, originally) and baby-stepping through the reasons why you may want to move services to a more micro level. It is definitely written from a pro-microservices standpoint, but refrains from being preachy.

by Robert C. Martin

This book is a window to a future you, wisened by years or decades of experience. Any time you can find that window, open it.

This book is completely different from other management books, but also seemingly the same. It builds on concepts you definitely know, simple ones, but presents them in an easy-to-follow and highly tactical fashion, one at a time, then brings it all together into one simple but powerful package.

This book is my favorite management book to date. Perhaps it is just me, but this book spoke to me in greater fashion than others. Others had situations that felt familiar, but not exact. This book felt dead on 100% of the time, which made it all the more powerful.

For every issue you encounter in code, you are likely implementing one of these patterns, but this book gives it a name, and you awareness of that fact.

I am not sure I really recommend this book, but for someone who asks the exact above question ("What do other people experience when managing software people?"), it would be hard to beat just a ton of interviews in a book, which this is.

This book talks through the specifics of management at the highest levels, but gets there by steadily moving up levels of complexity. This, combined with solid analogies, paints a simple to understand picture and gives direction of where to head.

Event-driven architectures are likely going to drive the future of architecture design, at least in the intermediate term. Centralizing has advantages, and this book dives deep into them.

by Henrik Kniberg (Author), Mattias Skarin (Contributor)

This book focuses near entirely on communcation: Authentic, vulnerable communcation and exactly how to achieve it

This book is a good summary of all of the possible situations you will encounter as a Software Engineering Manager, and contains tidbits of how best to handle each.

This book approaches Software Management from a different perspective from the others, looking at it more from the perspective of incremental improvement rather than high-level strategies. Both are very helpful.

If you have an interest in being the best coder you can be, you have to have familiarity with algorithms. This is the best introduction to why that is that I have found.

This book provides what in some organizations may be a radical idea: actually saying what you think. This provides benefits for both recipient and deliverant, even if it increases some awkwardness.

Using key-value stores are all about consistency (as is any database actually, but simple databases are far less forgiving of inconsistencies). This book establishes reasonable, practiced patterns that will help you from making simple mistakes in your data modeling journey.

This book centers on how more people can actually get less work done, and strategies to ensure that does not occur.

If you have a keen interest in Software Architecture, it's nice to have a dictionary.

I read this when trying to get my hands on as much Architecture knowledge as was available. I'd prioritize this lower on the list than most, but its a decent read.

This book is all about defining the job role behind a Staff Engineer: What are you supposed to focus on? How do you best contribute?

The CDK is a massive timesaver over raw Cloudformation, but even with helpful constructs in place, it takes some getting used to. Reading this book, while taking a few hours, will likely save you more than a few days over the course of time.

Using key-value stores are all about consistency (as is any database actually, but simple databases are far less forgiving of inconsistencies). This book establishes reasonable, practiced patterns that will help you from making simple mistakes in your data modeling journey.

This book presents conflict as a cornerstone of healthy teams, and walks through how to create an environment of trust to encourage this behavior, ultimately improving results.

This book does a decent job at putting what is typically under wraps on display: building a business is hard and often ugly, meaning that you are almost never choosing a right answer, but the least wrong, and you only know 10% of what is required to make a good decision.

This book was extremely helpful in focusing me on what was important in management, and also who I was supposed to be as CTO to all partners, tech and otherwise. This is likely to be true for whatever level you are at as well.

This book provides a lot of data on why major software projects get mis-estimated.

If you care about your craft, you should care about how you craft. This book is about how to care about how you craft, introductory-level.

Jack does a great job of providing a lot of actionable advice in a very easy to understand way. He provides a lot of examples, and a lot of reasons why things are the way they are. I kept feeling like some of his advice wouldn't age well, but he really does a great job of providing timeless advice and even directly addresses that concern frequently.