Hello there, fellow reader! It's been a while, hasn't it? As you've already acknowledged probably, this is issue no #12 and it can only mean one thing - insert fireworks here - the 1-year anniversary has come! No party right now (maybe next year), but we still have a few articles in store. Also, thanks for sticking by!
As usual, I'll keep my ranting quick and then we'll jump right in. Or you can skip this, no hard feelings.
What I wanted to write about was legacy code & an exploration of how to keep building good software without breaking everything to pieces in the process.
I have a sticker on the back of my laptop - it's a ninja in attack pose saying: good code is invisible. Indeed, a piece of code becomes invisible when it performs its function without requiring constant lookovers and adjustments. This usually happens when it's also well tested and fairly well decoupled from the big system. Problem is, legacy code rarely is like that. It usually gathers a few concessions down the road, either forced by harsh conditions (read 'tight deadlines') or pure ignorance.
Here's this situation:
You end up in the middle of a codebase that does not look like anything you wished for. Put your helmet on, my friend! You have to embrace it and make it at least bearable (if not a decent place to live in). I've come to realize that tearing everything apart and writing it the way you want is rarely an option. There's simply no time for that. So a way to still ensure you'll get some breathing air from now on is to 'start with the leaves'.
Pick up the areas that are as far from the core as possible and start fixing the issues there, slowly progressing towards the middle.
By doing so, you're keeping the project working while still being able to push small improvements to production. A few weeks/months from now, you'll have a better codebase in your hands.
These were my 2 cents on working with legacy code. Now, let's dive in.
Or 'Google + California Academy of Sciences = a good initiative'.
There are three main categories - food, water, energy - each showing ways to reduce your Carbon footprint. I know it might seem odd not to start this month's issue with a technical article but I feel that taking a step back and assessing what you can do to help is a must. Recommended by Robert.
If you want to brush up on your low-level computing concepts, here's something to fill up your evenings/nights/weekends. It's an OS tutorial, recommended by Darius. And, as one of my college professors used to say, "there's a UEFA Champions League match coming up tonight, so here's a math problem for you to think about while watching".
You can validate a solution by picking out the essential pieces and quickly putting them together, just enough so as to make it work.
In The Pragmatic Programmer, this concept is referred to as tracer bullets (= or how to fire a machine gun at night and possibly hit your target). In this article from Andrei, it means moving all the work downhill and hitting the wall earlier. It's all good: more time to recover or fundamentally change your approach.
Whenever you're debating whether or not to hire a junior developer, you're making a statement about your company culture and the health of your organization. There's a quote I really liked: "error resistance liberates them to build great software (instead of constant firefighting) and protects their nights and weekends".
I concur, protecting nights & weekends is key. Credits for this recommendation go to Alin.
"As a designer, there have been two stages in my professional life: Life ‘Before Sketch’ (BS) & life ‘After Sketch’ (AS)". This is a funny & lengthy piece about object-driven design. So grab your favorite beverage and get yourself comfortable before jumping in. From Robert.
...you get an anniversay cherry-on-top, which comes in the form of these two Open Source goodies:
These being said, thanks again for sticking by and have a look here for a recap of the past year's Around25 reads.