
Ask HN: How do you identify programmers who finish things? - catherd
In the context of hiring. Assume you have the chance to work with them on a few short term projects, but not long enough that the newness wears off.<p>Alternatively: How do you identify programmers addicted to novelty&#x2F;who have a hard time internalizing business goals?
======
PaulHoule
My experience is that "finishers" frequently have a hard time in their careers
because they do the "80% of the work that gets 20% of the results." and aren't
perceived to be productive as the "programmers addicted to novelty/who have a
hard time internalizing business goals."

~~~
gshdg
You can do the 20% that gets the 80% of the results, though, and still ship.
I’d consider that “finishing”. Whereas a lot of devs get distracted even
before that point and _don’t_ ship.

~~~
PaulHoule
Shipping means getting to 100% of what is necessary. So if are getting 80% of
the results and shipping, that means that somebody else is doing 80% of the
work.

Let's put it this way. If Christopher Columbus was looking for the new world
and he got 80% of the results the reward would be a watery grave.

~~~
gshdg
Except he did get 80% of the results. His stated goal was to make it to India.
He did the important part, which was to prove that you could cross the ocean
to reach another land mass.

The other 80% of the work was sailing around the southern end of South
America, and building the Panama Canal so you could actually reach Asia by
sailing west from Europe.

------
Copenjin
Even if those are short term projects you should look for a few things:

0- They should care about getting projects done, in reasonable time and
without the need for subsequent reworking. Regardless of what the project
actually is.

1- They should have internalized that nothing is ever finished. After the
"building" phase comes the "maintenance" phase and they should be aware of
this and behave like they know that maintenance for every line they write will
be one of their long term task (see #5, #6).

2- Willingness to do the least pleasurable and more mundane parts of the
project (possibly trying to reduce the time needed through automation if it
makes sense), that are necessary to finish it.

3- They should be able to always keep a clear idea of the current status of
the project, what they still need to do and what is still missing. They
shouldn't have a tendency to throw away time to look into unnecessary and
irrelevant details (i.e. technical rabbit holes).

4- They shouldn't lose interest or lose direction when something doesn't go
according to plan. In these cases the plan should be re-evaluated and a new
plan defined.

5- They shouldn't be too hasty with what they have to do just to get it over
with quickly and jump to the next thing.

6- Understand that there is a difference between a project that needs to be
completed and used in production and something you can experiment on and has
no hard requirements related to when it will be ready and how reliable it will
be.

------
bjourne
I don't think question A: How do you identify programmers who finish things?
and question B: How do you identify programmers addicted to novelty/who have a
hard time internalizing business goals? are equivalent or even similar.

Many developers are "addicted to novelty" because that is how the industry
works. You don't get very far in the game by only knowing VB.NET and C++. To
get a high salary you need to change jobs many times. To change jobs many
times you need to have knowledge about the latest and greatest (AJAX, jQuery,
MongoDB, TypeScript, Android, iOS, Rust, Go, Scrum, TDD, whatever...).

~~~
catherd
They may not be equivalent, but for the purposes of this situation they are
both worthy of identifying.

You're justifying the game plan of a certain type of programmer. I'm asking
how to find someone who's professional toolbox includes the ability to knuckle
down and manage the boring shit until it's done, over a project-level time
period.

In this instance I don't want to hire an alphabet soup programmer who will
move on to the next company as fast as the next resume update allows. If it's
a side effect of kicking ass on a variety of projects, broad experience is a
nice-to-have, but I need someone who will hang around long enough to
internalize and take responsibility for business goals.

------
itronitron
By 'finish things' I am going to assume that you mean they complete their work
in a manner such that a coworker can use it without revision. This takes
practice and training.

If you have limited time with the person (say, 3 weekly meetings over a period
of 3 weeks) then I would watch for the following...

a) did they do what they said they would do (in the previous meeting) -OR- are
they asking for clarification on what was discussed in the previous meeting?

b) can you or another dev build and run their code from whatever they last
checked in/committed -OR- do you get build errors, compile errors, or runtime
errors?

c) do they ask questions and help you clarify what needs to be done?

Regarding the addicted to novelty, not internalizing business goals question,
I see that as more of a management issue than an individual trait. They may be
too busy learning a new technology to care about the business goals, in that
case the engineering manager needs to make sure they are on track (and that
the new technology is relevant to the work being done). Once they become
proficient then they can easily internalize the business goals, but they will
need repeated exposure.

------
JamesBarney
Also adding in this response. > In this instance I don't want to hire an
alphabet soup programmer who will move on to the next company as fast as the
next resume update allows. If it's a side effect of kicking ass on a variety
of projects, broad experience is a nice-to-have, but I need someone who will
hang around long enough to internalize and take responsibility for business
goals.

I'll start with dev incentives and why it explains their behavior. Now one
thing that is fairly common is internal raises are relatively much smaller
when compared to market for jr. devs than sr. ones. This incentivizes most
young/jr devs to switch jobs fairly often to get market pay raises(which are
very substantial for young devs and usually much larger than internal raises,
I quadrupled my salary in my first 3 years of working). To do this they need
to build up technical expertise as quickly as possible because this is what
the next job is looking for. And there really isn't any incentive to build up
domain knowledge that will become useless the first time they switch jobs.

Senior/older devs for instance are usually on the opposite end where the pay
raise for switching jobs is relative lower compared to internal raises. They
are usually at a point where job security is more important because they fear
being a hard to hire greybeard. They're already close to maxing out as a
single contributor(and a lot of time if they wanted to move to management/tech
leadership they would have already). And for them to pursue their goals of job
security and maxing out pay by being valuable to one company as opposed to
many companies they'll pursue and acquire lots of domain knowledge.

So I think you have two options. Hire an expensive older/sr. dev and convince
them that the company would be a great place to spend the next 5-10 years. Or
hire a younger dev and explain how it would be very beneficial for them to
make a career there, talk about how much your company values domain knowledge
and internalizing business goals. And then explain that you are willing to pay
very handsomely for that and match what are the absolutely nuts pay bumps that
go to jr. devs when they switch jobs.

*Note I'm generalizing like crazy and I don't think this is true in every case. I've met plenty of older devs who were fascinated by new tech and had little interest in domain knowledge and vice versa. But I think as a general rule it holds, and it holds for myself. When I first started I always got really excited about new tech and building out things the "right" way. Now 10 years in meeting business deadlines/goals and learning deep domain knowledge so the application really shines excites me more than learning Yet Another Framework.

~~~
catherd
Not sure I agree with the hire a younger dev and start persuading option. In
my managerial experience, it's almost impossible to change someone's core
personality or their value system, either through words or through money. And
even a temporary change takes monumental effort on my part. Better to find
someone who's natural mode of operation fits this type of role.

I feel like the personal value system and personality are what drive long term
performance. You can explain and cajole all you want, but inevitably a few
months later the core personality starts coming back through. Establishing a
culture around certain things will go a long way toward making those behaviors
expected, but finding a person who has the appropriate temperament and skill
level for a the types of activity needed for a role is so incredibly easier
than doing everything the hard way.

Maybe I've been spoiled... I have a few engineers in other roles who do
naturally get things done and don't need constant hand-holding to get through
anything boring, but so far the programmers mostly just want to work on
whatever they think is cool and turn into procrastination machines if I push
too hard or give them an uncool task. I do have one older guy who I can leave
to his own devices and the result will mostly make sense and happen without
lots of my time pushing to finish. The other engineering roles with
'finishers' are mostly young guys, though, so I'm still hopeful any age could
be this type.

~~~
JamesBarney
I think you're right that changing a person is hard. But I disagree that
changing a person's behavior by changing their incentives is nearly as
difficult.

