HN Explorer

Ask HN: How do you, as a developer, set measurable and actionable goals?

24 points by humaninstrument ↗ HN
I see a lot of people from other industries, say designers or sales people, who can set for themselves actionable and measurable goals such as "Make one illustration a day", "Make a logo a day" or "Sell X units of Y product a day", "Make X ammount of dollars seeling product Z by date X", etc.

How do you, as a developer, set measurable goals for yourself, being it at work or in your side hobbie?

9 comments

[ 3.7 ms ] story [ 33.2 ms ] thread
sharemywin
The problem is X is never the same. To me the more X is different from all previous Xs and it still gets done the better the developer.

Also, it's real easy to rush and put in shit code and add bugs and all kinds of other problems.

It's very hard to "score" developer performance even for your self.

sharemywin
some companies use some kind of agile methodology to manage the work.

https://en.wikipedia.org/wiki/Agile_software_development

two of the most widely used being Scrum and Kanban

which could be used to track how your doing against your self. although recommended not to be used for evaluating employees so take with a grain of salt.

jayec
At work we do 2 week sprints and have a checklist of things to achieve for each sprint. For side projects I like to be a little more explicit, but I guess that comes down to how I plan projects. I'll say I want to complete X controller or component rather than vague functionality.
gardnr
It's easy to get stuck "below the sprint" and not have a higher level view. Make sure to always take time to look ahead and see what's coming and make suggestions on ordering. If your team has a backlog meeting then take some time to prepare for it by reviewing the backlog and introducing stories or tasks that may not already be in there.
breeny592
On a more macro scale, places I've worked have had people set goals across a longer period of time (3, 6, 12 months) that are measurable and have direct actions. I've found those to be quite good for myself as a developer as a day level measuring doesn't really capture what I do and what I achieve.

Ignoring fluctuations in performance at a day level (somedays no progress goes forward and it's more reading and thinking, come in the next day and everything just lines up and can power through a ton of work), I find that by virtue of working in a ticket based environment (user stories, anything involving Jira and/or Trello etc.) provides enough day to day ability to track how you go, so I like to set goals like in 12 months I want to have learned a new framework and worked on a project with it, or in the next 3 months I want to have re-factored this legacy code etc.

Goals to me should always extend past what you're expected to do, and instead show what you want to do in addition, whilst still adding value to the org you're at.

sprobertson
The simple/stupid/obvious answer: Keep a todo list.

It takes some practice to define todo list items that are achievable in a consistent fixed amount of time. But it's a worthy practice. Being able to boil a big abstract project into small component parts is (IMO) one of the most important skills of being a developer.

tabeth
I've been trying to implement the following metrics:

1. Forecasting accuracy -- Given a goal estimate how long it will take. Try to minimize the amount of time it takes.

2. Streaking -- Try to minimize the amount of time you're not in the routine. E.g. One deployment a week for 2 years straight.

3. Remembering -- Try to minimize the amount of time you need to re-look things up. This generally refers to documentation, patterns, etc.

There are other things I tried but they're too subjective unfortunately.

Jugurtha
I have carte blanche for the first project I'm working on which involves "customer" premises devices I will not be able to connect to, to be deployed in unreachable places, interacting over flimsy connections of different types, so there are considerations on power consumption and data plans (scrounging for bytes and milliwatts).

What I lack in experience I make for in other ways: I daydream all the time about the ideal scenario regardless of skill, and write the code to make that happen ramping up the skill. Then I daydream all the time about the worst scenario to ruin the perfect scenario, and write the code to prevent that from happening.

After a daydreaming session, I have a bunch of behaviors to be exhibited by the code to deal with different triggers, where the absence of a trigger can be a trigger.

Murphy's law states that things that can go wrong will go wrong. There's another law that states: "Even things that can't go wrong, do". Having that mindset makes me think of a lot of actionable goals to make real, and potential bugs to kill in the egg.

A flyback diode and the dying gasp are some of the most beautiful things I've seen. Designing, whether in hardware or software, for power outages is a thing.

I also think about space probes all the time and I try hard not to fall into Nietzsche's "admiration for a quality or an art can be so strong that it deters us from striving to possess it."

It sucks to know of software that brushes off solar flares for 40+ years like it's nothing and have mine die because of unicode.

Not dying because of unicode is a measurable, actionable, goal.