Most software developers I know are really keen to improve their skills. But how do we know we’re improving? How can we tell if our efforts are effective? Without feedback on our progress, it is easy to feel swamped and demoralised by the rate at which stuff we want to learn piles up, compared with the rate at which we feel we’re improving. Setting and working towards goals can help address this.
Yet when I’ve asked other devs, most have great personal, work and non-tech goals, but have something to the effect of “become a better developer” thrown in as well. I’ve been thinking about this a bit recently, so thought I’d jot down a couple of thoughts about goals specifically related to software development.
Goals are important
Goals have the potential to motivate us, help us focus, get into a flow, avoid wasting energy, make the most of opportunities we have and, when we reach them, give us a feeling of achievement and growth, along with the happiness that brings.
Many (if not all) of the people I know that I consider really successful are very goal-oriented. They know what they want to achieve and have the skill, self-confidence, and drive to make it happen. For them it seems to come naturally, but I think it is an approach that can be learned and adopted by anyone, irrespective of personality. It’s simply a matter of choosing the right goals; ones that inspire and provide both feedback on progress and a feeling of achievement on meeting them.
Goals with external dependencies
One thing I’ve found really useful in helping to pick goals is to consider which ones depend solely on me, and which ones depend on other people.
Goals like getting a certain number of blog readers, presentations at user groups and conferences, or community recognition all rely on other people. Sure, you have some ability to influence these measures, but the final result is out of your hands. You are not the one in control of whether you meet your goal.
Now I’ve seen these kind of goals work great for people as a way to become better developers (higher profile leads to more opportunities and exchanges of ideas with other top devs), but there are a few reasons they don’t work for me. For one these goals just don’t inspire me, perhaps because I’m a bit of an introvert. Also I don’t have much success in these areas, so you could attribute this to sour grapes ;). But most importantly, I find making progress towards goals plays a crucial part in my motivation and happiness, and I’m not willing to chance either of those things by making them dependent on other people who aren’t even aware of the burden I’ve placed on them.
So for me I need goals that are largely dependent on my own actions.
Non-specific goals
I love learning. I love the process of piecing together little bits of information, until finally something clicks, accompanied by the joy of discovering something I didn’t know before. I guess it’s no surprise then that a number of my goals have been things like “learn (TDD|WPF|Haskell)”.
These make horrible (albeit well-intentioned) goals. The problem is determining when I have achieved them. When have I “learned functional programming”? One of the main things I learn on any topic is becoming aware of more stuff I don’t know – the unknown unknowns. This makes it very tough to get the motivating feeling of progress or the joy of reaching a goal.
These make great, general directions for us to follow, but as goals they just don’t cut it.
Concrete goals for software developers
We’ve ruled out a few types of goals for me so far: goals with external dependencies, and goals based solely on my areas of interest (like learning tech X). Where does that leave me if I want to improve as a software developer? It pretty much just leaves building stuff.
Rather than trying to learn technology X, build a project with technology X. The area of interest sets our direction, and we set an achievable, unambiguous goal out in that direction. This gives us something concrete to focus on, a measure of progress against the project requirements, and the ability to complete our goal and say we’re done. And we’ve got the added benefit that we don’t need 10 people to click our subscribe links, or 3 conferences to accept our talk proposals. It’s completely up to us to work towards our goal, with no external pressures to stifle our creativity, taking us in a direction we’re keen to go, inspired by frequent feedback on our progress, and with the joys of both learning and creating something new.
In keeping with standard guidance for goals, good projects to choose are probably simple, small projects that don’t have to (but can) culminate in polished, shippable products, but are enough to learn and apply the skills being sought. The important things are to make sure it is something that you can build that unambiguously qualifies as achieving the stated goal, and that you’re enthusiastic about it.
A related approach that I’ve found useful is “building” a blog post on the topic I’m interested in. While it’s a bit more ambiguous as to the success I’ve had in meeting my goal, it does provide a way to develop my understanding and relate it to concrete output.
Generating ideas for projects
I thought it was worthwhile to quickly mention this. It can be tough to come up with usable project ideas, so whenever I do come up with one I note it somewhere safe (in a “trusted system” as David Allen would call it). Paper, notebook, task list app, email it to yourself, whatever. Just make sure it is captured and accessible. I’ve found the more I do this, the more ideas I seem to get (although admittedly I still struggle to get lots of inspiring ideas. I do feel capturing everything is slowly helping me improve though). If you’re really stuck try looking up code katas or exercises like Project Euler. But the best projects will be ones that serve a need you have, or fit in with a hobby or subject that really interests you.
Conclusion
Many developers I’ve spoken with have the aim of becoming better developers, but haven’t taken the step of defining what that means. I’ve found it helpful to start translating this into specific goals, and the ones that seem to work best for me are building small projects that relate to an area of interest. I’m also careful to avoid goals that don’t work for me, such as those that depend on external factors and non-specific goals.
If you’ve found other software dev-specific goals and related approaches that work for you, I’d love to hear about them!