Being an awesome developer is all about being a genius. It’s the only way you can get a job at a cool company and it’s the only way you can build anything amazing.
Oh wait, no it’s not.
Here’s the thing. If you care enough to actually want to be a better developer, you’re already ahead of 99% of field. So now what? Get smarter? Start a project with the perfect blend of flavour of the month and pop culture that goes viral on github? You could do that or you could do something with a concrete return on investment…
Build good habits.
Building good habits is a great investment for a developer because it goes a long way to making what you do consistent, repeatable and valuable. Building good habits takes those things we know we should be doing and makes them just, “the way”. Let’s be honest, if you don’t make a habit out of something, it’s going to be dropped the second any pressure is applied.
Good habits I’m working on:
- Smaller steps! Whether it’s a new feature or refactoring legacy nonsense, taking smaller steps is great.
- Making sure tests really are driving what I’m doing. It’s so tempting to race off ahead, but it ends in tears every time.
- Automate it. Rake, powershell, whatever. Just stop doing it manually.
- Keep the excitement, keep the love. There’s more to life than coding and it’s easy to burn out. Mix it up, do other things.
What are you working on?
The single responsibility principle (SRP) is one of the foundations of good object oriented design, taking pride of place as the “S” in SOLID. It states that a class should have a single responsibility which should be encapsulated by that class and that the class’s interface (i.e. public methods) should be closely aligned with that responsibility. Let’s look at an example.
# woof woof!
# om nom nom
Our (albeit contrived) Dog class adheres to the single responsibility principle as all its operations relate directly to Dog stuff. Good dog! Now let’s give our dog one more ability.
# woof woof!
# om nom nom
Now our Dog can build its own kennel, great! Or is it? Well, no. There’s two problems with this. One is that, dogs don’t have thumbs and as such cannot use hand tools and as we all know a dog with thumbs is an abomination. The second is that it has two concerns, dog stuff and carpentry. There it is, the “and”. You can easily spot that something violates the single responsibility principle whenever you find yourself saying “and” about class functionality.
But, why do we care? Well, adhering to the single responsibility principle helps us keep out code more loosely coupled, conceptually clean and here’s the big one, IT MAKES CHANGE EASIER. Change is what’s hard about building software (that and naming things) and the single responsibility principle helps us make sure that when we do need to change something, it’s nicely encapsulated, decoupled and much less likely to break other stuff.
TLDR; You should follow the SRP because dogs don’t have thumbs.
Staying up to date with good practices in software can be difficult. What was a good practice only a moment ago has fallen out of favour replaced by something leaner, more agile and completely incompatible with the way we used to do things. While it’s great for all those guys who need ways to fill time between giving conference talks, we mere mortals have things like clients, bosses, legacy code and less than stellar teams to deal with.
So, I believe an easy win is in order. Presenting, the data clump.
“Whenever two or three values are gathered together – turn them into a $%#$%^ object.”
— Martin Fowler
So, what is a data clump?
Whenever the same variables are being passed around together, it’s generally because they’re related. This sort of implicit relationship means something within our code, it represents a “thing”. The problem with this is, we want our code to be explicit, no muddied waters, no things that aren’t things but really are things. Data clumps make code harder to understand, harder to change and as a result, harder to live with.
Awesome, now what?
Work out what the implicit relationship between the variables is, throw them in a meaningful class and marvel at your cleaner, explicit code.
Easy win, you say?
You only need to do this once and you’ll see the benefits. Do it twice and suddenly it starts to jump off the screen at you. Keep doing it and it becomes a habit that makes you a way better developer.