This blog post is intended to sabotage any chance that I’ll get a “normal” software-engineering job, because I don’t think I could ever go back to a “normal” job.

I’ve become used to extraordinary jobs, not “normal” jobs.

The following 10 things, which I hate about software development as practiced in much of the industry, I think will keep me from ever being successful or happy in a “normal” software-development job.

Along with them, I list the antiviruses that I hope will help me avoid these diseases, if I need to go back into software development, even temporarily.

Incompetent managers. Software development managers in general graduated from being software developers. Unfortunately, the skills you need as a developer are different than the skills you need as a manager. The best manager I ever had was not a particularly good or experienced software developer. Rather, she treated management as a profession, read books on how to be an effective manager, attended seminars, took classes, and as a result, she was good at her job. But most software-developers-turned-managers don’t treat management as a profession. Instead, some of them become telepaths, who expect you to know what they need without actually telling you; others become micromanagers, who expect to be able to do all the actual development themselves, using your eyes and hands and brain; still others become arguers, the worst of both worlds, who instead of letting you do your job, take great pride in pointing out everything they think you did wrong. So the next software job I take, I will be interviewing and trying managers carefully to make sure they know how to manage, regardless of whether they are good developers.

Snotty developers. I must confess to going through a snotty phase myself. It’s part of growing up. You have to live as a snot-nosed, young-whippersnapper, green-behind-the-ears code slinger before you can mature into a wizened Yoda figure. In fact, part of me still may be a snotty developer. I’m definitely snotty when it comes to my own work, because I don’t want anyone telling me how it should be done, as long as I achieve the intended results. But as someone who’s been doing this shtick for 20-something years, I’ve grown weary of junior colleagues telling me I don’t know what I’m talking about. And when something doesn’t work out as well as they thought it should, they persistently maintain that it had nothing to do with them, despite the fact that they had ignored every piece of advice I gave them. There’s only one sure-fire remedy I know of for this problem, and that is to insist on a higher rate of pay. People may balk at paying you through the nose, but when they have to—especially managers—they not only accept your advice, they seek it out, because for the money they’re paying you, they expect you to solve their problems.

Commoditization. That is, the devaluation of specialized knowledge. The most obvious manifestation of this disease is the company who outsources its development to a third-party contract shop in India or Mexico, and then wonders why the project is falling apart at the seams. A more insidious and pervasive symptom has employers and clients boil a job down to a long list of buzzwords, pattern-match résumés to those buzzwords, interview you to make sure you really do qualify for the buzzwords selected, and then look for the lowest price. And then they ask you to do everything under the sun, including those tasks that could be handled by a $20/hour contractor from Mexico. Instead, they ought to be looking for solutions to specific problems or for people to fill specific roles within the organization. For veteran jobs, that’s no longer about price, however, because if you’re specific enough, you’ll likely find only one or two qualified candidates, if you search for them, and whatever they want to charge you, you’ll pay. Again, the only sure-fire antivirus I know of is to demand a higher rate of pay, because for the money they’re paying you, they won’t treat you like a commodity.

Slipshod engineering practices. I am one of those programmers who actually believe software development is engineering. Many developers don’t believe in software engineering, or at most give it only lip-service. But software engineering is like gravity: you may not believe in it, but the result is the same when you step off that cliff. Developers who don’t believe in engineering experience bugs, hold-ups, overwork, and stress. To account for it, they blame the code, the programmers who worked on the software in the past, their development environment, the operating system… But they never do anything to fix it, because “we just don’t have the time.” Note, however, just because developers complain about not having enough time to fix the system doesn’t mean they’re using slipshod engineering practices. In fact, those developers who don’t complain are probably the worst offenders. Often, good developers complain about the code, but it’s really not that bad, because they’ve already fixed the worst parts of it, and the problems that are left just stick in their craws. These are the developers I’d love to work with. The quickest way I know of to assess the situation is to look at the code: Is it well-architected? Well-designed? Are there unit tests? If so, the team is probably using good engineering practices.

Neglect of quality. By “quality,” I don’t mean over-designed, fluffy, overly glitzy software. What I mean is, simply, software that works, that satisfies the customer’s needs, makes the customer swoon, has no bugs, does not constantly poke you in the eye—”See that?!” Ow! “See that?!” Hey! Cut that out! Quality is important, because it gives a team of engineers a sense of accomplishment, of pride, a healthy morale. And engineers who value quality will be professional, always improving their craft, always building better and better software. Again, a quick glance at the codebase should give some idea as to how highly the team values quality, because a quality team will use sound engineering practices. But you could also look at the finished product, and especially customer comments on the product and its support.

Black-and-white thinking. Frankly, I hate having my good ideas shot down with dismissive comments like: “Unit tests don’t catch every bug.” Yeah, but they catch more bugs sooner and cheaper than any other method of testing. Polarized, black-and-white thinking is actually a sign of depression, of hopelessness, of having given up. “My life isn’t perfect; therefore, I have no reason to live.” Sounds silly when put that way. But how many software teams are in a similar, self-imposed depression? “That technique can’t solve all our problems; therefore, it’s not even worth trying.” Almost every team has a naysayer, but such sentiments can cause actual depression in the more innovative among us, who actually want to better the team and its engineering practices. The antivirus is simple, if not easy: Early in working with a team, try to find one or two simple process problems and propose simple, direct solutions. Then sit back and see what happens. If you get a lot of hemming and hawing and ignoring and naysaying, think about whether you should split.

Focus on establishment. Humans have a natural need for stability and for camaraderie. That is, they need to feel like the floor is firm beneath their feet and that there are others on their side. But in some companies, these tendencies can become dysfunctionally pervasive. If you continue to do only what you’ve always done, only what everyone else is doing, you’ll always be safe from blame. But humans also innately need to do what they haven’t done before, to stretch their minds, to create. Because this gives one a sense of purpose. Rather than playing it safe, we should always be trying new things, and keeping those that work. But the dysfunctional company focuses on establishment, rather than on results. The antivirus is similar to that for black-and-white thinking. Early in the experience, try something new, and then see what happens. Do it early, before you develop an emotional investment in the project. It might even be best if the thing you try fails completely, because then you can see how the team handles failure. Even if your experiment fails, they should not make you feel like a failure for having tried it. If they do, think about whether you want to stay there.

Ignorance of modern research. Quick! Name at least 2 of the 9 teamwork-killers Tom DeMarco and Timothy Lister identified in their landmark work? It should be pretty easy, because they identified 7 of those 9 back in 1987. That’s what I mean by “modern.” Here’s another one: What 3 characteristics must a software team exhibit in order to have any reasonable chance of success, according to Alistair Cockburn in his research? Peopleware (2nd ed. 1999) and Crystal Clear’ (2005), for starters. This is what I mean by “modern.” Heck, we might as well even include The Mythical Man-Month in the list, because too many software engineers have never read it, either. At my next interview, while the development staff are quizzing me on my knowledge of Perl programming, PHP, and JavaScript, I’ll be sure to quiz them on their knowledge of Demarco and Lister, Cockburn, Schwaber and Beedle, Kent Beck, Michael Feathers—and of course, Frederick Brooks.

The blame game. Being caught in the blame game can cause stress, exhaustion, demotivation, and depression. It can also be the source of other maladies, such as black-and-white thinking, as engineers attempt to cope. Unfortunately, staffers don’t usually like to talk about the blame game, but a pointed interview question might reveal something. Something like: “Tell me about the last, big mistake someone made that cost the company money.” What was the fallout? Did anyone get yelled at? Fired? In a perfectly healthy organization, no matter how bad the error was, no one will have gotten yelled at; rather, it will just be accepted that everyone makes mistakes, because we’re all human, and the whole team will have looked at the process (rather than any particular person) to see how to avoid an analogous oops in the future.