The Regenerate Web

A while ago Jeff and I had Eric Sink on the Stack Overflow Podcast, and we were yammering on about version control, especially the trendy new distributed version control systems, like Mercurial and Git.

In that podcast, I said, “To me, the fact that they make branching and merging easier just means that your coworkers are more likely to branch and merge, and you’re more likely to be confused.”

This is what Taco looks like nowWell, you know, that podcast is not prepared carefully in advance; it’s just a couple of people shooting the breeze. So what usually happens is that we say things that are, to use the technical term, wrong. Usually they are wrong either in details or in spirit, or in details and in spirit, but this time, I was just plain wrong. Like strawberry pizza. Or jalapeño bagels. WRONG.

Long before this podcast occurred, my team had switched to Mercurial, and the switch really confused me, so I hired someone to check in code for me (just kidding). I did struggle along for a while by memorizing a few key commands, imagining that they were working just like Subversion, but when something didn’t go the way it would have with Subversion, I got confused, and would pretty much just have to run down the hall to get Benjamin or Jacob to help.

And then my team said, hey you know what? This Mercurial bug-juice is really amazing, we want to actually make a code review product that works with it, and, and, what’s more, we think that there’s a big market providing commercial support and hosting for it (Mercurial itself is freely available under GPL, but a lot of corporations want some kind of support before they’ll use something).

And I thought, what do I know? But as you know I don’t really make the decisions around here, because “management is a support function,” so they took all the interns, all six of them, and set off to build a product around Mercurial.

I decided I better figure out what the heck is going on with this “distributed version control” stuff before somebody asks me a question about the products that my company allegedly sells, and I don’t have an answer, and somebody in the blogo-“sphere” writes another article about me junking the sharp.

And I studied, and studied, and finally figured something out. Which I want to share with you.

With distributed version control, the distributed part is actually not the most interesting part.

The interesting part is that these systems think in terms of changes, not in terms of versions.

That’s a very zen-like thing to say, I know. Traditional version control thinks: OK, I have version 1. And now I have version 2. And now I have version 3.

And distributed version control thinks, I had nothing. And then I got these changes. And then I got these other changes.

It’s a different Program Model, so the user model has to change.

In Subversion, you might think, “bring my version up to date with the main version” or “go back to the previous version.”

In Mercurial, you think, “get me Jacob’s change set” or “let’s just forget that change set.”

If you come at Mercurial with a Subversion mindset, things will almost work, but when they don’t, you’ll be confused, unhappy, and unsuccessful, and you’ll hate Mercurial.

Whereas if you free your mind and reimagine version control, and grok the zen of the difference between thinking about managing the versions vs. thinking about managing the changes, you’ll become enlightened and happy and realize that this is the way version control was meant to work.

I know, it’s strange... since 1972 everyone was thinking that we were manipulating versions, but, it turned out, surprisingly, that thinking about the changes themselves as first class solved a very important problem: the problem of merging branched code.

And here is the most important point, indeed, the most important thing that we’ve learned about developer productivity in a decade. It’s so important that it merits a place as the very last opinion piece that I write, so if you only remember one thing, remember this:

When you manage changes instead of managing versions, merging works better, and therefore, you can branch any time your organizational goals require it, because merging back will be a piece of cake.

I can’t tell you how many Subversion users have told me the following story: “We tried to branch our code, and that worked fine. But when it came time to merge back, it was a complete nightmare and we had to practically reapply every change by hand, and we swore never again and we developed a new way of developing software using if statements instead of branches.”

Sometimes they’re even kind of proud of this new, single-trunk invention of theirs. As if it’s a virtue to work around the fact that your version control tool is not doing what it’s meant to do.

With distributed version control, merges are easy and work fine. So you can actually have a stable branch and a development branch, or create long-lived branches for your QA team where they test things before deployment, or you can create short-lived branches to try out new ideas and see how they work.

This is too important to miss out on. This is possibly the biggest advance in software development technology in the ten years I’ve been writing articles here.

Or, to put it another way, I’d go back to C++ before I gave up on Mercurial.

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now.

Because so many people dive into Mercurial without fully understanding the new program model, which can leave them thinking that it’s broken and malicious, I wrote a Mercurial tutorial, HgInit.

Today, when people ask me about that podcast where I dissed DVCS, I tell them that it was just a very carefully planned fake-out of my long time friend and competitor Eric Sink, who makes a non-distributed version control system. Like that time he started selling bug-tracking software, and, to punish him, we sent him a very expensive Fog Creek backpack with a fake form letter that made it look like we were doing so well that expensive backpacks were the standard Christmas gift we were sending every FogBugz customer.

I seem to have run out the clock on this site. It has been an extreme honor to have you reading my essays over the last ten years. I couldn’t ask for a greater group of readers. Whether you’re one of the hundreds of people who volunteered their time to translate articles into over 40 languages, or the 22,894 people who has taken the time to send me an email, or the 50,838 people who subscribed to the email newsletter, or the 2,262,348 people per year who visited the website and read some of the 1067 articles I’ve written, I sincerely thank you for your attention.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

Maybe you have a job or two open. You’re reluctant to pay more than you have to for a given position. I understand that employers want to get the biggest bang for their employment buck.

I once consulted for an organization who had deliberately hired from the “bottom of the barrel.” (That was their phrase.) And, oh my goodness, they got less than what they paid for.

Getting to a release was a nightmare. And, because many of these folks were on H-1B visas, the people were desperate to keep their jobs. They would agree, as in say yes, to anything, because it meant they could stay here legally and keep working.

When the mix of work changed from commodity (keep the system going), to innovation (the market is changing, quick we need to change what we do), the technical staff was ill-prepared to deal with the changes.

Now, you don’t have to go outside the US to find not-highly-competent people. They exist here. We don’t need to import them. But the point is, the management in this organization had deliberately hired people they thought would be easily cowed, would be virtual slaves, and could do the minimum work for minimum pay.

Do a job analysis first, and know: what kind of hiring are you doing? Highly paid people can be competent for you–and they can be incompetent for you. You need to look at the environment in which people work, look at the problem, to find people who can learn the problem space and the solution space, and who can get along with others.

Don’t just look for the cheapest people. Look for the people who can do the work. Think about what you are hiring for, and pay for that expertise.

Tweet This Post

I’ve been working with teams who want to move to agile. Some people on their teams are in another location, where the salaries are cheaper.

It’s difficult to get agile started with a geographically distributed team. If everyone’s distributed, it’s easier than if just some people–especially if they are all one function, such as developers or testers–are. Or, if the people on the team know what it’s like to work in a highly collaborative environment, it’s ok, but not as good as when everyone is all together in one location.

The problem is that many managers have confused wage cost with project labor cost. Wage cost is a part of run rate, what it costs to keep the project alive for a week at at time. Yes, cheaper salaries will reduce the project run rate.

The problem is: what happens if the geographically distributed project takes longer to deliver the project? My experience says that all the geographically distributed projects I’ve met take longer to complete. The lack of being all in one place made a particular team take longer to deliver running, tested features. Here’s an annotated value stream map that represents this organization’s delays:

Wage cost is certainly lower in some parts of the world. But the only measure of productivity is running, tested features. If your project team takes longer to complete features, then you have a larger project cost.

Before everyone gets so excited about bits and pieces of remote team members, ask yourself, “Are we building in delays that will cause us to take longer to complete running, tested features? What will those delays cost us?” Now you can start to look at wage and project cost and make decisions that will make sense for your team–whether that means moving to agile or not.

Tweet This Post

At  right, a picture of Taco, a ten-week-old siberian husky puppy who moved in with us last week!

Some of you may have seen my final column in Inc., in which I announce my retirement from blogging effective March 18th, the 10-year anniversary of Joel on Software.

Writing for Inc. was an enormous honor, but it was very different than writing on my own website. Every article I submitted was extensively rewritten in the house style by a very talented editor, Mike Hofman. When Mike got done with it, it was almost always better, but it never felt like my own words. I look back on those Inc. columns and they literally don’t feel like mine. It’s as if somebody kidnapped me and replaced me with an indistinguishable imposter who went to Columbia Journalism School. Or I slipped into an alternate universe where Joel Spolsky is left-handed and everything he does is subtlely different.

I’m not going to stop writing altogether.

What I am stopping is the traditional opinionated essay that has characterized Joel on Software for a decade. I’m not going to write Ten Ways to Get VCs to Salivate, I’m not going to write Why You Have To Buy a $10,000 Italian Espresso Machine for your Programmers, and I’m not going to write Python is For Aspergers Geeks or Ruby is for Tear-streaked Emo Teenagers. After a decade of this, the whole genre of Hacker News fodder is just too boring to me personally. It’s still a great format... the rest of you, knock yourselves out... I just can’t keep doing that particular thing.

There will still be some posts here—don’t unsubscribe. There will be announcements of new projects, stories of things that I’m doing, and links to other things I might write, like HgInit, the Mercurial tutorial.

Philip Greenspun and Dave Winer (with DaveNet, even before Scripting News) pioneered the Internet Pundit style of essay writing which has served so well for fifteen years. They started as lone voices in a new medium, but the genre spread like wildfire. It was perfectly prognosticated in the 1990 Christian Slater movie Pump Up The Volume. If you’ve already forgotten it, here’s what happens (not a spoiler): Slater plays a kid with a low-power radio station in his bedroom, broadcasting in the middle of the night to the other isolated, angsty kids in his high school. Interesting drama ensues. 102 minutes later, by the time the credits roll, high school kids everywhere are spouting their opinions on their own pirate radio stations. And that’s exactly what happened with blogging, until we got where we are today, with millions of people expressing themselves and using the exact same narrative techniques and stories and styles that the first bloggers pioneered.

What we need now, I feel, is not another essay repeating No Silver Bullet for the 18,000th time. We need something that is more objective (based on measurable truth and falseness rather than just lists of anecdotes about successful projects and failed projects). We need something that reflects the best new ideas about what authorship means in 2010, not just electronic forms of 18th-century pamphlets. We need to stop rewriting the same things again and again (fail fast! NDAs are worthless! Execution matters, not ideas! Use the right tools for the job!). Instead we should start filling in the long tail of knowledge.

So that’s what I’m going to do with the next decade.

More details on my faux retirement:

• I’m drastically cutting back on speaking engagements. I already committed to speak at Business of Software 2010, in Boston in October, so that’s still on.
• This week’s StackOverflow Podcast will be the last in that format. Jeff and I are working on a new format and will come up with something exciting, new and different, so stay tuned for the details, but the current format is getting kind of tired.
• Although I appreciate that many people find Twitter to be valuable, I find it a truly awful way to exchange thoughts and ideas. It creates a mentally stunted world in which the most complicated thought you can think is one sentence long. It’s a cacophony of people shouting their thoughts into the abyss without listening to what anyone else is saying. Logging on gives you a page full of little hand grenades: impossible-to-understand, context-free sentences that take five minutes of research to unravel and which then turn out to be stupid, irrelevant, or pertaining to the television series Battlestar Galactica. I would write an essay describing why Twitter gives me a headache and makes me fear for the future of humanity, but it doesn’t deserve more than 140 characters of explanation, and I’ve already spent 820.
• The Joel on Software discussion group, in long decline, will close. The Business of Software group will remain open.

 

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

Steve Berczuk has a lovely discussion of Manage Your Project Portfolio. You can see his review here.

Tweet This Post

I like to work with recruiters. I’ve used them in the past. I refer people to them. But I am missing something here.

I just got off the phone with a recruiter. He was using some kind of a phone, either VOIP or a cell phone, but it cut in and out. I had to spell someone’s name for him twice. He didn’t hear me. I finally stopped the call because I couldn’t stand it. Stupid recruiter trick #1: Use a phone that makes someone unable to actually converse with you.

The other trick happened last week. A recruiter emailed me, looking for an “agile developer.” He said “rate is based on velocity.” This is so wrong in so many dimensions, I thought I had misread the email. I asked him. Nope, that’s what he meant. His reply, “Our client is not basing the rate on experience, but on how well and efficient the candidate’s code is.  Velocity = Productivity. ” Stupid recruiter trick #2: not understanding agile and pushing the hiring manager to explain what the manager is really looking for.

OMG. I thought that with the depression/recession, stupid recruiters would be unable to keep their jobs. I guess not.

Recruiters and hiring managers: personal velocity is meaningless, especially on an agile team. The team works together to deliver features. If you persist in measuring people’s productivity, they will game the system by always estimating stories as slightly larger than they are, or breaking stories down into tasks and assigning very large numbers to those tasks.

I won’t be referring people to these guys. TSTL. (In fiction, that’s a character who is Too Stupid To Live.)

Tweet This Post

Last week, when I was on vacation, my most recent Stickyminds column went up. I somehow expected more comments. Maybe other people were on vacation, too?

Tweet This Post

One of the problems many people encounter when moving to agile is that they (literally) cannot imagine iterations shorter than 4 weeks.

I rarely recommend an iteration as long as 4 weeks now, and if people insist on 3 weeks, suggest they find the root cause for the reason their iteration needs to be so long. “Our builds take too long” or “our testing takes too long” are the most common problems I’ve heard. If you know what causes you to need more time, you can make a conscious decision about what to do. Do you want to address that technical debt now? or later? Every time your iteration needs to be long, it’s because you have technical debt of some sort. You can choose not to address that debt now–but be conscious of that debt.

There was a question about the length of iterations on the scrumdevelopment list. Ron Jeffries said that he and Chet regularly paired in 2-hour iterations. With our teleclass, Gil and I often pair for an hour or two. We decide in advance how long to pair for, so we timebox our time, and then we do the work.. We have daily standups where we replan what we’re doing for the day.

Does it make sense for you to have one-day or shorter iterations? It depends on who your customer is and when you can get feedback. But why not consider how short your iterations could be, and remove the obstacles to those shorter iterations? Your project will thank you.

Tweet This Post

New StackOverflow developer Kevin Montrose (6,878 reputation) added a neat feature to the career site that makes it a zillion times easier to file a CV if you’ve already put in your job and education history on LinkedIn or FaceBook. Try it out.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

A few people heard me on This Week in Startups (starting at 15:45) asking Jason if we should take money from the first VC who fell into our laps, or spend time doing the Sand Hill Road rounds, meeting more VCs, and doing a road show for the other firms that might be interested in investing.

Jason (and his guest James Segil) both agree that we should take more time picking the right partner. We’re going to be in bed with these guys for years, they say, and we have to approach this like picking a spouse.

Anyway, people emailed me in shock and surprise that we would even consider VC, considering the things I’ve written.

flickr.com/photos/niznoz / CC BY-NC-SA 2.0Why are we seeking venture capital for StackOverflow?

Almost ten years ago, I wrote about two kinds of companies, the Ben and Jerry’s type of company, which grows carefully and organically, and the Amazon type, which uses huge amounts of investment capital to get big quickly.

At the time, I had no doubt that I wanted Fog Creek to be a Ben and Jerry’s type of company, and that model has served us well. By staying profitable and growing carefully, we’ve managed to survive two big downturns and we’ve grown into a stable, 34-person company that’s a great place to work and is likely to remain stable, and a great place to work, for a long time.

StackOverflow, though, is a bit of a different story.

There are a few indicators for the type of company that I believe can benefit from, and should take, VC.

1. There’s a land grab going on. The business is in a new field with no competition, but the field has proven itself, and is obviously going to get very crowded very soon, so the faster you can grab territory, the better.
2. There is a provable concept that’s repeatable. I always point to the example of the Starbucks IPO, which was brilliant because it was so simple. Every new Starbucks store that opened in Seattle became profitable in a matter of months. They tried a couple of stores in Chicago and Washington just to make sure it wasn’t a Seattle thing, and those worked even better. Thus, the formula of opening as many stores as possible was as close to a sure-thing as possible, so raising money was a no-brainer.
3. The business itself could benefit from the publicity of getting an investment from someone who is thought of as being a savvy investor.
4. The investor will add substantial value to the business in advice, connections, and introductions.
5. The business can potentially have a big exit or become a large, publically traded company.
6. The founders are not in it for their own personal aggrandizement and are happy to give up some control to make the business more successful.

There are counter-indicators, of course: signs that you shouldn’t consider VC. Here are just a few off the top of my head:

1. If the founders are risk-averse and are willing to trade a much smaller payout for lower risk.
2. If the founders are technical without substantial business experience and wish to maintain absolute control forever.
3. If the investor is mostly “dumb money,” i.e., someone who doesn’t know about the field. The proverbial dentist, who is happy to give you a half million bucks, but doesn’t know the first thing about CPMs and CPCs and CTOs, so you might as well not bother.
4. If you’re going into an established field with a lot of competition, there’s no benefit to speed; you’re better off slowly building a niche business and growing from there, quietly taking one customer at a time away from the competitors.
5. If the product is immature and unproven, in which case, expensive marketing efforts will be wasted proving to the world how bad your product is.
6. If the founders don’t have enough of the right kinds of industry connections, or the idea is not compelling enough, so that raising VC would take months or years
7. If there is any other way to raise the kind of money you need, for example, by selling actual products to customers.

When I put all these things together the conclusion is that StackOverflow is one of those rare companies for which VC can really work. Jeff and I started out with a goal for StackOverflow of changing the way programmers and system administrators get answers to their questions on the Internet, which was deeply broken. In 18 months we’ve accomplish that: we’ve got 6 million unique visitors every month. Now we’re biting off the bigger goal of changing the way everyone gets answers to their questions on the Internet, and that’s something we can’t do alone.

So, off I go, on a StackOverflow road show. I’ll be in Silicon Valley Feb 24-Mar 3; drop me a line if you want to get together.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

In the early days of a technology startup, you tend to have a lot of software developers, and you feel like you could never have enough. If you hire sales and marketing staff too early, they don’t really get much traction, and you may start to think that sales and marketing are a waste of time. This led me, in the early years, to believe that a healthy software company should have a lot of real software developers and maybe no sales and marketing.

At one point I entertained the quixotic and, retrospectively, stupid idea of requiring every employee at Fog Creek to be a programmer... even the receptionist would have to have done some BASIC programming in high school to qualify. In the US Marines everyone, even the cooks, is a rifleman. Of course that’s because the cooks are in friggin Afghanistan getting shot at so they better be riflemen, whereas our receptionist almost never has to drop into the source code and bang out a class. Almost never.

Over time, though, as your product gets better and better, the more sales and marketing people you hire, the more you sell.

That’s because programmers multiply salespeople, and vice-versa.

I’m a nerd, so I’ll be real math-y about this. Define the quality of your code on a scale from 0 to 1.

0 means your product solves absolutely no problems for anybody so nobody in their right mind would ever buy it. Microsoft Bob.

1 means that every single person on Earth, if they bought your software, would be net happier, even after paying your fee.

Your software starts at 0 and slowly climbs up the hill.

If everybody in the world knew about your software and was encouraged to evaluate it, the number that would buy it would be (Earth population) x Quality.

Sales and marketing functions exist to encourage earthlings to find out about your software and evaluate it. These functions will have no effect on sales if your quality is extremely low. But as the quality gets higher, the value of sales and marketing goes up, commensurately. Double the quality, and the same sales effort yields double the revenue.

The population of the planet is so large, and the effect of sales and marketing so hard to scale, that by the time your product is really great, the optimal ratio might be very heavily tilted in favor of sales and marketing. Large software companies might have 5 or 10 or 20 people in the sales organization for every developer.

This explains, among other things, why US software companies can’t expect to get sustainable advantage by offshoring software development to cheaper countries. If a developer in Russia, India, or China costs 50% as much as a developer in Seattle, San Francisco, or Boston, but software development is only 10% of your costs, you can only get a 5% advantage from offshoring development. The offshoring that does happen is strongly biased to custom software development which, by design, can only solve one person’s problem, so more developers than marketers are needed.

It is not the case (as commonly believed by nerds) that marketing is a substitute for code quality. The best marketing in the world cannot force people to pay for a useless product.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

I’ve been working with Gil Broza on our teleclass series, Prevent Your Agile Titanic, both on marketing it and on its content. And it never fails, we have questions for each other almost every day. Sometimes I’m developing something and it looks “funny.” So I ask for review. Sometimes, as with the content, we discuss and one writes, and then we switch.

Pairing seems natural to us. We hadn’t paired before this venture, and that doesn’t matter. We are both ready to pair, which helps. Neither of us have egos that get in the way of the outcome: a great series of classes.

Tweet This Post

Erik Gfesser posted a lovely review of Manage Your Project Portfolio. Thanks, Erik!

Tweet This Post

I wrote a little article about Barriers to Agility in the most recent version of PragPub, the online magazine from the Pragmatic Bookshelf. There’s a bunch of other good articles in there, too. Andy Lester has a great article about speaking as a way to practice interviewing, a bunch of comments/thoughts/rants about the iPad, and much more. Take a look!

Tweet This Post

I just returned from Tokyo, where I keynoted at JaSST, the Japan Symposium on Software Testing. 10 years ago, when they started the conference, maybe it was just about testing, but now it’s evolved to be about quality in the organization.

Some highlights from my trip:

• Everyone (and everything) I met appeared quite orderly. Everything had a place and everything was in its place. I saw this at the lost-luggage counter, in the hotel, and at the conference.
• I was pleasantly surprised that the subway ticket machines had an “English” button so I could buy my ticket and know what I was doing. The maps were in English as well as Japanese, so I could know in advance what my trip would be and which stop to get off at. I had a little trouble with which track, but that’s probably because I was jet-lagged.
• I was pleasantly surprised to see evidence that the simultaneous interpretation for my keynote worked fairly well. I could tell because people laughed when they were supposed to :-)
• For the tutorial, I did not allow enough time for the consecutive interpretation or for the questions about agile, so I needed another 20 minutes, which I did not have :-(
• I was a little concerned that when the panel prepared for the questions, I thought we might be boring. Nope, we were thought-provoking and funny.
• My Japanese hosts were amazingly solicitous and helpful for my entire experience: to/from the airport, to/from the conference, to/from sessions at the conference

I had a blast. I hope I have an opportunity to return to Japan. Now, all I have to do is get enough sleep so I’m awake during the day…

Tweet This Post

I read a lot about speakers practicing authenticity. (Huh?) All the suggestions seem reasonable, yet contrived to me: act interested in your audience, use your current location in your speech, remember to thank people at the end of your speech.

If you don’t want to be a speaker, don’t. If you do want to be a speaker, you may do those things, because they make sense. You don’t do them to practice authenticity, you do them because if you love speaking, you do it. You are authentic because you care about your job.

It’s the same thing with interviews and thank you notes. If you love your job, and you’re interviewing candidates, you don’t have to remember to thank people for coming in for the interview. You don’t have to remember to thank people for their time at the end of the interview–you’ll do that because you are an authentic human.

If you’re like me, you need a little checklist/reminder at the beginning of the interview process to stop work-as-normal, and start interviewing. I don’t need to remember to smile, I need to remember to put away the day’s work and focus on the interview. As a hiring manager or team member, you might need some other remembrances.

And, if you’re a candidate, and you liked the interviewer, the team, the organization, by all means, send a thank you note. If you have questions, ask them. If you have concerns, and they are minor, say you want another conversation.

But if you have major concerns or don’t want this job, say so. Or, don’t write a thank you note. Don’t write a fake note, saying you want the job when you don’t.

Authenticity is a necessary part of interviewing–from either side. So, don’t practice authenticity–be authentic.

Tweet This Post

My sister got her kids a little puppy, and they’ve been trying to train it. To live with a dog in the house, you need to teach it not to jump on people, not to poop in the house, to sit on command, and to never, ever, ever chew on the iPad. Never. Good girl.

With dogs the main trick to training is that feedback has to be immediate. If you come home to discover that, hours before, the dog tipped over the garbage can in the kitchen, it’s too late for training. You can yell at her but she just won’t get what you’re going on about. Dogs are just not that smart.

For programmers, getting better at what you do requires quick feedback, positive and negative, on what you’ve just done. The faster you get the feedback, the faster you’ll learn. With long-cycle shrinkwrap software, it can take a year or more to hear feedback from customers.

That’s one of the reasons we have testers. A great tester gives programmers immediate feedback on what they did right and what they did wrong. Believe it or not, one of the most valuable features of a tester is providing positive reinforcement. There is no better way to improve a programmer’s morale, happiness, and subjective sense of well-being than a La Marzocco Linea espresso machine to have dedicated testers who get frequent releases from the developers, try them out, and give negative and positive feedback. Otherwise it’s depressing to be a programmer. Here I am, typing away, writing all this awesome code, and nobody cares. Boo hoo.

Who should be a tester? That’s tricky! Software testing is one of those careers that isn’t that well known, so a lot of people who would be great at testing and would probably enjoy it a lot never consider applying for jobs as testers.

Signs of a good tester:

• Scientific
• Loves a good puzzle, even the kind that takes days to solve
• Likes to think about things methodically
• Generally likes working with software and computers

You don’t have to be a programmer to be a tester. A lot of companies want testers to be programmers who write automated test suites. It seems more efficient that way. This reflects a misunderstanding of what testers are supposed to do, which is evaluate new code, find the good things, find the bad things, and give positive and negative reinforcement to the developers. Sure, automated test suites are a time saver, but testing software covers so much more than that. If you put too much emphasis on those scripts, you won’t notice misaligned text, hostile user interfaces, bad color choices, and inconsistency. Worse, you’ll have a culture of testers frantically working to get their own code working, which crowds out what you need them to do: evaluate someone else’s code.

A particularly terrible idea is to offer testing jobs to the programmers who apply for jobs at your company and aren’t good enough to be programmers. Testers don’t have to be programmers, but if you spend long enough acting like a tester is just an incompetent programmer, eventually you’re building a team of incompetent programmers, not a team of competent testers. Since testing can be taught on the job, but general intelligence can’t, you really need very smart people as testers, even if they don’t have relevant experience. Many of the best testers I’ve worked with didn’t even realize they wanted to be testers until someone offered them the job.

If you:

• Love software and computers
• Want to work on a software team, and
• Don’t particularly like programming

you should consider being a tester. (We’re hiring! What a coincidence!)

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

Steve Krug has written a follow up to his usability classic Don’t Make Me Think. The sequel, Rocket Surgery Made Easy, is a terrific, short, concise, fun guide to running simple “hallway” usability tests to improve the usability of your software and websites. Highly recommended.

 

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

“As companies expand, the people within them start to specialize. At such a point, some managers will conclude that they have a ‘keep everyone on the same page’ problem. But often what they actually have is a ‘stop people from meddling when there are already enough smart people working on something’ problem.”

From my latest Inc. column: A Little Less Conversation

 

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

I’ve been busy the last couple of weeks, first preparing and then delivering the teleclass, 3 Crucial Factors for Preventing Your Agile Titanic. If you missed the call, you can still sign up for the replay. If you like what you heard on the replay, join us for the whole series of calls, starting Feb 8, 2010, and  sign up now.

Yesterday, I also did a webinar with Donna Reed, Selecting and Managing the Best Lifecycle for your Project, Team & Solution. Long title, good content :-)

And, the great folks at Dzone posted my video made during the Agile 2009 conference where I spoke about managing the Agile 2009 conference, where I think agile is going, especially for management.

Tweet This Post