
Ask HN: How do you, as a developer, set measurable and actionable goals? - humaninstrument
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 &quot;Make one illustration a day&quot;, &quot;Make a logo a day&quot; or &quot;Sell X units of Y product a day&quot;, &quot;Make X ammount of dollars seeling product Z by date X&quot;, etc.<p>How do you, as a developer, set measurable goals for yourself, being it at work or in your side hobbie?
======
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.

------
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.

------
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.

------
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.

------
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.

------
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](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.

~~~
westurner
Burn down chart (each story has complexity points; making it possible to
estimate velocity and sprint deadlines):

[https://en.wikipedia.org/wiki/Burn_down_chart](https://en.wikipedia.org/wiki/Burn_down_chart)

User stories in a "story map" (Kanban board) with labels and/or milestones for
epics, flights, themes:

[https://en.wikipedia.org/wiki/User_story#Story_map](https://en.wikipedia.org/wiki/User_story#Story_map)

Software Development > Requirements Management > Agile Modeling > User Story:
[https://wrdrd.github.io/docs/consulting/software-
development...](https://wrdrd.github.io/docs/consulting/software-
development#user-story)

