The Starter, the Architect, the Debugger and the Finisher
jacquesmattheij.com
jacquesmattheij.com
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.]
EDIT: Wow. A downvote. That what I get for showing the pain I experience to the world. :-)
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...
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.
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.
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.
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.
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.
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.)
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.)
[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.
There's probably a few variations on these as well (and I might be misremembering them slightly).
Architect -> Plant + Specialist
Starter -> Resource Investigator + Shaper
Debugger -> Completer Finisher
Finisher -> Teamworker + ImplementerPerhaps 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.
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 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.
The four adjectives don't immediately create images in my mind of what qualities they represent.
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?
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.
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.
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'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 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.
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.
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?
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.
With most sales on flippa I feel like I am playing "Find the scam".
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.
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.
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?
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.
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 :)
No, you still have to fix it yourself. But at least there is a feedback element.
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.
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.
My guess is the population here is dominated by Starters and Architects.
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 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 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%?
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.
Also, reading the Fountainhead was a game changer for me.
Is there somewhere I can write to get a better Debugger/Finisher?
It helps to pick small projects in the beginning to not lose sight of the goal.
(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.
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).