Growing Object-Oriented Software Guided By Tests is an early text on TDD. Since it was published in 2010, the code samples are fairly dated, but the essence of TDD is there to be expressed. So, you need to look past some of the specific listings since their choice of libraries (JUnit, jMock, and something called Window Licker I had never heard of) seem to have fallen out of favor. Instead, focus on the listings where they show all of the steps and how their code evolved through building out each individual item. It’s sort of as if you are engaged in pair programming with the book, in that you see the thought process and those intermediate steps that would never show up in a commit history, sort of like this old post on refactoring but with the code intermixed.
This would have been mind blowing stuff to me in 2010, however the march of time seems to have moved three of the five parts of the book into ‘correct but commonly known’ territory. The last two parts cover what people are still having trouble with when doing TDD.
Part 4 of the book really spoke to me. It is an anti-pattern listing describing ways they had seen TDD go off the rails and options for how to try to deal with each of those issues. Some of the anti-patterns were architectural like singletons, some were specific technical ideas like patterns for making test data, and some were more social in terms of how to write the tests to make the more readable or create better failure messages.
Part 5 covers some advanced topics like how to write tests for threads or asynchronous code. I haven’t had a chance to try the strategies they are showing but they do look better than the ways I had coped with these problems in the past. There is also an awesome appendix on how to write a hamcrest matcher which when I’ve had to do it in the past was more difficult to to do the first time than it would look.
Overall if you are doing TDD and are running into issues, checking out part 4 of this book could easily help you immediately. Reading parts 1 through 3 is still a great introduction to the topic if you aren’t already familiar. I didn’t have a good recommendation book on TDD before and while this isn’t amazing in all respects I would recommend it to someone looking to get started with the ideas.
Amazon Web Services in Action is a great introduction to the basics of AWS. It mostly discusses IaaS services, but touches on some of the PaaS services too. It also covers a good portion of what’s in the Architecting on AWS course if you were considering that. I was hoping for coverage of AWS Lambda, API Gateway and EC2 Container Service but they weren’t included. There were references to when to use AWS Cloudfront but it was never introduced like the other services were.
It’s a very quick read, even though it weighs in about 400 pages. There are lots of detailed examples including specific information about if the example was covered under the free tier of services and how to be sure to roll back everything. Lots of screenshots of consoles and the CLI interface and plenty of code samples of using the various SDKs, mostly in node.
If you are already familiar with AWS this probably isn’t the right book for you. It doesn’t cover the architecture aspect in depth, just simple examples of how to combine the various services. For my taste it doesn’t sufficiently cover how to decide when to use a PaaS solution vs rolling your own at the IaaS level. There is one little chart in the portion covering Elastic Beanstalk about the benefits of it vs other less managed options.
Overall it wasn’t the book I was looking for. But it is the sort of thing that can be helpful to lots of people who want to try and understand how to apply their existing architectural knowledge to the AWS platform.
Zero Bugs and Program Faster by Kate Thompson is a book that’s hard to describe. None of it is a really novel way of looking at creating software but it’s all of those things that you would expect to describe when you think about how to do programming well. It’s a breezy and fun read that is divided into enough small sections that you can read it in however much time you have available.
The book is structured in two parts. The first part is a series of short vignettes about programming. Some of which are more direct, like the chapter on ACID; some are more abstract, like the chapter entitled “The Many Sides of the Elephant.” I appreciated the dual chapters of “Do It Now” and “Do It Later” that are about how you can’t always do it now but you shouldn’t always defer it either. None of it was a mind shattering revelation but it was all solid advice about programming.
The second part is extracts from various programs to demonstrate a lot of different ideas. The code samples in the second part were generally significantly older, mostly in assembly or C. The low level nature of the examples made it more difficult for me to appreciate. Seeing Altair assembly from the 70s that’s notable for being clever and concise won’t help me build a better web service today.
If you are the sort of person who is reading lots of programming books, you will appreciate the book, however you may not get much from it. If you aren’t the kind of person who reads lots of programming books some of the more oblique points may be obscured. I don’t have anything bad to say about it but don’t know who I would recommend the book to.
This is a bit outside of the normal material I write about here, but I felt that it was something that others might appreciate as well. One of my wife’s classmates gave her a copy of Daring Greatly and said that it was part of his inspiration to be in their doctoral program. I’ve always read broadly and tried to find a way to integrate that into my life. I saw this book and wasn’t sure if it was the sort of thing for me, but I decided to read it to find out. I started reading it and maybe a third of the way through I thought to myself, “I’ve read this book before but with the word vulnerability replaced with with word authenticity.” But I kept reading and eventually something started resonating with me.
What resonated was the idea that you need to put yourself out there, give more of yourself to the situation, and say those things you are thinking. You have to do that even if it’s not be easy, because it is important and is part of what separates good from great. The willingness to say something that puts yourself in a vulnerable position to open yourself to those around you takes a bigger commitment than most people are willing to make. People are willing to say the easy thing but not the hard things that require them to push against the structure around them. It’s like the Emperor’s New Clothes, everyone sees something but the incentive structure is put together so they don’t recognize the problem. This book is all about how to structure your own thoughts to be able to push against the structure around you.
There are portions of the book written in an abstract sense and some others that are much more specific. The specific sections contain several manifestos to describe how leaders or parents should behave around those they are responsible for. It puts out there that you may not be perfect but that you strive to be better and hope that everyone else engages with you in trying to be better. Each of the manifestos describes how the person in that situation can open up to those subordinate to them to truly embrace the position they are in.
I’m not sure if this is that profound, or if it found me at the point in my life that had me open to what it was saying. However I felt moved by this. It made me feel that I should push outwards and express my opinions further. I had been expressing myself in some domains, however it is hard to put yourself out there in all areas all of the time. Sometimes you just want to wait and let things happen, but sometimes you need to make things happen. Not in the doing sense but in the living sense, where you can’t just wait for something to happen but need something to progress the situation.
The Mikado Method describes a way to discover how to accomplish a particular refactoring. The method itself asks that you first attempt to do what you want “naively” and identifying the problems with that approach. Then you roll the code base back to the original state in order to tackle one of those problems and iterate on the process until you can begin to resolve the problems in a bottom-up fashion, resulting in multiple small refactorings rather than one big one. This strategy means you can merge or push with the master branch more frequently since the codebase is regularly in a working state. This avoids the rabbit hole of making changes and more changes and never being sure how close you are to having compiling software with a passing test suite again.
The actual description of the technique and examples is only about 60 pages of the roughly 200 pages of the book; most of the rest is other tips and tricks for working on refactoring. There is also a rather long appendix on technical debt that I found expressed some ideas I had been thinking about recently; it describes four techniques for tackling the sources of technical debt.
The four techniques listed are absolve, resolve, solve, and dissolve. Absolve is essentially normalizing the practice and saying it is okay to do things this way. This would be something like lowering the automated test coverage necessary during a hard scheduled push. Resolve is reverting a change in the current processes and environments that had unintended negative effects. This would be something like getting rid of an internal bug bounty if it was being abused. Solving is changing the incentive schemes in order to put groups into alignment. For instance, having development teams on call in order to help align their incentives with the operations teams. Dissolving is the sort of radical solution that completely removes the friction between groups and makes the problem disappear completely. To continue with the previous example this would be a sort of devops culture where operations and developers are all on the same team and there is less distinction between the two. Each of these techniques could be applied to various means that create technical debt, or even to other sorts of problems.
The actual Mikado technique doesn’t seem book-worthy in the sense that it isn’t complex enough to warrant an entire book on it’s own. The other refactoring techniques weren’t anything particularly novel to people who are already familiar with Refactoring Legacy Code or other similar material. Overall it was a quick read and enjoyable but not the sort of thing I would be recommending to others strongly.
The Senior Software Engineer by David Bryant Copeland is a manual for being a Senior Engineer and covers all of the things nobody bothered to tell you about. For me, it’s all of those things that I put together from reading dozens of blog posts and watching those senior to me do the job. Most of the book was the description of what the role is and describes it in sufficient detail to help an engineer who has not yet achieved the role to target the experience to show they can do the job. It is the sort of description of the role I would have liked to have gotten from a manager early in my career.
Since I’ve been doing the job of a Senior Engineer for years now, most of it wasn’t particularly novel to me. However, I would have liked to read this before I made the transition to Senior Engineer. It differentiates between building a new feature, fixing bugs, and solving problems, which are what I would describe as the three main technical components of being a Senior Engineer. It also describes quality technical writing, working with others, making technical decisions, interviewing job applicants, and leading a team.
Interviewing is probably one of the most critical areas that you don’t get a lot of exposure to before becoming a Senior Engineer, and it’s pretty well covered here. Copeland lists four components to the technical interview (in order):
- Informal get-to-know-you conversation
- Homework assignment
- Technical phone screen
- Pair Program
It seems like the phone screen should go before the homework assignment, especially if the assignment won’t be the focus during the phone screen. I actually interviewed at a place where the author was working some years ago and the interview was significantly different than what he described. There was no informal conversation, no homework assignment, and no pair programming. There was a phone screen and a white boarding session. I suppose he may not have had total control of the process there but it is interesting to see the difference between the ideal and the actualized.
If you are looking to become a Senior Engineer and get a grasp of all of the aspects of the job before trying it, this would be a good read for you. If you are a Senior Engineer I’d pass and try something else. It might also be good read if you are a manager and looking to find a way to articulate some of these ideas to your junior team members.
Flow by Mihaly Csikszentmihalyi is about the psychology of optimal experience. Optimal experience is the idea that the perception of an experience is more important to your enjoyment than the nature of the experience itself. The popular conception of the book I had gotten was about how to produce a flow state and therefore be more productive. That was part of the book, but the reality of the concept was much more complex than I realized. The eight components that are used to describe a flow activity are:
- An achievable task
- Clear goals
- Immediate feedback
- The activity has enough depth to take up your full attention
- A sense of control over your actions
- Loss of sense of self
- Time dilation
Some of these components are things you can control to try to induce flow (1-6), and some of them (7 and 8) are what you experience under flow. Not all flow experiences have every component, and just because you meet the first six items it doesn’t mean you will have achieve flow. Flow is an enjoyable state but not all enjoyable experiences are flow eligible; you don’t achieve flow watching TV, it is a passive action not something you actively engage with.
The book was more about understanding that flow appears in any place that you achieve deep satisfaction than about exactly how to achieve it. Flow can be in the way you can lose yourself in any significant activity: playing sports, spending time with your family, at work, or overcoming adversity. It isn’t that flow creates satisfaction or activities that cause satisfaction have the innate ability to create flow. It is about the underlying way that your mind process experiences and what that means for building a satisfying life. There is significantly more to the book than a way to increase focus on an activity. It could almost be described as a philosophical text on the meaning of enjoyment in the human experience.
There was a section discussing the flow that some people found in overcoming adversity. There was a story of a man who found life after losing the use of his legs to be more satisfying since he stopped to recalibrate his expectations and found enjoyment in the challenge of living everyday life. There were other similar stories of those who overcame hardship and found flow in doing so. From a logical perspective there isn’t a way to see losing your vision as a positive, but there were accounts of people who did.
Since the book wasn’t what I was expecting, I feel like I need more time to digest what was there and what it means to me. The philosophical aspect of it reads much more deeply than most of what I normally read; even when it was prescriptive it was less concrete and more aspirational. I picked up a copy of another of his books, Finding Flow, which seems like it is more practical. I hope that I can take away more of the specifics of this on how you can live a more fulfilling life.
Scala for the Impatient is a reaction to the heft of Programming Scala. It recognized that Programming in Scala was a great resource but weighed in at 800+ pages and that it may make a better reference than introductory text. Scala for the Impatient attempts to capture the bulk of the value at a much slimmer 340 pages. Having not read Programming in Scala I can’t say if it captures the bulk of the value, but it does provide an amazing introduction to Scala.
The each chapter is labeled with a Scala level to give you an idea of how complex the topic is. This helped me since I could see that the chapter on implicits was labeled L3, the most complex level, and that most of the time you don’t need a feature like this. That helped signal to me that it was okay that I didn’t fully understand how to apply the topic right after reading, while I’m still a relative newcomer to Scala. I haven’t wanted to write any implicits so far, since I haven’t been writing anything too complex. But, it still helped when I saw some implicits in library code I’ve gone into; I have been able to follow along, although I don’t fully understand why the code needed to be put together that way.
I had issues with some of the exercises. There were some that asked you to think about why something was written in a particular manner, but there wasn’t an answer key, so it was impossible to know if you were right. I went searching on the internet and found people discussing the exercises but I would have appreciated a more authoritative and definitive answer. There were also places where it asked you to implement something, where it clearly meant for you to use some particular feature that was discussed in the chapter, but it wasn’t evident how you would implement it using those features.
I really enjoyed the ability to download of all of the example code, and code snippets from the examples. It made it easy to experiment with the example code and see what happens, without having to copy it all over. The errata was helpful, but there was a lot of it and it interrupts the flow of reading the book, but it doesn’t reduce the value of the book. Overall, out of the things I did to start learning Scala it was the most comprehensive. It has been my biggest time investment in deliberate learning for Scala so far and I’m glad I did it. I’ve got a copy of Programming Scala which I intend to get to eventually, but its significant heft may make it wait for a while before I dig into that to give a comparison.
The Phoenix Project is a novelization of an agile transformation at an autoparts company. It is written to show how the transformation helps the whole company and not just the IT department. There is also a resource guide to provide additional details for those inspired to implement agile after having read the book. The novel itself is about Bill, an IT manager who gets promoted up the chain during a series of crises.
Over the course of the novel, Bill learns – through a series of interactions with a guru who had previously helped the company resolve issues with their production lines – how to deal with a failing software development project, a complex system outage, and mundane day-to-day IT tasks like replacing a dead laptop, and he thereby gains control over his work life. Being a novel rather than a normal technical or business book allows it to introduce concepts and show how they are applied. This is beneficial too in breaking a major concept into digestible pieces, since if you look at the entire set of agile practices being suggested, some of them are designed to solve problems that the reader hasn’t necessarily seen yet. The book goes through the learning and rollout processes in a company that was very close to having a complete IT meltdown.
Showing the concepts in action seems to be a powerful way to assist in visualizing for those who have been exposed to the concepts but not necessarily put together what they mean in practice. I found the depiction of the work in progress lesson particularly intriguing since it is always somewhat difficult to understand in the abstract. The work in progress situation was shown through Bill finding that there was one person who was involved in almost everything going on even though most of those things don’t seem related to what the team was doing. Most of the examples are made in a physical production analogy rather than directly discussing the ideas in the software context. It seems to me that the structure was to keep the book from being a single monologue from the guru who is mentoring Bill, but I also think it makes the story more interesting by letting Bill discover the steps on his own. The author shows a bit of self-aware humor, as Bill gripes about the guru’s oblique descriptions in the text.
The target audience seems to be upper management, which makes the story more about leading the change and telling people to do it rather than how the change works for the actual developers. This makes sense to a certain degree, since a bottom-up agile transition is more difficult to do. The management perspective is especially enlightening in the section discussing change control; the company is looking at all of the scheduled changes that aren’t getting done. Bill then asks the insightful question: if we are failing to make hundreds of supposedly important changes a day, why isn’t it causing a problem? It helped them recognize there was a lot of work being considered that, while useful, was not resolving their major issues.
If you are already up on agile stuff from an individual contributor role I would probably pass on the book in favor of something else more immediately relevant. As an agile coach, scrum master, or executive it seems like a useful perspective to add to your portfolio. As a standalone novel it is somewhat dry, since other than Bill and the CEO the characters lack depth and there isn’t much dramatic tension.
Thinking Fast and Slow by Daniel Kahneman is a psychological profile of the two systems of human thought – a topic on which he is one of the pioneering researchers, and for which he shared a Nobel Prize. System 1 is the fast intuitive system that allows you to make snap judgments. System 2 is the slow methodical system that allows you to really dig into the data and do math. The book is mostly about the weaknesses of the two systems and how System 1 can be tricked and System 2 gets tired. The material is presented as a series of experiments mostly paired with an anecdote of how the idea came up. It tries to outline which problems engage which system and why. None of this material is directly applicable to computer programming; however, the understanding of human cognition is useful to understand how you are thinking about problems and hopefully be able to recognize when you should be trying to engage System 2 and when taking the quick answer from System 1 is acceptable.
One of the most interesting experiments to me was one that described how patients rated their pain over time during a procedure and how they rated the experience as a whole afterwards. The goal was to find the relationship between the two of them. The peak level of pain suffered was an obvious component to the whole, the experience towards the end of the procedure also had a strong component. However the total duration of the procedure did not impact the total rating of the experience. This implies that the mind doesn’t remember things based on the duration of the experience. Kahneman suggests that therefore, if you were trying to structure an experience where there will be discomfort, extending the session to make the last part nicer would improve the memory of the whole experience. I’m not sure if this would apply to pulling off bandaids or not.
There was another anecdote that caught my attention, where Kahneman had spent his time in the Israeli Defense Force working on figuring out how to assign incoming recruits to the various branches. The previous method had been a sort of free-form interview relying on the judgement of the interviewers, which had not been overly successful. He designed a new system to try and remove the individual biases of the interviewers from the process. The system he put together had six categories and a fixed set of factual questions for each category. Based on the answers to those questions each category was assigned a rating between one and five then the results were summed to produce an overall evaluation. This produced a significant increase in successful placements over the old system. He also suggests that this theory could be applied to hiring. I’m not certain if that would be a good choice since this was to sort recruits to different types of units, rather than to pick one person from many.
Overall there are thirty-some of these different little experiences that are all drawn together here from Kahneman’s 40+ years of research and quite entertaining. Despite the somewhat dense material, it reads easily and is quite accessible without any sort of former exposure to these sorts of topics. If this sort of thing is interesting to you, he also references other similar books talking in more detail about some of the specific ideas discussed.