11 ms·

The Starter, the Architect, the Debugger and the Finisher

328 points by prez 15y ago

euroclydon 15y ago
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.
PaulHoule 15y ago
"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.
- deleted 15y ago
  [deleted]
- dalore 15y ago
  Yes but isn't the rule that last 10% of a project takes 90% of the time?
- Periodic 15y ago
  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.
c1sc0 15y ago
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.
skrebbel 15y ago
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 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.
- drsim 15y ago
  Nice
- aercolino 15y ago
  Maybe this is better: Architect -> Plant + Specialist Starter -> Resource Investigator + Shaper Debugger -> Completer Finisher Finisher -> Teamworker + Implementer
- zipdog 15y ago
  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).
ZeWaren 15y ago
This reminds me of role variants in the Keirsey Temperament Sorter. http://en.wikipedia.org/wiki/Keirsey_Temperament_Sorter http://en.wikipedia.org/wiki/Keirsey_Temperament_Sorter
Swizec 15y ago
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 15y ago
  > 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?
  - vladd 15y ago
    I've seen successful finishers. You can see them hang out around sites like www.flippa.com , looking for that special project that they could buy and operate as owners for a quiet life and sustainable revenues.
    - krelian 15y ago
      To bad that 90% of the starters on flippa think the finishers are idiots ("huge potential!") and market to them as such. With most sales on flippa I feel like I am playing "Find the scam".
    - polyfractal 15y ago
      I think Rob Walling is a perfect example of a Finisher. He's purchased several different web properties, polished them up with a new skin, new marketing and new copy, removed all those nagging little bugs that the previous owner left languishing.
jordhy 15y ago
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).
TamDenholm 15y ago
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 15y ago
  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%?
edw519 15y ago
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.]
- revorad 15y ago
  Did you try switching roles with a cook or server? That would have been fun :-)
  - edw519 15y ago
    No need for that. I had already done every job and knew exactly what would happen. But your question reminds me of another time when I did do that. I was the IT Director and got tired of the lead programmer bitching about my decisions. So we traded jobs for one day. I had a great day just coding. He made 5 decisions. On each one, I pointed out about 5 things he didn't take into consideration, making his decision less than optimal. He was glad when that day ended. (And I was glad when that job ended; I've been coding ever since.)
- kiiski 15y ago
  How did your customers like the food made by servers, and the serving done by cooks?
- geebee 15y ago
  I would agree that people learn from being involved in all phases of a software project at least once. Especially starters. Starting a project is an exciting, heady, creative time. If the last 10% takes 50% of the effort, the first 90% is where you create and build at a fast pace, enjoy the adulation of your clients who are amazed with how quickly things are going, investigate and implement interesting new technologies and approaches, and revel in the fun of creating something new. The question is, did you leave the code base in good shape, or did you go on a bender, drinking the champagne but leaving your successors to experience the hangover? My guess is that most people on this board have had to deal with a truly bad code base, in production, inherited from a programmer who flitted off to the next project cause he "enjoys the challenges of creating new things". Until you've been the debugger who fixes the million little problems, the "architect" (wish we had a different word, cause you will be coding a lot) who refactors the code into something that can actually be maintained, and the finisher who experiences the irritated grousing of clients (who notice that things have slowed down so much since the "starter" left the project... we just asked for it and he did it), you don't know the kind of damage a rogue "starter" can do.
tseabrooks 15y ago
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.
ludflu 15y ago
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.
darylteo 15y ago
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.
jpdoctor 15y ago
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.
ClintonWu 15y ago
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!
CPlatypus 15y ago
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.
Jd 15y ago
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.
nadam 15y ago
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 15y ago
  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 15y ago
    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?
pkandathil 15y ago
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.
fabricode 15y ago
> 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 15y ago
  > 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 15y ago
    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 :)
larsberg 15y ago
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.
debacle 15y ago
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.
Bjartr 15y ago
Does anyone have advice on how to become a better finisher?
- jacquesm 15y ago
  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 15y ago
"The finisher" sounds like a mythical creature to me...
jblake 15y ago
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.
chaostheory 15y ago
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).
dennisgorelik 15y ago
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.
ilaksh 15y ago
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.
andrewflnr 15y ago
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?
malkia 15y ago
The 4 seasons.

328 points by prez 15y ago

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.

PaulHoule 15y ago

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

deleted 15y ago
[deleted]
dalore 15y ago
Yes but isn't the rule that last 10% of a project takes 90% of the time?
Periodic 15y ago
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.

c1sc0 15y ago

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.

skrebbel 15y ago

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

drsim 15y ago
Nice
aercolino 15y ago
Maybe this is better: Architect -> Plant + Specialist Starter -> Resource Investigator + Shaper Debugger -> Completer Finisher Finisher -> Teamworker + Implementer
zipdog 15y ago
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).

ZeWaren 15y ago

This reminds me of role variants in the Keirsey Temperament Sorter. http://en.wikipedia.org/wiki/Keirsey_Temperament_Sorter http://en.wikipedia.org/wiki/Keirsey_Temperament_Sorter

Swizec 15y ago

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 15y ago
> 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?
- vladd 15y ago
  I've seen successful finishers. You can see them hang out around sites like www.flippa.com , looking for that special project that they could buy and operate as owners for a quiet life and sustainable revenues.
  - krelian 15y ago
    To bad that 90% of the starters on flippa think the finishers are idiots ("huge potential!") and market to them as such. With most sales on flippa I feel like I am playing "Find the scam".
  - polyfractal 15y ago
    I think Rob Walling is a perfect example of a Finisher. He's purchased several different web properties, polished them up with a new skin, new marketing and new copy, removed all those nagging little bugs that the previous owner left languishing.

jordhy 15y ago

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

TamDenholm 15y ago

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 15y ago
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%?

edw519 15y ago

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

revorad 15y ago
Did you try switching roles with a cook or server? That would have been fun :-)
- edw519 15y ago
  No need for that. I had already done every job and knew exactly what would happen. But your question reminds me of another time when I did do that. I was the IT Director and got tired of the lead programmer bitching about my decisions. So we traded jobs for one day. I had a great day just coding. He made 5 decisions. On each one, I pointed out about 5 things he didn't take into consideration, making his decision less than optimal. He was glad when that day ended. (And I was glad when that job ended; I've been coding ever since.)
kiiski 15y ago
How did your customers like the food made by servers, and the serving done by cooks?
geebee 15y ago
I would agree that people learn from being involved in all phases of a software project at least once. Especially starters. Starting a project is an exciting, heady, creative time. If the last 10% takes 50% of the effort, the first 90% is where you create and build at a fast pace, enjoy the adulation of your clients who are amazed with how quickly things are going, investigate and implement interesting new technologies and approaches, and revel in the fun of creating something new. The question is, did you leave the code base in good shape, or did you go on a bender, drinking the champagne but leaving your successors to experience the hangover? My guess is that most people on this board have had to deal with a truly bad code base, in production, inherited from a programmer who flitted off to the next project cause he "enjoys the challenges of creating new things". Until you've been the debugger who fixes the million little problems, the "architect" (wish we had a different word, cause you will be coding a lot) who refactors the code into something that can actually be maintained, and the finisher who experiences the irritated grousing of clients (who notice that things have slowed down so much since the "starter" left the project... we just asked for it and he did it), you don't know the kind of damage a rogue "starter" can do.

tseabrooks 15y ago

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.

ludflu 15y ago

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.

darylteo 15y ago

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.

jpdoctor 15y ago

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.

ClintonWu 15y ago

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!

CPlatypus 15y ago

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.

Jd 15y ago

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.

nadam 15y ago

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 15y ago
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 15y ago
  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?

pkandathil 15y ago

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.

fabricode 15y ago

> 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 15y ago
> 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 15y ago
  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 :)

larsberg 15y ago

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.

debacle 15y ago

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.

Bjartr 15y ago

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

jacquesm 15y ago
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 15y ago

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

jblake 15y ago

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.

chaostheory 15y ago

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

dennisgorelik 15y ago

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.

ilaksh 15y ago

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.

andrewflnr 15y ago

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?

malkia 15y ago

The 4 seasons.