The Starter, the Architect, the Debugger and the Finisher(jacquesmattheij.com)
jacquesmattheij.com
The Starter, the Architect, the Debugger and the Finisher
http://jacquesmattheij.com/The+Starter+the+Architect+the+Debugger+and+the+Finisher
67 comments
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. :-)
EDIT: Wow. A downvote. That what I get for showing the pain I experience to the world. :-)
The way over that hump is essentially to realize your implicit baseline of "not shit" is unrealistically high. An architect should strive to not produce shit, but also has to be able to emotionally deal with the unattainability of that goal. No sarcasm, I've seen people who can't deal with that. An architect must also have just enough ego to believe they stand a chance of being able to produce something less shitty than would otherwise be produced without them, while at the same time not being so egotistical that they lose touch with the users of their architecture, which is a fatal error, or even worse, become actively arrogant. (You are still producing shit, after all, and don't you ever forget it.) It's a delicate balance.
An essay that had a significant impact on me and the development of this attitude, the first few paragraphs of: http://scripting.com/davenet/1995/09/03/wemakeshittysoftware...
An essay that had a significant impact on me and the development of this attitude, the first few paragraphs of: http://scripting.com/davenet/1995/09/03/wemakeshittysoftware...
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.
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.
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.
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.
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.
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.
+1 for bringing up documentation. Good documentation without code is valuable. Good code without documentation ... probably worthless (unless it's clean enough to read, which is rare for production code once you've killed all the weird edge-case bugs).
You just described my most fitting persona, one which wasn't mentioned in the OP: the Refactorer (or less glamorously, the software janitor). Reducing complexity is among my favorite programming activities. Nothing like calling it a day after disentangling some chunky piece of over-engineered object-oriented spaghetti, leaving the codebase a few hundreds LOC lighter and all test lights flashing green.
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.
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.
Completely agree. I once worked at a bespoke software shop where they had 'proper' developers upstairs, and support developers downstairs. (Quotes used to indicate how that made the support staff downstairs feel).
Most projects taken on by the company followed the same path: upstairs developers would code up the application as per functional spec, client would do a bit of UAT, accept it, publish it live, at which point the project was assigned to the support staff.
What generally happened next was the application would begin to fail on non-functional fronts, generally appalling performance and scalability problems.
Since there was minimal communication between floors (afterall, what could a 'proper' developer learn from a lowly support developer?), the pattern repeated again and again.
I'm sure that either rotating the positions, or having individuals responsible for staying with each application throughout its life, or some other form of mixing, would have drastically improved both morale and quality of apps produced.
Most projects taken on by the company followed the same path: upstairs developers would code up the application as per functional spec, client would do a bit of UAT, accept it, publish it live, at which point the project was assigned to the support staff.
What generally happened next was the application would begin to fail on non-functional fronts, generally appalling performance and scalability problems.
Since there was minimal communication between floors (afterall, what could a 'proper' developer learn from a lowly support developer?), the pattern repeated again and again.
I'm sure that either rotating the positions, or having individuals responsible for staying with each application throughout its life, or some other form of mixing, would have drastically improved both morale and quality of apps produced.
The danger I had when I got good at debugging, is I came away with the belief that I needed to make mistakes impossible to make. In that regard, I did exactly as you say is unlikely. I left a world of debugging and wrote some highly over engineered crap. Pulling things back to make the mistakes obvious, not impossible, I've had much much more enjoyment.
I can also say that the thing you really need to do is use what you are programming. Or at least something like it. I don't know as that this is cross cutting, in that someone that uses a product may not be good at building it, but they are probably good at selling/describing it.
I can also say that the thing you really need to do is use what you are programming. Or at least something like it. I don't know as that this is cross cutting, in that someone that uses a product may not be good at building it, but they are probably good at selling/describing it.
What you've described is fundamentally a problem of communication.
You don't need to do multiple roles in order to understand them. You do need to listen to the feedback from each different area and then act on it so that your decisions don't create unnecessary work for others.
The restaurant scenario is one I've heard before and it's the literal version of putting yourself in the other person's shoes. Not workable in every situation (but kudos for having the balls to do it.)
You don't need to do multiple roles in order to understand them. You do need to listen to the feedback from each different area and then act on it so that your decisions don't create unnecessary work for others.
The restaurant scenario is one I've heard before and it's the literal version of putting yourself in the other person's shoes. Not workable in every situation (but kudos for having the balls to do it.)
How did your customers like the food made by servers, and the serving done by cooks?
Did you try switching roles with a cook or server? That would have been fun :-)
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.)
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.)
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
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.
[1] http://en.wikipedia.org/wiki/Team_Role_Inventories
Starter -> Resource Investigator
Architect -> Shaper
Debugger -> Teamworker
Finisher -> Completer Finisher
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.
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).
There's probably a few variations on these as well (and I might be misremembering them slightly).
Maybe this is better:
Architect -> Plant + Specialist
Starter -> Resource Investigator + Shaper
Debugger -> Completer Finisher
Finisher -> Teamworker + ImplementerNice
"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.
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.
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.
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.
[deleted]
Yes but isn't the rule that last 10% of a project takes 90% of the time?
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.
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.
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.
The four adjectives don't immediately create images in my mind of what qualities they represent.
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?
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?
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.
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.
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.
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.
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".
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".
> 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?
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?
I'm a good starter and a good finisher. It's the middle of the project where my motivation can dip, particularly on side projects.
I love taking a seed of an idea and running with it into prototypes etc.
And I also love doing that final layer of polish, trying to break my code and handle edge cases and tweaking user experience.
I think it's because I approach the start and the end from the users perspective, but then the middle of the project can sometimes feel a bit disconnected from the user.
Something like writing your persistence layer doesn't really feel as though it's contributing to the vision of what you want to build.
I love taking a seed of an idea and running with it into prototypes etc.
And I also love doing that final layer of polish, trying to break my code and handle edge cases and tweaking user experience.
I think it's because I approach the start and the end from the users perspective, but then the middle of the project can sometimes feel a bit disconnected from the user.
Something like writing your persistence layer doesn't really feel as though it's contributing to the vision of what you want to build.
I'm a a debugger. I can't stand to look at a blank screen since I never know where to start. However, I love it when someone toss a difficult bug at me. I can spend days pouring over code in nothing but a debugger and live for the rush when a simple change fixes everything.
We have a running joke on my team that I come out of the bullpen as the setup man and hand it off to our closer. We'll have meetings where it comes and my colleagues will say, "Put him in coach." It works for us since most people are starters and one guy is a great finisher.
We have a running joke on my team that I come out of the bullpen as the setup man and hand it off to our closer. We'll have meetings where it comes and my colleagues will say, "Put him in coach." It works for us since most people are starters and one guy is a great finisher.
> 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?
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?
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.
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.
I think most programmers can earn more by doing 'finisher work' than doing 'starter work'. I am a starter by heart, but I earn more money by maintaining a big Java system than I would have working for example at a small startup. Of course this is not true for prestigueous/famous programmers. They get the 'starter' jobs even in high-paying positions.
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.
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.
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".
With most sales on flippa I feel like I am playing "Find the scam".
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.
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.
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 & 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.
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.
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.
> 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?
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?
> 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.
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.
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 :)
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 :)
> 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.
No, you still have to fix it yourself. But at least there is a feedback element.
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.
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.
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.
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.
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.
My guess is the population here is dominated by Starters and Architects.
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.
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.
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.
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 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%?
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%?
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!
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.
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.
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.
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).
Is there somewhere I can write to get a better Debugger/Finisher?
Is there somewhere I can write to get a better Debugger/Finisher?
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
Does anyone have advice on how to become a better finisher?
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.
It helps to pick small projects in the beginning to not lose sight of the goal.
"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.
(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.
(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.
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.
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).
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).
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.]