My Quest for Mediocrity

“How would you rate yourself as a programmer?” They always have to ask THAT question in job interviews. And I hate it. So much. Why do I hate it? Because I know they won’t like my answer. But what am I supposed to do, lie? Nope. I have to be honest. Which is why I take my time before responding. I take a deep breath, look deeply into the eyes of the interviewer, and, finally, I say: “Average.”

That’s right. I consider myself an average developer. And I’ve worked darn hard to get there.

Don’t Be a Dojo Champion

I’ve been at this IT thing for 30 years now and strongly feel that my drive for mediocrity is the proper strategy. I initially learned that strategy as a martial artist in the ‘70s. At every dojo, there is always one person that is the standout: the dojo champion. When I was 16 years old, I was a dojo champion myself. And I thought I was something special. Until I started competing at tournaments. The pedestal I had placed myself upon came crumbling down. I quickly discovered that I really wasn’t a standout. In fact, I found out that I really couldn’t even consider myself average. I had a huge desire to get better and, as it turns out, getting within the mathematical mean needed to be my first goal. I discovered that some dojos had open sparring sessions on Friday nights and Saturday mornings. So I began attending those sessions with a vengeance. All the regulars in those groups truly wanted to be standouts. They knew they needed real-world competition to do that. It wasn’t enough for them to merely be a dojo champion. They wanted to go to tournaments and kick ass!

Every now and then, a new guy would join our open sessions, clearly rating themselves as expert or top notch. After all, they were their dojo’s champion. Let’s just say the sparring sessions usually didn’t go so well for them. And many we’d never see again. Apparently, they were happy to remain paper tigers. But others would continue attending and would literally fight their way to mediocrity, and carve themselves a place among the best fighters in the county. Sometimes, they’d even become better than average, and now and again, top-tier fighters. Myself? After fighting my way up to average in that highly-competitive group, I never became the best. That was fine by me because I knew I was constantly improving. And, yeah, I was kicking some serious ass at tournaments.

Smartest Half-A-Dozen Coders I’ve Ever Met

After getting into the IT field, I continued the strategy of surrounding myself with people that challenged me. In the early ‘90s, as an RPG/Cobol developer with a business degree, I somehow talked my way into a job as a C++ Systems Programmer at ASNA. ASNA provided a number of tools for the AS/400 market including: a C-compiler, a dynamic systems performance tuner, and a debugger for RPG and Cobol. They were also working on a Windows-based version of the RPG programming language. Before introducing their RPG tool to the industry, they paid a well-known AS/400 programming language expert, Paul Conte, to come down to their San Antonio office for a week and, essentially, bless their enhancements to the RPG syntax. A few months after Paul Conte’s visit, I was speaking with a writer friend of Paul’s, Roger Pence. Roger told me that after Paul came back from that visit he told him: “I’ve just met a half-a-dozen of the smartest developers I’ve ever met!” I laughed out loud, and he said: “What’s so funny?” “Well,” I said, “ASNA has seven developers. I know I’m the one that didn’t make the half-dozen list.”

The thing is: All the ASNA developers, but for me, had masters degrees in Systems Programming. I was constantly learning from everyone in the team and I had to work my ass off to get to the point where I could be considered average.

Surround Yourself with Programmers That Challenge You and Build a Collaborative Workplace

I’ve worked at places where there were plenty of good developers but the collaboration was little to none. In the late ‘80s, I was on a 12-person team of Cobol programmers. To say we were a team was, initially, a misnomer because we were really 12 autonomous developers that worked on the same project, but on completely separate tasks. I couldn’t stand that autonomy because I knew I had a lot to learn from the other developers (perhaps because I had little to no Cobol experience when I took that gig.) So I started to do cubical dancing and ended up getting about six of those dozen developers to collaborate regularly on tasks. The result? We each got our tasks done in less time, had more fun, and learned a lot from each other.

My point is, you need two things to be coerced into improving your skills:

1. Other programmers that challenge you.
2. A collaborative workspace that enables the sharing of skills.

Once those two essential elements are in place, be sure to:

• Learn to ask for help;
• Pair program;
• Ask others what they’re reading or have learned lately.

Learn to ask for help:

Corgibytes uses Slack to post questions and request pairing sessions. It’s rare to not get an almost immediate response to a request for help. The worst we get is something like: “Hey, I can help in two hours.” Asking for help can, initially, be quite hard — because you think you are making yourself vulnerable by suggesting you don’t know a technology. But vulnerability is not weakness. It’s even in our core values! As Dr. Brené Brown puts it: “Vulnerability sounds like truth and feels like courage. Truth and courage aren’t always comfortable, but they’re never weakness.” And, as much as it’s good practice to ask for help, please do remember to also give help whenever it is asked.

Pair program:

At Corgibytes, we pair at the drop of a hat. We use it when we need help, want a dynamic code review, or maybe want to see what someone else is working on. We use ScreenHero (our favorite screen-sharing tool) and pair. In fact, we’ve found that pairing is such a great way to acquire and transfer skills that we, “turned up the good” (as Woody Zuil says) and adopted Mob Programming. Mob programming is where your whole team works on the same task sharing one computer.

Ask others what they’re reading or have learned lately:

We at Corgibytes are fans of GetPocket.com (a fantastic tool for bookmarking content) and we have a Slack channel called reading-list to post recommended articles or videos. We use a custom GetPocket plugin that allows us to put the hashtag #corgibytes in Pocket and an entry is automatically added to the reading-list Slack channel. What I do, when a person or newsletter recommends an article or blog post, is immediately bookmark it in Pocket. If I like that post, I add it to my Pocket recommended list.

What Do You Do if You Are the Best?

There are times when you may, unfortunately, be the best coder on your project. Maybe you have a well-paying job at a great company and you are either the only programmer or the only programmer that continually works hard to stay abreast of your field. What do you do? Here are some suggestions:

Coerce quality developers to your team

If you can’t expand your team, start a Slack channel with core group or quality developers where you can collaborate with each other daily.

Give serious consideration to joining another team

If you are not growing or improving, you are limiting your future employability. Consider joining another team — even if you make less. In the long run, it will benefit you.

Join open-source projects or at least read open-source code.

Scott, our brilliant tech lead, is constantly digging into open-source projects. I’ve paired with him on multiple occasions where he delves deep into the code of a Ruby gem. Even though Scott is tech lead, he still regularly reads code from industry greats.

Discover technologies other team members are great at and learn that technology.

There’s always someone that knows a technology you don’t know or don’t know well. Seek that person out and bleed knowledge from them.

Mentor

You may be surprised how much you’ll learn from junior developers. And, as they say: “To teach is to learn twice.”

Cross-boundaries

Go from Java to Ruby, or Windows to Linux, or MySQL to PostgreSQL. You’ll always end up being a better overall developer after crossing boundaries. In the late ‘90s, I took a three-year sabbatical from coding to be a full-time technical editor. Andrea (our CEO) would say I moved from C++ to English. In that job, I was forced to learn all the latest technologies and I worked with the top technical writers in the AS/400 industry.

The Corgibytes Dojo

The Corgibytes dojo has quite the cadre of adept coding practitioners. We don’t have one dojo champion. What we have is champions on a variety of skill sets. All of the developers are expert in many languages and love to learn new ones. Corgibytes has fleshed out their staff in a way that we have a very broad set of diverse skills. Everyone brings skills to the table that force others to up their game from code to content to client facing and project management. Everyone is open and honest about their abilities and limitations, which means no one judges the person who asks for help. You always know that, when you find yourself fighting with some tough code, there’s a Corgi who has your back. That’s how I know I’m working at the right place and with the right people.