The Starter, the Architect, the Debugger and the Finisher

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:<p>The more time you spend Debugging shit, the less likely to you are to Architect something that produces shit.<p>The more time you spend fixing a million little things caused by poor early decisions, the better Starter you'll become.<p>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.<p>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.)<p>[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.]

Nice article, but IMO it's essentially a software-specific version of the Belbin Roles[1].<p>[1] <a href="http://en.wikipedia.org/wiki/Team_Role_Inventories" rel="nofollow">http://en.wikipedia.org/wiki/Team_Role_Inventories</a><p><pre><code> Starter -&#62; Resource Investigator Architect -&#62; Shaper Debugger -&#62; Teamworker Finisher -&#62; Completer Finisher </code></pre> Roughly.<p>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.

"The debugger couldn't be paid enough money to start from a blank page in order to get something new started."<p>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.

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.<p>When trying to figure out where my limits are I found out another characterization:<p>- fastness<p>- deepness<p>- input bandwith<p>- memory (forgetfulness)<p>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.:)<p>When solving easy tasks this does not come out. But when pushing my limits I experience these weaknesses / strongness.

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

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.<p>And I <i>hate</i> 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.<p>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.<p>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".

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

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.

When you put it in sequence like that it seems like the Starter &#38; 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 <i>ideas</i> while the Finisher loves beautiful user-faceing <i>implementations</i>.

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

&#62; The Starter, the Architect, the Debugger, the Finisher<p>and the Stereotype.<p>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 &#38; architect) and get things working (debugger &#38; finisher).<p>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.<p>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.<p>Next week's article: What happens when the boss is a Sagittarius and the team lead is a Gemini?

I associate myself mostly as an Architect first, Starter second.<p>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 :(<p>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.<p>Definitely not a finisher... I'm a sprinter, not a marathon runner.

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

It would be interesting to run an HN poll: Which of these rolls are you mostly associated with?<p>My guess is the population here is dominated by Starters and Architects.

I think the actual explanation is this:<p>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.<p>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.<p>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.<p>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.

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

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.

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!

<i>Debugging the code that you wrote for weeks on end isn't as satisfying as helping someone squash a bug in their code.</i><p>Most likely explanation is not boredom of keeping working on the same project from start to finish.<p>Most likely explanation is boredom from working alone.

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.<p>Also, reading the Fountainhead was a game changer for me.

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).<p>Is there somewhere I can write to get a better Debugger/Finisher?

This reminds me of role variants in the Keirsey Temperament Sorter.<p><a href="http://en.wikipedia.org/wiki/Keirsey_Temperament_Sorter" rel="nofollow">http://en.wikipedia.org/wiki/Keirsey_Temperament_Sorter</a>

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

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

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.

The 4 seasons.

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.<p>(1) Paratroopers, who jump into unfamiliar territory. In software, researchers and architects.<p>(2) Infantry, by far the largest component, responsible for the core task of taking and holding territory. In software, most programmers.<p>(3) MPs (also quartermaster, community liason, etc.) who maintain order in the held territory. In software, debugging specialists and release engineers.<p>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.

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

Depending on the programming language, I can't help but feel that this article is out of date.<p>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.<p>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).