Careers

Confessions of a jerk

~ Andrew Stellman ~ Leave a comment

The worst kind of jackass is the kind that knows he's good

The other day I made this short, shameful confession in response to a Slashdot story about a Forbes blog post called When Smart People are Bad Employees. The post outlines three distinct types of bad employees. The third one was called “The Jerk,” and it sounded eerily familiar:

If a member of your staff is a raging jerk, it may be impossible. Some people are so belligerent in their communication style that people just stop talking when they are in the room. If every time anyone brings up an issue with the marketing organization, the VP of marketing jumps down their throat, then guess what topic will never come up? This behavior can become so bad that nobody brings up any topic when the jerk is in the room.

Here’s my confession: I’ve been that jerk in the past.

I was that really smart programmer that everyone listened to because I made really good software really quickly. But people hated dealing with me because I was obnoxious to deal with—and worse, I knew it and was openly arrogant about it. If snarky geek t-shirts had been around at the time (this was back in the mid-90s) I would definitely have worn them. When someone was wrong, I definitely let them know. If I didn’t respect someone, I would make myself unpleasant to deal with, enough so that it was easiest to just shut up anytime I was in the room.

I was a kid in my early 20s, and it was only my second job out of college, so I was really eager to prove myself. I came up with some pretty ingenious solutions to a couple of vexing problems. It was a small company, and one of the systems I built produced an entirely new product for their salespeople to sell to clients. They had some serious problems managing client information for their help desk, serious problems where their programming team wasn’t able to track bugs properly (these were the days well before tools like JIRA and Bugzilla were cheap or free), and managing large amounts of data. I built some pretty good tools, and they made a big difference. So people put up with my attitude, because it was a net win for everyone. But it made their jobs more difficult, just so I could engage in some personal ego gratification.

Actually, here’s something from that time that I find really funny. The company I was working for had all prospective employees take a Caliper Assessment test as part of the interview process. At the time, it was basically a combination of an IQ  (abstract reasoning) test and a personality profile, and the results were compiled into a report with a page of scores and a two-page writeup. My boss gave me a copy of my results when I came on board. My abstract reasoning score was 100%, and scores on the “extroverted” and “ego-driven” scales were both over 90%. The writeup said that I would be “a loose cannon,” but if I was “aimed properly, I would knock down any barrier in front of me.” It also warned that I would not play nice with people who I did not respect.

In other words, the Caliper report certified me as an extremely smart, highly capable, grade-A jerk.

So, first of all, kudos to the folks at Caliper. They definitely had my number, which was pretty impressive considering that it was based on a 100-or-so-question fill-in-the-bubble timed test. And they got that profile exactly right.

This all presented a really frustrating problem for the people at the company. Here I was, this kid who kept hitting projects out of the park. But I was truly impossible to deal with. I would barely let people finish sentences before cutting them off (“Okay, I know exactly what you want. You go away now.”) I perfected all of the programmer stonewalling tricks to get people to stop asking me questions: interrupting people with pedantic questions before they’d barely started getting to the point, sending people back with half-answers so I didn’t have to think through the question I was being asked, answering questions in a way that was obviously far too technical for whoever I was talking to so. And heaven help anyone who said something to me that was technically inaccurate.

I was belligerent to people around me. I was definitely immature and naïve. But people respected me and knew that I was worth dealing with, because I did really good work.

Eventually, though, a funny thing happened.

I slowly discovered that if I stopped acting like a jerk, life got a lot easier. I mean, obviously, it got easier for the people around me. But it got easier for me, too.

Unthinkingly, I felt that I needed to be a jerk to make people respect me. I think, on an intuitive level, that it was a kind of litmus test. People had to respect me, because if they didn’t respect me they never would have put up with my attitude. But what I found was that when I stopped acting like a jerk, people still respected me. Not only did they stop fighting me, but they actually went out of their way to help me.

Once I stopped being a jerk, it was a lot easier to do my job, and I’m convinced that I was actually able to produce better code because of the reduced number of bureaucratic headaches.

I wish I’d figured it out earlier.

(Hmm, on the other hand, I was asked to do more stuff because people were less afraid of me. So I guess… be careful what you wish for?)

A Few Things Every Job-Seeking Programmer Should Know About Project Management (part 2)

~ Andrew Stellman ~ 1 Comment

I’ve met a lot of programmers who really hate project management. And it’s not that surprising, because project management done poorly can be a pain. But if you’re a developer looking for a job, employers are more and more likely to expect you to know something about project management. Luckily, good project management can make your life easier, and it’s worth knowing about it—not just for job interviews, but to help you get the most out of your own projects. In part 1 of this post, I talked about a few basic things that I think every developer ought to know about project management. Now I’ll finish up by going into a few details that can help you run your projects more smoothly—and deliver better software.

Why you should care about project management

I’ve had a lot of developers over the years tell me outright that they think project management is stupid.

Some of the best developers I’ve worked with had pretty negative opinions of project management. At best, they’d say something like, “Well, that sounds good for another team, especially a really big team, but our projects run just fine without the extra overhead.” At worst, they think it’s malignant bureaucracy imposed on them by pointy-haired bosses. One bad experience can sour a good developer on project management. And that’s pretty unfortunate, because good project management can make a developer’s life a lot easier.

So why should a developer care about project management? I think the answer is in the Why Projects Fail talk that Jenny and I have done many times over the years, where we outline many different ways that projects fail. We got the idea from that presentation because we’ve spent years talking to many different people about the different kinds of project problems. We had to figure out exactly what it means for a project to fail. Obviously, if your project completely crashes and burns, it’s a failure. But the funny thing about a software project is that you can almost always deliver something – even on a project that everyone agrees is a failure, you’ll have code that compiles and runs.

So we came up with this definition of project failure:

  • The project costs a lot more than it should
  • It takes a lot longer than anyone expected
  • The product doesn’t do what it’s supposed to do
  • Nobody is happy about it

When we go through these things, we always get a lot of head-nodding, especially from developers. More importantly, we’ve never met a single professional software engineer with more than a few years of experience who hasn’t been on at least one failed project. We always ask for a show of hands to see if there’s anyone who’s never had a failed project. And we’ve yet to meet anyone who has. (We did get someone who raised his hand once, but I talked to him afterwards, and he was just messing with us.)

What does this have to do with project management? Well, everything! Have a look at a typical project management textbook, and you’ll learn about the “triple constraint” (which some people call the “iron triangle”) of scope, time, and cost.

(source: Head First PMP, 1st ed., O’Reilly 2007)

Project management really boils down to managing that triple constraint: balancing the scope of the work to be done, the cost of doing the work, and the time it takes to get the work done, all in order to get the best quality that you can. If you do that right, your project runs well, and your team is happy. If you do it badly, your project stinks, and you end up with a failure. And that’s why you, as a developer, should care.

I’ll go into a little depth about each of those things – scope, time, cost, and quality – just to give you an idea of why you should care about each of them. But the one that developers care about most is scope, so I’ll spend a little more time on that first.

Scope: the work and features that go into the project

Every project can be broken down into a small number (say, ten to twenty) features. For big projects, those features are big (“solid rocket boosters,” “reuse and reentry”); for small projects, those features are small (“holds 12 fluid ounces of liquid,” “screw-top cap”). And similarly, every project can be broken down into a small number of tasks that are needed to build those features. Project managers call the list of features the product scope, and they call the tasks the project scope – and a lot of people just talk about all of it as scope.

I’m consistently amazed by how much work a project team can put into a project without before they realize they’ve got a scope problem. Jenny and I talked about this in our book Applied Software Project Management in the section on scope problems:

A change in the project priorities partway through the project is one of the most frustrating ways that a software project can break down. After the software design and architecture is finalized, the code is under development, the testers have begun their preparation, and the rest of the organization is gearing up to use and support the software, a stakeholder “discovers” that an important feature is not being developed. This, in turn, wreaks havoc on the project schedules, causing the team to miss important deadlines as they frantically try to go back and hammer the new feature in.

Applied Software Project Management, p31

Does that sound familiar? If so, talking about the scope earlier in the project can really help. One way to help fix this is to put together a Vision and Scope document. It’s a really simple document, usually only a page or two, but it can really help prevent scope problems. It’s also a staple of project management. Once in a while, I’m pulled into a project that’s been running into trouble. I’ll spend a few hours talking to each of the team members, managers, and anyone else I can find who knows something about the project or needs it done. I’ll throw together a quick vision and scope document, and what I’ll often find is everyone had very different ideas of what would actually get built. And it’s usually a big relief, because everyone – especially the lead developers! – realizes that they were going down a path that would have had them waste a lot of time building the wrong software.

(source: Head First PMP, 1st ed., O’Reilly 2007)

Faster, better, cheaper—choose two… right?

There’s a whole lot more that I’m tempted to write about managing time, cost, and scope in order to get to the right quality level, but I really want to pare this down to the basics. There’s an old (and somewhat cynical) project management saying: “faster, cheaper, better: pick two.” What it means is that there’s no way to reduce cost, shorten the schedule, and increase quality all at the same time. At least one of those things absolutely has to give.

But there’s a reason that’s a saying and not a law! All three of those constraints are related to each other, and there’s almost never an easy, obvious trade-off where you can sacrifice one to improve the other two. If there were, project management would be a lot easier. It’s really easy to fall into a trap of trying to do the impossible, but the first step in avoiding a trap is knowing that it’s there. In this case, just knowing that every project is a balancing act between scope, time, and cost is a really good first step in making sure your project ends up running well.

I wanted to leave you with just a couple of thoughts:

  • One thing that makes the “time” aspect of project management tricky is that developers really hate giving estimates – or, more specifically, they hate giving estimates because they know they’ll be misinterpreted as hard commitments. I wrote a blog post about this a while back (The Perils of a Schedule) .
  • Every project needs a start, middle, and end. My old friend Scott Berkun writes about this beautifully in his book, Making Things Happen.
  • Cost doesn’t have to mean dollars – it’s often more effective to measure cost in hours.
  • Burndown charts really help, because they can make the cost seem real.
  • Sometimes the word “quality” makes developers a little nervous, because they start to think that improving quality just means doing endless testing. Sometimes it helps to replace a phrase like “high-quality software” with “software that we can be proud of.”

A Few Things Every Job-Seeking Programmer Should Know About Project Management (part 1)

~ Andrew Stellman ~ 4 Comments

I’ve met a lot of programmers who really hate project management. And it’s not that surprising, because project management done poorly can be unnecessarily restrictive. But if you’re a developer looking for a job, employers are more and more likely to expect you to know something about project management. Luckily, good project management can make your life easier, and it’s worth knowing about it – not just for job interviews, but to help you get the most out of your own projects. Here are a few basic things that I think every developer ought to know about project management, and why I think you should care about them.

Tough Programmer Interview Questions: Project Management

Programmers are often surprised when a job interview shifts from technical questions to questions about project management. I just saw a great example of this in a recent Head First C# forum post:

I am a C# programmer since 2003. I recently took a job interview where I was asked several questions about project management.

  • How do you make an estimate for building a C# program?
  • How is a project with 3 programmers different from project with 15?

– PiterKhasak

This is a lot more common that developers realize. I’ve seen a lot of discussion lately about how to do effective programmer job searching, especially for relatively new developers who have three years of experience or less. Did you ever ace the tech part of an interview, only to find that you didn’t get the job? I bet that a lot of the time it comes down to questions that seem peripheral or less relevant – to the a junior developer.

Not to a lot of senior developers. That’s one of the biggest differences in attitude that I’ve seen between people who are new to development and people who have been doing it for a long time. And in a lot of cases, I think it really does come down to attitude. So my goal with this post is to outline the basics of project management, the core things that really matter.

Why should you care about project management?

There’s a flip side to project management, too. A colleague of mine once asked me, “What’s the most important part of project management?” I told him that it’s managing stakeholder expectations – making sure that the people who have control of the project or are affected by it are in the loop on all the important developments as the project rolls along. If bad things happen, they know about them in advance, and are prepared. The reason for this is that some projects fail (more than you think!), often for reasons that have nothing to do with the team. If you manage everyone’s expectations, get them on the team’s side, then the developers can come out as heroes fighting a lost cause. On the other hand, a project can be a roaring success, but if everyone expects something that’s not exactly what was delivered, the developers could be blamed for something that they had no control over. Expectations matter, communication matters, and these things can have a big impact on the project and the team.

And that’s why developers should care about project management: it affects your life, even when your job is to keep your nose buried in code all day.

A lot of developers have a very poor opinion of project management and project managers. I’ve spent a lot of my career writing books and giving training to help project managers improve their skills. Over the years, I’ve met many different types of project managers. And, unfortunately, while there are plenty of great ones out there, there are a lot of really bad ones as well. In any field, there is a wide range of skill level and aptitude. If you’re a developer who’s only ever worked with poor project managers, it’s not surprising if you ended up with a dim view of the project management as a whole.

But even if you’re a developer who doesn’t have a high opinion of the field, you should at least acknowledge that learning more about it can have an impact on your own career. I’ve personally seen employers pass on good developers who didn’t know enough about project management, even ones who had the technical skills to do the job.

I’ve also conducted a lot of developer interviews, easily several hundred of them over the last decade. And one thing that I’ve noticed is that really good developers have a healthy respect for exactly the same things that really good project managers care about: the work and the features needed to create the software, the team that crafts it, the effort required to build it, and the quality of the final product. That’s why I think that learning more about project management can help make you a better developer.

In the next part of this post, I’ll outline those things, and make a case for why they should matter to you.