It’s objective setting time for the guys at work. Aligning what’s really good for you with what’s good for the company shouldn’t be difficult, right? Your generally heading in the same direction and have similar interests at heart. Why then do we end up with generic meaningless objectives like “attend a XXX course”? I think you can get the most out of the objective setting exercise by thinking about what you want personally out of your career, don’t settle for the bland, phrase your objectives so there is real value in them. So, if the company think of them in terms of

S.M.A.R.T

I like the think of them as

S.M.A.R.T.Y

Where the Y is all about YOU; make it personal.

For example, we all want to be better developers but how do you phrase that as an acceptable business objective that management can neatly label it, put in a box and pull out in twelve months time to see if it’s flourished? Defining “better” in terms of SMART isn’t going to be easy.

Keep a Developer’s Journal

How about rephrasing it and thinking about it as reflecting on your coding practice? Keep a code journal of good and bad coding choices, yours and your teams. Reflect on it regularly and update entries. Was choosing a ThreadSafeDooDar the right decision three months on, did it ever get used in a threaded context? How about that choice of using setter over constructor injection? How’s that working out for you? The responsibility to reflect is yours but you can get outside perspectives from your peers.

The key personal objective here is to keep learning, the company objective is to become a better developer. It can be specific because your wording will reflect something along the lines of “demonstrate a self-assessment of personal and team coding standards and style”. It’s hard to avoid the word “quality” but if you do mention it, you should define it (not easy).

The point is there’s something the company can buy into but there’s something more subtle that you can really buy into and get value from. It’s all about YOU after all.

It’s measurable (at least from the companies perspective, and so can get signed off on) because you have your journal as evidence along with dates and conclusions. You can even emphasize a few key learning points / techniques that you’ve changed your opinion on. Change is good and demonstrates learning. You might be able to extend in terms of coaching. Asking for professional and formal coaching is a great way to develop and the journal idea can be used as evidence. The coach can co-author to give it that “official stamp”.

An example journal template might include date, initial description (the approach you took), pros/cons of the initial decision (why you took the approach), updated thoughts (including what caused you to reflect on this specific entry), updated pros/cons, conclusion, peer comments. Try and keep an entry specific to a single decision you made in the code (coarse or fine grained). Getting a feel about what to journal and what not to journal should be pretty natural, any “niggles” you get might prompt you or spotting that you’re all talking about this part of the code a lot might be a clue.

Reflection is Key to Development

The real benefit though is what you can take away from it, if you talk over your journal points with your peers and keep an open mind, it could become a great learning tool.

Failing that, maintain a blog!