Here at eMoney Advisor, we believe in constantly learning and improving our software development skills. One way in which we do so is via a weekly technical reading group discussion. Even though ad-hoc technical discussions do (and should!) take place, our reading group gives developers, QA, and business folks an opportunity to talk software. Reading technical books keeps us hip to new techniques and skills that we can use to improve our craft. Also, meeting up gives us a chance to chat and bond with fellow employees we don’t see on a day-to-day basis.
Here’s how our reading group works. We ask all the devs if they have any book suggestions. Then we have a vote and the highest voted book is the one we read. We order physical copies for anyone interested, as well as eBook versions for those who don’t wish to kill trees.
Each week, we assign a few chapters from the book for people to read before coming to the discussion. Everyone who attends the discussion is expected to have read the chapters. We also determine a moderator to lead the discussion for that week. During lunch, we eat and discuss the assigned chapters.
The moderator will go through each section of the chapters, highlighting important points and facilitating discussion amongst the group by asking for opinions. We consider if, and how, we can use those points to work better.
At the end of the discussion, a moderator is chosen for next week and we decide how much to read for next time. Often, there will be post-meeting discussion in our #readinggroup Slack channel if people have more to say.
We read technical books in order to continually improve the way we work. Our developers have benefited from reading technical books in a number of ways.
Working Effectively With Legacy Code by Michael Feathers has taught our developers to write pinning tests when working with untested code as to document its current behavior. This gives us confidence in changing untested code. The book has also taught us about looking in our code for seams, places where it makes sense to break out code into smaller methods or classes. This makes our code better organized and more testable.
Practical Object-Oriented Design In Ruby by Sandi Metz (also known as POODR) has taught us to design for changeability. One certain thing about our application is that it will change over time. However, we do not necessarily know what that changes will be. Sandi’s book gives techniques on how to keep our application in a state where it will be easy to change even though we don’t know what the future changes will be. POODR has also taught us about the pitfalls of inheritance and how to use inheritance the way it was intended. Inheritance should be used for specialization and not code reuse.
Continuous Delivery by Jez Humble and David Farley has taught us about the release pipeline and how it’s important to automate as much of our release process as possible. As a result, we started using Octopus Deploy to ease our deployment process. Continuous Delivery talks about the importance of smaller feedback loops and how it saves time to fail a build as soon as possible when an issue is discovered. This inspired us to split our tests into two solutions: one which contains our faster-running unit tests and one which contains our integration tests that take more time to run. When deploying, the unit tests run before the integration tests. If any unit tests fail, we now find out much faster than when we ran both the unit tests AND the integration tests as one group.
Start a reading group today!
If your software organization doesn’t have a reading group, start one. You won’t be sorry. The returns you’ll get from your company’s developers learning about their craft is well worth the investment of an hour each week. Don’t be afraid to start one up! All it takes is a few people and some pizza to get good ideas flowing.
Right now, we are currently reading Growing Object-Oriented Software, Guided By Tests by Steve Freeman and Nat Pryce.