Tech Life The single most productive engineer

Free Electron

There’s a Screwed Scenario that I missed.

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. My counterpart in engineering, Jerry, 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. That’s the Screwed Scenario, 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. I’ve got an article kicking around my head about 1.0 product development… it’s titled “1.0 spelled One point oh my god I’m never going to see my family again and, dear lord, I’m going to take the company out while I’m at it.” Short version: 1.0 is incredibly hard and combined with his Windows inexperience, Jerry was in trouble.

Yet, Jerry has 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 substantively changes, it just looks different. Another name for this coding practice might be “Coding by hope”.

The end result with Jerry’s code was 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 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 wasn’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 can not 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 can 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, he was pissed, but in a few weeks, Jerry was cranking because people always work better when they know they have the ability to complete a task.

With Jerry adjusted, 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 has already popped into your mind that fits the bill.

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 getting it working. You can build an entire businesses around a Free Electron. They’re that good.

Free Electron Got’chas:

» There are two classes of Free Electrons. Sr. Electrons and Jr. Electrons. Both have similarly productivity yields, but the Senior versions have become politically aware. In technology savvy organizations, most CTOs fall into this category. Think Bill Joy. The Junior versions have all the ability, they just don’t have the experience of dealing with people because they spent a lot of the youth writing their own operating system as a intellectual exercise. These Junior electrons represent the single best hire you can make as a hiring manager. If you get two in twenty years, you’re doing something right.

» 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. Sound 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 never engage and they’ll never explain why. Free Electrons are high functioning and have a strong opinion about everything… but they may never tell you that opinion. 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 of a diving save and they nod in the affirmative 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 plainly 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 inaction was the right move. Your Free Electron knew that two weeks ago. He/she just didn’t want to take the two hours to draw the picture for you… Annoying, huh? You’ll get over it.

» You might expect Free Electrons to exhibit the personality of other uber-nerds, but often they do not. The main Free Electron at Netscape was the most decent human being I’ve met in recent memory. He also rode a unicycle.

» There are two primary tasks in an engineering organization. Research and Development. While the Free Electron is imminently capable of doing the 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 and you will have permanently damage the future productivity of your organization.

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 a 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.

16 Responses

  1. Regarding Computer Associates as you linked them in the glossary: ArcServe Backup. And my god does it suck.

  2. John Whitlock 11 years ago

    You say:

    The title of Free Electron comes from their habit of bouncing around the organizing and making stuff happen. While they are imminently capable of doing this, it is a waste of their talent. If you leave a Free Electron in this role too long, they will vanish and you will have permanently damaged the productivity of your organization.

    So, what is the proper role for a Free Electron?

  3. Dammit. That’s a good question, John.

    Been considering a response and I think it’s best put in the article… will update shortly.

  4. Ok. I’ve updated the article with the following Free Electron defining blurb:

    “There are two primary tasks in an engineering organization. Research and Development. While the Free Electron is imminently capable of doing the 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 and you will have permanently damage the future productivity of your organization. ”

  5. I was almost positive you were going to say Bernard just ended up blowing it too, and that’s what a Free Electron was.

    Sweet. It is so rare to find people like that though.

    Usually you either have the Architecture Astronaut syndrome or Gets Things Done but will blindly follow authority / implement crappy suggestions by management.

  6. Great essay, it created an idea in my head, the opposite of a Free Electron. I’m calling them Free Radicals. It could tie into your Screwed Scenario in that if you have some ratio more Free Radicals to Free Electrons, your company has cancer and it’s time to do something about it. I’m guessing it’s a 5-1 ratio but it could be higher.

    If you have as few as 2 Free Radicals and no Free Electrons, chances are your company will have cancer in the next 6 months.

  7. My friend worked for a company that got bought by a company that got bought by CA.

    He always called CA “where software goes to die.”

  8. Chris 10 years ago

    They are also called Hackers (

  9. You took the following out of the article and now you don’t have a explanation of the term anywhere:

    The title of Free Electron comes from their habit of bouncing around the organizing and making stuff happen. While they are imminently capable of doing this, it is a waste of their talent.

    Perhaps you should put the above back in?

  10. Agree with Ajay – I read the entire article and ended up scratching my head, wondering why you’re calling them Free Electrons. I had to head over to the comment section to find an explanation.

  11. Tom CF 10 years ago

    “While the Free Electron is imminently capable”…I think you meant “eminently” (i.e. wholly,without a doubt) as opposed to “imminently” (i.e. soon, any time now, but not just yet).

  12. I enjoyed reading this article. It reminds me of something that happened to me.

    After working on unix and dos for about two years, I left the company because I was constantly running behind the facts and fixing things for programmers who were at that company before me and therefore were regarded “more senior”. They kept on going without consulting me and I was the one fixing their problems.

    I then came to work for a small company that created apps for the Mac. Going from C to object-oriented Pascal. Learning each of the managers and not having the standard c-libraries and rewriting existing code for MacApp, boy, was that a transistion. The Mac compared to nothing I knew about unix, vax, system/36 or anything I had done in the past.

    I had a contract for six months and after four months I was told that I wasn’t productive enough. That most of that had to do with the equipment I had (no kidding: restart took 20 minutes, loading MPW another 15. A compile and link about an hour. One crash and the cycle started again; and I still was on schedule) was something they didn’t want to hear. From my job interview, they expected more. My contract would end two months later and I knew I needed to look elsewhere.

    I got my next job at another company that created apps for the Mac. The first day, after meeting with several coleages and after lunch, I got to our department. my boss told me that he did not have my workspace ready, but I could use his office and his Mac to get acquainted with their software; he would be in meetings. They had a license for source code from another company and I needed to study that. My boss gave me a list with ten bugs and told me to look into them.

    I admit, I was really going to show I was every bit as good as I had told them I was (and I believed I was). At about four, my boss came back into the office and asked me how things were going.

    Me: “I am not done yet”.

    Boss: *silence*

    Me: “Well, I found and fixed the first eight problems. I also found bug nine, but it is too much work to fix now. I think I found bug ten and I have a solution. I will be able to get it fixed today. As I see it, I will have fixed bug nine before noon tomorrow”.

    Boss *shakes his head*: “Let me see if I get this straight. We have this source and we add to it and we fix things. Every now and then, there is a bug that keeps eluding us. We keep track of those on a list. I thought it would be a good idea to give you that list, so you would have a reason to look around in the source. You are telling me that in the four short hours that you have been working at it, that you fixed eight and have the two remainding bugs fixed before noon tomorrow?”

    He stands up, walks to the door, shaking his head. Before leaving he turns around and says: “I don’t think you will have a difficult time getting through the trial weeks. Welcome to the company”.

    Soon after that, the company underwent some restructuring. A new department was created: product development and I was one of two in that department. My task was indeed to look for anything happening outside the company and to give advice when major modifications would be made to any of the products that we have.

  13. I can also relate to the difference between being junior and being senior. During the years I worked for that company, I had to come up with choices for technology or to come up with a design. With it comes an estimate for development effort.

    I had seen many of my colleages, who were loosing a lot of time on something that had been a “quick fix”. However, these fixes were meant to be a temporary measure, but years afterwards they still needed regularely to spent time on the problem.

    At my first meeting with the owner of the company we were discussing my solution and my estimate.

    Owner: “This estimate is for a solid solution, I assume. However, do you think there is a quick fix that will only take a couple of days?”

    Me: “There is no quick fix, sir”

    Owner: “Sure there is. All your colleagues always have a quick-fix alternative.”.

    Me: “No, there isn’t”.

    Owner *pissed*: “Ok, we’ll discuss this later”.

    My boss tells me later that he had a hard time convincing the owner to let me keep my job. Although I did a lot of work on many of the projects, it was thought best that I would not attend meetings if the owner would be present. Every communication between me and the owner would go via my boss. The owner and I talked when we met in the hallway, but never discussed anything related to a customer or a project.

    Over the years, I learned how to make a “no” sound like a “yes” or to just say “yes” and get away with “no” anyway. That is politics and that difference is what makes someone “senior”.

    I can understand (now) the situation that Rands is in. When I, as a programmer, make a change, then the result needs to be tested. However, as Rands is not a programmer himself, he probably doesn’t understand how the process of modification works (you need to be aware of the program-transformation step of the JSD methodology to begin to understand what I am talking about) and how you can rearrange/restructure code without causing it to produce a different outcome. (thus, the modification process should not need addional testing or I am doing something wrong)

    Spaghetti like code can be transformed step-by-step, even if I, as a programmer do not fully understand how the code works and so reorganise source into readable, well documented and highly structured code. After or during restructuring can a programmer choose to fix bugs or add features, but it is better to seperate those tasks. (Even better, since it is a process, a seasoned programmer should be able to do it on “automatic pilot”, allowing his brain to soak on other problems. If you really know your tools and your programming language, it is possible to be chatting with colleagues all through that process. To put it differently: you know that you understand a language completely if you can switch your brain off during restructuring of existing code.)

    I have trained many in programming, but this “clicks” with only a few. I don’t know why, since this has been obvious to me since the first time I had to fix some elses code.

    From what Rands write, I get the impression that it is indeed a rare capability. However, restructuring is even important for code I wrote myself to prepare it to add new features. How can anyone be a programmer and not be able to do this blindly?

  14. algal 10 years ago

    The real genius of this article is how it takes an absolutely commonplace idea (that the best programmers are 20x more productive than the worst) and makes it seem new and engaging by giving it a clever name and a little narrative wrapping.

    And what that demonstrates is the importance of marketing. But let’s not say “marketing”.

    What every orginization needs is a Human Megaphone. What is a Humann Megaphone? You’ll only run across three or four in your career. They seem like other workers. I once knew a … etc.

  15. Dig the free electron thing. Seen it, it’s real.

    But who I really like is the “moving crap around on your plate” guy.

    I’ve been on the receiving end of this and never new what to call it! My “crap mover” guy was great, at somethings, but sucked dreadfully at taking an open task and closing it.

    Thank you Rands. Owe you.