I recently received my copy of Working Effectivly With Legacy Code and have been busy reading it. The book, as a product of its time, has examples of not only Java, but also C++, probably to show concepts and techniques that apply to languages that behave differently in terms of linking and building. But regardless of its examples not really applying to what I work with, it was full of useful vocabulary and techniques to work with not only legacy systems, but really, any kind of system.
↩ all tags
Pages tagged with "Software Development":
I had this book on my wishlist for quite a while, but never thought I needed it. But then it was warmly recommended to me during a fantastic OOP Workshop with Sandi Metz. If Sandi recommends it, it must be good. Excited to dive into this one:
For the past year or so I’ve been writing a lot of Scala and fallen in love with its Option type and how it allows me to avoid nulls. I reflected on null, why they are bad, and how optional types allow you to write more expressive code. What is null? Most programming languages have the concept of null (or nil) that represents the absence of a given value or object.
I’m currently re-reading Growing Object-Oriented Software, Guided by Tests, and this quote really spoke to me: We should be taught not to wait for inspiration to start a thing. Action always generates inspiration. Inspiration seldom generates action. – Frank Tibolt I think of myself as a perfectionist, the kind of person that hates to produce anything short of flawless. And while this is great quality to have because it drives me to improve and progress, it’s also incredibly crippling and frustrating.
At work we are maintaining several large and complex grails applications. In order to improve stability and reliability, we’re trying to increase test coverage. But as with all projects, time and resources are limited. In order to get a better understanding of what parts of the application are more important than others, I decided to use Graphviz to help me get a better overview of our applications. Meet Graphviz I discovered my love for the dot language when I used it years ago to analyze template hierarchies in a proprietary CMS system I worked on.
In my career as a software developer, I’ve come to appreciate the principles of Continuous Integration (CI). It forces you to do the hard things early and often and thus helps you reduce risk during development. It forces you to write tests, and be responsible about what you check in. All in all, good qualities and something that every development team should aspire to. Or so I thought. Reality is different, and so far almost every development team I have interacted with is deadly afraid of doing CI.
I’ve had the idea for this blog post in my mind for a long time. It is based on all my personal experiences and observations over the past years and is in no way scientific. It is my personal opinion, and even though this is how I perceive the world, it might not be true for other people. With that said, let’s jump to the core of things. A happy developer is a productive developer.