Back in my Borland days, we were working hard on Paradox for Windows. I was a QA engineer testing the database creation and modification functionality. Jerry, my counterpart in engineering, was working hard, but getting absolutely nowhere.
We were mid-to-late in a 1.0 product cycle, and most of the engineers were slowly moving from development into bug-fix mode, but not Jerry. He was still implementing . . . over and over again. You are screwed because you’ve given a critical task to someone who is utterly unable to complete it.
Now, let’s first give Jerry a break. He was a fine programmer, but he had two major strikes against him. First, Jerry had never programmed for Windows, so he was learning while he was coding. Second, this was also a 1.0 product. Chapter 22 of this book is titled “1.0,” but its actual title should be, “1.0 spelled one point oh my god I’m never going to see my family again.” I’ll summarize: 1.0 is incredibly hard, and combined with his Windows inexperience, Jerry was in trouble.
Yet, Jerry had pride. Jerry believed that he could pull it off, but being on the receiving end of his code, I observed a disturbing coding practice, which we’ll call “moving crap around on your plate.” Jerry’s approach to fixing his bugs was to move his code around in interesting ways, much the way you used to shove food around on your plate in a feeble attempt to convince your mom that you actually ate your beets. Nothing substantially changes; it just looks different. Another name for this coding practice might be “coding by hope.”
The end result with Jerry’s code was that each time he’d fix something we’d discover another fundamental problem with the feature. Yes, small, incremental progress was being made with each bug fix, but Jerry was in a losing situation because his basic architecture was crap. When asked for status, his lists of excuses were astonishingly lengthy and believable. They were the excuses of a person who honestly believed he could pull it off and was willing to put in the hours to do it. But all the hours in the world weren’t going to help Jerry because he was in over his head.
If you’re the manager in this scenario, you’ve got to make a major change because you cannot release crap. There are companies that do this and end up making a tidy profit. You are not that person, because once you are rewarded for releasing crap, you begin a blind walk down a path of mediocrity that ends up with you working at Computer Associates on a product no one has heard of and that no one cares about.
It’s a two-step fix process. We needed to make a Jerry adjustment and then we needed a miracle. I’ll start with the easy one.
We needed Jerry. He’s the only one who knows what the hell is going on in that pile of spaghetti and he could fix trivial bugs. The engineering manager sat Jerry down and told him we need to focus on quantity. There were scads of trivial little fixes all over the place that had been ignored, and Jerry could handle those. Yes, his ego was bruised, but in a few weeks, Jerry was cranking because people always work better when they’re making forward progress on a task they have a chance of completing.
With Jerry on task, we had to face another fact: we were six months from shipping, and we had a major portion of functionality that was cobbled together and barely working. In this scenario, you need a unique talent. You need a free electron.
The free electron is the single most productive engineer that you’re ever going to meet. I have not even provided a definition and I’m guessing a person that fits the bill has already popped into your mind.
A free electron can do anything when it comes to code. They can write a complete application from scratch, learn a language in a weekend, and, most importantly, they can dive into a tremendous pile of spaghetti code , make sense of it, and actually get it working. You can build an entire business around a free electron. They’re that good.
There are two classes of free electrons, senior electronsand junior electrons. Both have similar productivity yields, but the senior versions have become politically and socially aware. In technology-savvy organizations, many CTOs fall into this category. Think Bill Joy. There’s always a risk that senior electrons can spin into a technology high-earth orbit where their ideas simply sound insane, but, whenever they talk, you should listen.
The junior versions have all the ability, they just don’t have the experience of dealing with people because they spent a lot of their youths writing their own operating systems as a fun intellectual exercise. These junior electrons represent the single best hire you can make as a hiring manager. If you get two in 20 years, you’re doing something right.
Care and Feeding
If you are lucky enough to have a free electron in your organization, you need to be aware you are dealing with a strange breed of engineer and the care of and feeding of this engineer might be different than the rest of the team.
Keep them engaged. First, there are two primary tasks in an engineering organization: research and development. While the free electron is eminently capable of doing development, their value in the organization is research. They define the bleeding edge. If you leave a free electron in the development role too long, they will vanish simply because they’re bored. All engineers like to be on the bleeding edge, but free electrons simply must be defining it. A departing free electron will permanently damage the productivity of your group.
Misdirected free electron intensity can yield odd results. On one project, I assigned a couple of slippery memory corruption bugs to a free electron who nodded quietly and promptly vanished for a week. When he returned, the bugs were fixed and the entire database layer had been rewritten. A piece of code that’d taken two engineers roughly six months to design had been totally redone in seven days. Sounds like a great idea until you realize we were working on a small update and did not have the resources or time to test a brand spankin’ new database layer. Oops.
Free electrons sometimes will not engage and they won’t explain why. Free electrons are high-functioning and have strong opinions about everything . . . but they may never tell you those opinions. If you’re asking them to do something that they don’t believe in, they aren’t going to do it. Ask all you want. The worst case is when you ask a free electron to pull off a diving save and they nod . . . and promptly return to whatever they were doing before you distracted them with your useless request. One week later, you’re going to be expecting the miracle, but the free electron is going to say, “Haven’t got to that.”
One week more, your hair is going to be mostly pulled out, and then you’re going to realize you didn’t need a miracle in the first place and that inaction was the right move. Your free electron knew that two weeks ago. They just didn’t want to take the two hours to draw the picture for you. Annoying, huh? You’ll get over it.
It’s a team. All of this advice is directed at your free electron, but you need to remember even though they’re incredibly productive, they’re part of the team. My advice shouldn’t be interpreted as giving free electrons special treatment any more than you give each person on your team your focused attention. There’s no need to call attention to the fact that you’ve got a free electron on your team. Trust me, everyone already knows it.
Back to Jerry
Enter Bernard , Borland’s resident free electron . Up until he started poking around the code, I had no idea what Bernard actually did. He had an office. It was full of books. He talked a lot and produced little visible work. “Blowhard” is what I thought.
Bernard started tinkering with Jerry’s code on a Friday afternoon. The next Monday, I was able to run through my functional test matrix for the first time ever. By the end of that week, Bernard had closed a majority of the high-severity bugs and was beginning to tread in fix areas reserved for Jerry . The following week I was racing to file bugs to keep Bernard engaged.
That is a free electron at work.