The Smartest Guy in the Room is Not the Best Developer

I started my programming career 20 years old ago. Sometimes I still cannot believe that it’s been that long. Come August 2016 it will be exactly 20 years since I accepted a Software Test Engineer job after finishing my undergraduate degree. I completed my degree in August rather than June because I needed to finish a difficult Discrete Math course at Rutgers University while delivering NAPA auto parts part-time. I drove those little trucks with the baseball hat on top while secretly peeking over the shoulders of the store counter employees using a terminal based inventory management system. I couldn’t help being drawn to a computer screen. Any screen. Even ugly green and black ones.

alt text

I couldn’t help being drawn to a computer screen. Any screen. Even ugly green and black ones.

The Test Engineer position involved working with C++ and VB3. The company employed about 25 developers in the United States, a dozen in England, and a handful in Ireland. This was back in the day when Microsoft and Sheridan data widgets ruled the world. My employer developed pharmaceutical software using the waterfall model. We had too. There was no other option. If I remember correctly the FDA requires that every software feature is validated using a 3rd party, usually a consultant house. The waterfall model caused long and sometimes hectic days at the end of the lifecycle. Unlike today’s iterative approach one could not just publish a change, nor interact directly with the customer. It was labor intensive (expensive). The software was delivered to the client on a CD produced by a full-time Configuration & Release Manager. I quickly learned that I did not envy that job.

Let me introduce you to “Brian”, a developer who worked there and had a Ph.D. in genetics. He was definitely a smart guy. A lot smarter than me. And I do not want to diminish his academic accomplishment. To be blunt, he was an arrogant jerk. Everyone avoided him – QA, project managers, developers, technical writers, and lowly testers as myself. He was horrible to talk too. You were considered brave if you attempted to ask him a work related question. If you tried to casually share with him a newly released Microsoft feature that you learned, he would say and act like he already knew about it (even when it was just released 30 minutes ago). As much as I hate to admit it, genetics is an interesting topic. Ask him a question about his Ph.D.? You were not worthy. Leaving his office discouraged you could not help noticing the degree was strategically hung on the wall for all to admire.

Ask him a question about his Ph.D.? You were not worthy.

I guess he’s right though. I mean, who am I anyway? Just some starry-eyed kid straight out of college. Sure I was far from being a good developer and lacked experience. But I knew how to treat people. Brian did not take criticism well at all. And I am not talking purely coding or algorithm criticism during a code review. One time after a small nerd argument in a developer meeting I politely (so hard to be polite to him) mentioned the other developer, named “Joe”, was just trying to help him solve the problem. Team effort, right? He became furious at me. I remember his head physically turning red. And I haven’t talked to him since. Not even a good morning, a goodbye, or a urinal nod in the bathroom.

Apparently Brian, the smartest developer in the room, was too dumb to work with others. His attitude and behavior were the opposite of collaboration. I definitely believe the company and upper management share some blame. I was too young and inexperienced to ask: do we really need to keep this guy around? His Ph.D. super smart guy know it all attitude brought negativity to the development team; the toxicity seeped to all departments. It was not jealousy. And the degree was not an asset as far as I could tell. Mapping/decoding the human genome wasn’t declared complete until 2003. Did they even use programming and statistics back in the 90s like scientists do today? Maybe since we were in the pharmaceutical field Ph.D. looked good on paper? If there was an employee vote, Brian would have lost his job.

As a junior guy, I learned nothing from Brian. And at the same time, I learned something. The most important lesson – associate with the smart, hardworking, consistent, day in and day out developers that deliver. Those guys are good communicators, are able to accept criticism, and at least consider alternatives to their problem solves. Knowledge was shared, not hoarded. They were practical, pragmatic, and did not write complex academic I am so smart code for trivial tasks. They produced easy to understand and testable code (unit testing was not formalized back then). And they took young bucks such as myself under their wing.

They were practical, pragmatic, and did not write complex academic I am so smart code for trivial tasks.

Yes, it was the 90s and companies were crazy hiring just about anyone. I could have pursued other opportunities, but decided to stay. And in two years I moved from Test Engineer to Software Engineer. I intentionally avoided Brian’s team (if you can even call it a team) and positioned myself with the smart, hardworking, consistent developers. This was not by luck nor accident. Other guys who wanted to move from Test to Development were required to pass a written and verbal coding exam. Afterwards, they were placed on a dev team similar to a post-boot camp military assignment. I could not take the risk of being placed on Brian’s team. I was young. But I wasn’t stupid (at least professionally not stupid).

Since I was one of the first testers at the company incorporate some automated testing with Rational Test and Visual Test, the development managers were able to somewhat gauge my coding ability. Additionally, I volunteered for minor coding maintenance work outside my normal test duties. Most were mindless and repetitive tasks. For example, I remember one my first coding efforts involved changing variable types that pointed to database primary keys from int (16-bit at the time) to long (32-bit) as we progressed from VB3, to VB4, to VB5 (control edition). More than 65,536 records seemed crazy at the time. My efforts paid off. And I was able to determine my own dev team assignment.

At the end of this story, Brian left several “great” ideas unfinished. And then left the company. Looking back and reflecting I am grateful for the experience. I try to sniff out people like Brian during the interview process both as an interviewee and interviewer - avoiding them like the plague.

The smart, hardworking, consistent, day in and day out developers that deliver? I intentionally positioned myself with them. I worked with them. I grew professionally with them. I asked questions (sometimes stupid) and received non-condescending answers. They demonstrated patience with me (most of the time). I absorbed everything (hard and soft skills) like a sponge. I learned. I listened. I was mentored.

Disclaimer: I am not anti-Ph.D.. I am anti-jerk.

Stay tuned for some more developer war stories as I remember them. Consultants Ate My Unit Tests was popular.