
The Starter, the Architect, the Debugger and the Finisher - prez
http://jacquesmattheij.com/The+Starter+the+Architect+the+Debugger+and+the+Finisher
======
edw519
I believe that in order to get really good at any of these roles, you must do
the other roles, deeply and often. For example:

The more time you spend Debugging shit, the less likely to you are to
Architect something that produces shit.

The more time you spend fixing a million little things caused by poor early
decisions, the better Starter you'll become.

The more fun you have conceiving and Starting projects, the more you'll
realize how important Finishing is, so that you can get to new stuff.

And the more time you spend doing each of these roles, the better you'll get
at doing all of them at the same time, and understanding what conditions are
needed to do that. (Hint: Lots of quicker smaller complementary projects that
you can wrap your whole head around.)

[This whole discussion reminds me of the time I was a restaurant manager and
got tired of the servers and cooks bitching at each other. I had them switch
roles for one shift. Once they understood how what they did affected the
other, everyone got a little better and the bitching stopped.]

~~~
scotty79
The more time I spend Debugging shit the less likely I am to Architect or even
Start anything because I am painfully aware that everything produces shit.

EDIT: Wow. A downvote. That what I get for showing the pain I experience to
the world. :-)

~~~
wisty
So what you are saying is - you write better code, reduce lines of code, don't
be too clever, reduce complexity, and use well-proven libraries.

~~~
bermanoid
I think what he's saying is, after all that, you're still probably producing
shit, that no matter how awesome you are, whoever ends up tending to your pet
Frankenstein after you've moved on is probably still going to spend half their
time cursing your existence, if they weren't part of the project from the
beginning.

And that's only if you're good enough in the first place so that "finishing"
is actually worth the effort, rather than starting from scratch using your
code as the blueprint for the new and improved 2.0 spec. This requires not
only that you be good, but that you get lucky: that you've accurately
predicted the stack that your ops team will be pushing to standardize on in 2
years, that there's enough expertise in the language(s) you used to justify
its continued use, that management hasn't decided to switch everything to
Windows + .NET because "support", that every one of the OSS libs that you've
pulled in all happen to be licensed under the three particular OSS licenses
that legal decided to approve after that recent switch to a "whitelist"
policy, that the company services you were forced to integrate with when you
started haven't been shitbinned, that the new lead developer on the project
doesn't have aesthetic problems with the way your code is organized, and so
on. All of which usually mean "rewrite!", and few of which you have much
control over. At the end of the day, it doesn't matter whether it's your fault
or not, the people evaluating your work will still consider it "shit" because
it's not usable anymore, and nobody loves the project enough to bother
figuring out how to patch it up.

IMO, though, the _real_ reason we all tend to produce shit (and then throw it
out later) is actually missing from this otherwise excellent four-part
breakdown: documentation. And I'm talking real, detailed, explicitly human-
centric documentation that's more than just class/function level comments or a
user manual. Lately I've been dealing with several attempted tech
consolidation tasks as part of a several-tier acquisition (big fish swallows
little fish, bigger fish swallows entire lake), and it seems that no matter
what size the company is, nobody in software _ever fucking documents anything_
well enough to reuse it, even when they're developing services that are
explicitly intended to be consumed by other groups. The resulting duplication
of effort is ridiculous.

Good internal documentation needs to start with the starter, end with the
finisher, and be taken seriously by everyone in between. It should be
considered almost as important to a project as the code itself. It needs to
explain how to use the system, how to integrate with it, how to debug common
problems, where the pain points are, how the system is architected, why
certain decisions (especially tradeoffs!) were made, and more. Done right,
good documentation can make up for some pretty bad code, and make sure that a
project is actually maintained rather than thrown away.

~~~
goblin89
Spot on—wish I could upvote each sentence of your comment.

Everyone knows code readability counts, because it's “read much more often
than it is written”. Same on a larger scale—the project is built once, and
then maintained for years and decades (especially in “enterprise”
environment). So you should optimize for maintenance—that is, write docs.

It really puts me out that no one else in the team or management appears to
take documentation seriously. Is this ‘job security’ or general negligence, I
don't know. I think either your primary concern is project success, or it is
your job and money. If it's the latter, then of course why would you write
docs—just bang out something that works for client/employer, you'll get paid
and it'll be harder to fire you.

Or maybe it's management problem really and I shouldn't care.

~~~
helmut_hed
I think it's a short-term vs. long-term problem: everyone's focused on hitting
their milestones and the problems that will be caused by the bad documentation
won't manifest themselves until later. It's kind of a "technical debt"
situation.

------
skrebbel
Nice article, but IMO it's essentially a software-specific version of the
Belbin Roles[1].

[1] <http://en.wikipedia.org/wiki/Team_Role_Inventories>

    
    
        Starter -> Resource Investigator
        Architect -> Shaper
        Debugger -> Teamworker
        Finisher -> Completer Finisher
    

Roughly.

What I miss most in Jacques' article is the Plant, the person who thinks
things over and then comes forward with problems, issues and risks in the
chosen approach. It's, fortunately, a very common trait among SW engineers
though, so I guess every team has at least a bunch.

~~~
zipdog
A similar system is discussed for CEOs as well. The entrepreneur who starts a
company is not always a great consolidator who gets everything settled and
organised into a functioning whole once the money starts coming in. The next
two I think are substantial growth (being able to take an established business
and grow it into a dominant player in its industry) and the last I think is
something like holding, being able to take a large (and usually somewhat
unwieldy) business and keep it from losing ground.

There's probably a few variations on these as well (and I might be
misremembering them slightly).

------
PaulHoule
"The debugger couldn't be paid enough money to start from a blank page in
order to get something new started."

Perhaps it's different in S.V. but in the workaday world of the code mines
I've found that the Debugger doesn't get all that appreciated. Rather,
management likes the starter since he seems so productive... after all, he
just did the 20% of the work that got us 80% of the way there. They just wish
he could somehow do 25% and get 100% of the way there.

~~~
Periodic
From my experience as an enterprise coder I saw a management that didn't
understand that there were bugs. Everything was supposedly done with Scrum, so
at the end of each two-week sprint there were supposed to be no more bugs left
on that feature. As far as the schedule was concerned (and we were scheduled
over a year in advance) bugs didn't exist.

When bugs were found that the engineering team had to fix, we were either
supposed to do it in addition to our other tasks. And any major bug required a
huge rescheduling meeting to figure out how we can still make our schedule now
that we had lost 20 engineer-hours.

Also, with their focus on "individual ownership" they expected everyone to
take a feature, implement it, and fix all the bugs without involving the other
engineers.

What this lead to was a lot of buggy code, a lot of obvious bugs that didn't
get fixed and we just crossed our fingers over, and a lot of people acting as
starters even though we had and needed more finishers, debuggers, and
architects.

------
nadam
I find it very hard to characterize myself, I constantly struggle with it. I
enjoy starting things and don't like finishing/maintainging other peoples code
especially if I cannot see their philosophy.

When trying to figure out where my limits are I found out another
characterization:

\- fastness

\- deepness

\- input bandwith

\- memory (forgetfulness)

Compared to an average person I am good enough in all of these, but compared
to A players I am bad in all of them except deepness. Compared to the very
best I am slow to learn a new technology, slow to solve problems on the
whiteboard in real-time, I have to re-learn things because I have partly
forgotten them, and I am not especially fast in learning other people's
theorems, proofs, and algorithms. I ocnstatnly find lots of stuff bullsiht and
I constantly question basic beliefs, so I am slow at processing outer
information. What I am quite good at is getting a challenging task and
thinking about it for a lot of time refactoring my thoughts hundreds of times
until I come to interesting insigths. Not that I am that good at it, but I
have huge patience for this, because this is what I enjoy. It is more than
enjoying this: my brain needs this as a drog. My brain pretty much likes to be
detached from the outer world for long-long sessions.:)

When solving easy tasks this does not come out. But when pushing my limits I
experience these weaknesses / strongness.

~~~
Periodic
Would you please expand on your four characterizations, explaining what this
quality is, what it makes someone good at, and maybe an example persona that
exemplifies it?

The four adjectives don't immediately create images in my mind of what
qualities they represent.

~~~
nadam
I try to expand on the 4 metrics I came up with:

fastness:

This can be measured by giving the person a not too hard (but not completely
trivial) algorithmization problem, and see whether he/she can solve it in 15
minutes. Someone 'fast' is usually very good at competitions or at interviews
excercised by companies where interviews are quite intense like Google.

deepness:

This basically means that given a much harder problem than the previous one,
how the person solves it given lots of time. This is different than the
previous one. Can he come up with a quite original "theory"/(thought system)?
How fast a ray tracer he can write in 3 months? How good domain specific
language he can come up with for a tricky domain in 2 weeks? (vs. writing the
implementation for the Dijstra algorithm in 30 minutes without mistakes, which
is 'fastness')

\- input bandwith

How fast you can read a reasonably dense technical/algorithms/math book. How
fast you understand other people's nontrivial ideas? This is not totally the
same thing as how fast you come up with an idea, or how good an idea you come
up with yourself.

\- memory (forgetfulness)

How big a system / requirements spec. document can you hold in your head? If
you used C++ 3 years ago, do you need to re-read the book 'The C++ Programming
language' or you remember more or less everything? If you look at your
previous comments on Hacker's News, are you suprised by some information in
your own comments or you remember more or less everything?

~~~
Periodic
This makes more sense. Thanks for the explanation. I like "fastness" and
"deepness". I've definitely noticed a difference between people who are best
at getting things done under time constraints but procrastinate anything
longer (myself) and people who will do a great job if given enough time but
which choke under pressure (my wife). I never really tried to name the two
though.

Your system almost sounds like the two sides of two different things. On the
one hand you have the ability to get things done: the ability to get a lot
done quickly and on-the-spot and the ability to get things done meticulously
and precisely if given the time. On the other hand you have the ability to
learn things quickly and precisely remember them.

I might call it velocity vs. precision in the two areas of production and
learning.

------
larsberg
When I worked at MSFT, we used to break up (senior) people according to which
stage of the project they were better at leading, either as technical ICs or
managers. If you chunk projects into four parts: early, build-up, build-out,
and release (not the words we used --- we just used numbers 1-4), almost all
senior people tend to do best at some close span of two of them. I was
personally frequently slotted into 1/2 roles, but I knew lots of others who
fit more into 3/4 roles. It's a mixture of personality type and skillset.

Few things can doom a project more quickly than putting a "shipper" in charge
of an early-stage project or vice-versa. You end up with management that sends
all the wrong signals to the team and everybody can tell is looking forward to
some later stage.

Of course, for junior people, it's important to just make sure they get
through all of them. Not just to pick up the skills mentioned by other
commenters here, but also to see which they're good at for when you want to
stretch them with a leadership role, without setting them up for an avoidable
failure.

------
Swizec
Personally I'm a starter. Great at implementing prototypes, getting things
working fast, but absolutely terrible with polishing things and taking care of
edge cases.

And I _hate_ it. I consider it a personality flaw, a flaw in my work ethics,
and so on. Whatever it is, I don't want to have it.

What I've found has helped me get beyond this problem is taking on freelancing
gigs where I'm mostly the guy who gets a rough prototype and has to make it
work. The beauty of this is that I know how to think like a prototyper, so I
can become productive on a foreign codebase quickly.

And because I started at a different goalpost, I can still work as a "starter"
even though I'm doing the job of a "debugger/finisher".

~~~
follower
> I consider it a personality flaw, a flaw in my work ethics, and so on.

I'm curious what percentage of software developers self-identify as finishers
and what percentage as starters.

My assumption is that starters are much more common--but maybe that's because
I assume everyone is just like me.

Are there really software developers who fit the "finisher" description? And
prefer it? :)

If it turns out that software developers really do have a range of roles
available to them and each individual suits some more than others then maybe
it's best to work to accept it rather than feel guilty about it?

~~~
aurelianito
> My assumption is that starters are much more common--but maybe that's
> because I assume everyone is just like me.

If finishers are less common than starters, shouldn't they be payed more? Are
they being payed more? Is it a flaw in the market?

~~~
T-hawk
They are. The debuggers and finishers are the ones making $100k for day-to-day
Java maintenance at the big banks and insurers and retailers and such. For
every starter who's succeeded in their own business or risen to a $200k
director job in CorpWorld, there's four other starters who are subsisting on
someone else's capital and haven't launched anything for real income yet.

That said, pay is based on perception as much as results. If a starter can
sell someone on his vision of a $50M revenue payment processing platform,
there's a good chance he can convince someone to pay him a small fraction of
that like $500k, at least until the project dies off. Finishers can't do that
while shooting one bug or fixing one feature at a time.

------
Jd
One important thing to note is that you can be good in all of the roles but
not be able to do all of them on the same project. For example, I find
personally that I have a very difficult time being a finisher and starter on
the same project -- after a certain point exhaustion takes over. Also, I love
to debug things, but, again, after you've spent countless hours debugging you
might run into the problem of exhaustion.

This is, among other reasons, why I like the YCombinator emphasis on co-
founders and teams. Even if you are a superstar you need people around you to
work at maximum efficiency (speaking for myself at least).

Also, I'd like to applaud the backstage people (accounts, etc.) that make
other things possible. Even when I do reasonably well in all of the roles
mentioned in this article, I absolutely fail in the paperwork department.

------
pkandathil
I am opposed to the concept of having a architect that does not code. Too
often have I seen the situation where they recommend a solution without
understanding the complexity of the implementation.

------
c1sc0
When you put it in sequence like that it seems like the Starter & Finisher are
far removed from each other, but I find the opposite to be true. What these
personality types has in common is an appreciation for beauty. The Starter
just loves beautiful _ideas_ while the Finisher loves beautiful user-faceing
_implementations_.

------
tseabrooks
My first job in embedded systems required everyone to do pretty much all of
these things. Each developer handled their own modules from user facing UI
through to the HW (more or less). We had to architect and design things before
implementing them (No one checked.. and it wasn't enforced... it's just the
way the culture works) we then became individually responsible for
implementation and bug fixing until the QA dept said it was A+.

After that there was a module review by 5 randomly selected engineers that
would tell you what parts of the module was a messy hack and make you go fix
it. I miss this culture.

------
fabricode
> The Starter, the Architect, the Debugger, the Finisher

and the Stereotype.

These articles aren't very informative if they don't have some new insight
into how to maximize the output of the team by exploiting the traits of the
stereotype. The roles outlined in this entry really only fall into two
categories: get things going (starter & architect) and get things working
(debugger & finisher).

If I had to take a wild guess, I'd say that what the article is really trying
to say is that it's easy for people to start projects (I've yet to meet a
"debugger" that can't start their own), but it's hard to complete them. It's
often even harder to keep something working than when it was put together
given the nature of changing requirements.

So my take on the article would be to add the advice: if you consider yourself
a "starter" or an "architect", go live in the world of maintenance for a
while. Learn to complete your projects. And if people tend to curse a project
when your name was on the design doc, perhaps you should spend a bit more time
learning about practical programming, design, and algorithms... or mentor with
someone who is well regarded.

Next week's article: What happens when the boss is a Sagittarius and the team
lead is a Gemini?

~~~
jacquesm
> What happens when the boss is a Sagittarius and the team lead is a Gemini?

I don't know, will you write it?

If you missed the message on what you could do to 'meximize the output of the
team', without taking a wild guess, it is there in the next-to-last paragraph.

Whether that's a novel insight or not is up to you, it is novel enough to me
that I chose to write about it. I'm still trying to work around my tendency to
start stuff and not finish stuff and having been tossed into the role of
debugger/finisher lately has helped me to be both better at starting stuff
_and_ to get more appreciation for the people that work on later stage code.

~~~
fabricode
I did catch your conclusions in the penultimate paragraph. However, I don't
believe that "assigning [a] quality control role to the next person
downstream" is a workable solution. This is a form of passing the buck,
saddling someone else with your problems, etc.

In your reply here, you say that you've learned that by working as a
debugger/finisher you've learned how to start stuff better. _That_ is worthy
of further exposition as so many people suffer from the exact same problem.

And as much as false categorization & naming hurts your best point, it sure
seems to have caught HN's attention, so marketing may be where your true
genius lies. That's cool -- there's lots of money in marketing :)

~~~
jacquesm
> This is a form of passing the buck, saddling someone else with your
> problems, etc.

No, you _still_ have to fix it yourself. But at least there is a feedback
element.

------
darylteo
I associate myself mostly as an Architect first, Starter second.

There is nothing more than I'd like for someone to just take some designs I've
drawn up, critique if necessary, and then get it done. Generally, I get so
stuck in the big picture that I have great difficulty getting anything done :(

I CAN debug... often I can identify a problem just from a general description
of the problem (when you see me sit down in front of a computer and take over,
it's when the problem has dug in deep). Sadly, with all the maintenance work I
have to do with some legacy systems, debugging them is not a task I take to
fondly.

Definitely not a finisher... I'm a sprinter, not a marathon runner.

------
debacle
Often times, The Starter and The Debugger are the same person - the person who
approaches programming challenges like affronts to their ability. Once the
hard problems are solved, it's just a bit of tidying up and you're set.

I find it very difficult to be a Finisher, and I think many programmers do.
Finishing isn't fun, it's not glamorous, and it's not why we do the work, but
it's a skill that we need to develop.

I've noticed a trend in my own development. When I first start a project or
I'm working on a hard problem, I'm working 10-12 hour days figuring out the
interfaces, making the object model pristine (or as pristine as it can be in
the language I'm using), making the error messages helpful and the exception
handling consistent.

And then, as I'm closing out the project, I start to lose focus. I start
watching the clock. I'm out of work as fast as I can. I'm doing, for lack of a
better word, the bitch work, but the bitch work is what makes the system.

I've tried to get better at it, but I think there is a fundamental issue with
the project lifecycle that makes human beings phone it in in the last bits of
a project. Whether it's building a house or writing an application, those last
bits of the project seem the most arduous.

------
jpdoctor
It would be interesting to run an HN poll: Which of these rolls are you mostly
associated with?

My guess is the population here is dominated by Starters and Architects.

------
ilaksh
I think the actual explanation is this:

1) Generally managers still don't understand the concept of agile and early
release and so try to cram as many features, bug fixes amd details into each
release as they can think of.

2) There is no possible way that one programmer can take care of all of the
bugs, extraneous little features and tasks that the manager was able to think
of.

3) Therefore the manager must come up with a division of labor and a simple
categorization such as suggested by this article is one of most obvious and is
probably attractive to a lot of senior developers because it means they don't
have to worry about as many tedious tasks which they know are unlikely to
provide real business value.

I think that most programmers with a decent amount of experience don't really
fit into any particular one of those boxes because they have done all of those
things themselves for one or more projects.

------
TamDenholm
I consider myself a good starter and debugger, I really suck at finishing, i
hate all the little polish bits that are left over to do.

I find it easier to be the finisher if i didnt start the project, perhaps i
should partner with someone with the same problem and just swap our projects
once we get to the finisher stage.

~~~
Aqua_Geek
I also consider myself to be a starter and debugger. I have _dozens_ of half-
baked projects in the project graveyard on my hard drive.

I think part of my problem is what's described in the article - I start the
project, solve the hard problem, and then move on to learn something else.

Any finishers out there have any tips? What drives you through the slog of the
last 10%?

------
euroclydon
I've found the reasons why I sometimes don't want to wear all four of these
hats are mainly personality defects. It is possible to work for another year
on the non-creative parts of a project, it just takes discipline.

------
ClintonWu
This post also helps us non-technical types when interacting with technical
co-founders and the engineering team. I realize my partner is definitely a
starter and not a finisher!

------
dennisgorelik
_Debugging the code that you wrote for weeks on end isn't as satisfying as
helping someone squash a bug in their code._

Most likely explanation is not boredom of keeping working on the same project
from start to finish.

Most likely explanation is boredom from working alone.

------
jblake
I value the ownership of a project so much - the idea that when it becomes
big, I can say, "I made that." Like the British guy who fought WWII with a
sword and claymore. Challenge is rewarding.

Also, reading the Fountainhead was a game changer for me.

------
andrewflnr
I'm such a Starter/Architect it's not even funny. I know I need to work on
finishing, but I can't fight nature (edit: I should say, I can only fight it
so far).

Is there somewhere I can write to get a better Debugger/Finisher?

------
ZeWaren
This reminds me of role variants in the Keirsey Temperament Sorter.

<http://en.wikipedia.org/wiki/Keirsey_Temperament_Sorter>

------
Bjartr
Does anyone have advice on how to become a better finisher?

~~~
jacquesm
Take any project (open source is easiest) and fix something, get it closer to
that 100%. Do enough of this and you'll start to get a feel for it similar to
the kind of rush you get when you're starting, only it is then associated with
getting closer to the finish line instead of how far you got from the starting
line.

It helps to pick small projects in the beginning to not lose sight of the
goal.

------
Amadiro
"The finisher" sounds like a mythical creature to me...

------
ludflu
good article. I've found myself in various of these roles in different jobs.
But it really is hard to do them all in the same project.

------
malkia
The 4 seasons.

------
CPlatypus
Another metaphor I've seen is to the military (specifically the army), and
consists of three roles. Don't beat me up about military minutiae, please; I
don't claim to be an expert in that area and it's not even my metaphor.

(1) Paratroopers, who jump into unfamiliar territory. In software, researchers
and architects.

(2) Infantry, by far the largest component, responsible for the core task of
taking and holding territory. In software, most programmers.

(3) MPs (also quartermaster, community liason, etc.) who maintain order in the
held territory. In software, debugging specialists and release engineers.

The problem I have with the OP's metaphor is that the "starter" and
"architect" roles are both part of (1) and many people actually can do both
pretty well. Similarly, the "debugger" and "finisher" roles are both (3) and
also combine well. What's really unfortunate is that (2) seems entirely absent
even though in real life it consumes most of the time and resources on a
project. These are the folks who take mostly-complete designs from a
starter/architect, and get most of the code mostly working before the serious
integration/stress testing occur and the debugger/finisher come to the fore.
In other words, most of your colleagues most of the time. If you hired four
people according to these four roles, you'd have nobody to write most of the
code and you'd be abusing your four specialists to do it.

------
jordhy
The article it's ok, but this is just a permutation of the roles first
outlined in the Mythical Man Month (lawyer, surgeon, organizer, etc).

------
chaostheory
Depending on the programming language, I can't help but feel that this article
is out of date.

Today you don't really need to be a pure starter or architect anymore. There
are so many frameworks that mimic Rails and its philosophy of convention over
configuration, that there's not really a lot of effort needed to start and its
easy to delegate most of the architectural duties to the framework developers
themselves.

As for the debugger and finisher, that is also a lot easier as well. With all
the automated integration and behavior driven test frameworks, it's relatively
easy to both cross your t's and dot your i's. Today you can have something
yelling at you everything second your tests break (assuming that you wrote
them, which is key to any project).

