3 Lessons from the Smartest Developers I’ve Worked With

I have a confession.

I’ve copy pasted throughout my entire coding career.

Honestly, it’s how I’ve survived over the years as a developer.

On every team where I worked, I took note of what the smarter developers were doing.

I copied from the right people at some amazing companies and worked with developers who I truly think might be genius.

• One started a multi-million dollar business.
• Another wrote a popular library for unit testing that you’ve probably heard of.
• The last one called me out on my b.s.

I stole a little piece of each of these developers to accelerate my own career.

I’ve been very lucky.

I live in the epicenter of the tech universe in the San Francisco Bay Area. Every nerdy developer with a dollar and a dream ends up here somehow.

You don’t have to get lucky though.

I want to share the lessons I learned from each of these characters that saved me from mediocrity and might help you as well.

You won’t recognize what’s bad until you’ve experienced what’s good.

Before I met these super star developers, I was aiming too low in my career. After learning to code at 30, I was just happy someone hired me. My main goal was not to get fired.

I aimed to be average.

And I still fell short.

Here are phrases you’ll often hear from sub-par developers.

“It works on my machine”

“I don’t know how it works, it just does. Don’t touch it.”

“I just write the code, I don’t know how the business works”

“Looks good to me!”

Plot twist: I’ve said all these things.

That last line almost got me fired but we’ll get to that soon.

You don’t need to job hop 6 times in 10 years like I did to finally become a slightly-above-average coder.

Here are 3 lessons I learned from the smartest nerds I’ve met.

The salad eater

Let’s call him Don.

First off, this guy was a genius.

I could tell because when we went out to eat on the first day of work with the CEO and CTO — this guy used his hands to eat a salad.

Next, he asked if he could go home early because he was tired.

He slept on the couch in the office in the middle of the day.

Only a genius can get away with shit like that and not get fired on the spot.

He switched careers at 40 from medicine to software and was in his 50’s when I met him.

I was entering my 3rd year as a developer and thought of myself as mid-level at this point.

Wrong.

Don pair-programmed with me for the first 2 weeks on the job and I quickly learned just how junior I was.

Don wrote tests for the features we created using the library he authored for the framework we were using.

I had never written a test in my life.

Don had keyboard shortcuts to fly around his terminal and code editor.

I didn’t have the “time” for that.

I just wanted things to “work.”

Don didn’t accept my “make it wok by all means necessary” style of work. He refused to work with me until I learned keyboard shortcuts for VS code to make pairing more enjoyable.

If I wrote a feature without a test, he would reject it.

When I asked for help, he wouldn’t give me the answer but tell me where I could probably find the underlying issue.

We only worked together for 9 months but I can’t think of a more impactful stint in my career. I learned the art of testing, the importance of learning your tools and how to balance getting things done with getting them done correctly.

Last I heard, he co-founded a multi-million dollar software company. I bet he’s still eating salad with his hands.

The reviewer from hell… or maybe from heaven

I used to be nervous when this guy reviewed my code.

There were always a dozen or more comments.

Sometimes he would suggest a totally different approach. It was always clever.

“Why didn’t I think of that?”

I learned he was meticulous with everyone’s code .

I felt proud when I only received a few nit picks on a review.

Now me on the other hand — I was rubber stamping code reviews like a clerk in a mail office.

“Looks good to me!”

Looks. Good. To. Me.

This team was full of senior level developers. I trusted they had reviewed their own work. The review was sort of a formality right?

Right?

One afternoon, I got a cryptic Slack message from “Parker.”

“Hey dude — do you have a minute to chat?”

My heart rate elevated.

He video called me and asked me why I had accepted a recent code review from one of the seniors on the team. He went over the obvious errors one by one.

“How did you not catch this?”

This was a painful conversation and I was embarrassed.

He was right.

I failed to do the bare minimum and we nearly released code that could’ve crashed the app and pissed off customers.

I apologized and then I vowed to become the 2nd best code reviewer on the team.

“Parker, how do you do code reviews?”

He showed me his process:

1. Run the code locally and test the functionality before even looking at the code. If it doesn’t work then no point in reviewing.
2. Look over the new code line by line to understand what is being introduced.
3. Ask clarifying questions to make sure you understand anything that isn’t obvious.
4. Meet up to go over large reviews and have the developer explain the code.
5. Always do reviews in the morning before starting on your own work so you’re not context switching.

Wow.

That was a hell of a lot more involved than what I was doing.

I decided I would stick to it and avoid another blow up.

In my year end review, several team mates complimented me on my code reviews and my manager thanked me for being so thorough.

I felt like a good little boy.

The buzzword salad eater

I met “James” recently, at my last company and we worked together managing a small team of developers.

As the engineering manager, I was in charge of creating our technical roadmap for the quarter.

I never had this kind of power.

Finally, we could use all the technology I had been dying to work with like NextJS and TypeScript. We could refactor that library I wrote years ago. I bet we could even figure out a way to incorporate Kubernetes.

It was going to be great.

I showed James.

“What’s the point of doing all these things?” he asked.

I spit out a tech buzzword salad (I was really adopting my new manager persona):

“Well, uhh, static site generation can decrease load time, increase our SEO value and our http client is using an outdated version of NodeJS and could use a CLI tool to improve DX.”

The cringe was too much for him.

“Honestly, I don’t know what you’re talking about. How will any of this help the business goals for the quarter?”

…

Honestly, hadn’t thought about it.

“Brian”, he said, “We are in the business of making money for the organization. It’s fine if these things are needed or if they support some business effort. Otherwise it’s just fancy fluff.”

I went back to the drawing board and chatted with our product team to learn what the business actually needed for the next quarter.

It did not include decreasing load time on the site by 200 milliseconds.

It did include some very interesting challenges that I was happy to tackle.

I had good intention, just wrong direction.

Who will you be?

Every good story needs a hero.

These 3 people were the heroes I needed at different points in my career. I adopted a lot of their habits and applied their processes and mental models to my routine. It’s worked well for me overall.

I still use a fork for my salad though.

You know what else every good story needs?

A villain.

Unfortunately I was probably the villain in some of these developers’ minds.

I was a burden. I produced sloppy code. I took too long to get that feature finished.

That’s ok too, I think.

They say that if you’re the smartest person in the room, then you’re in the wrong room.

Easier said than done.

If there’s one takeaway from these bandicoots, besides that you should write tests, care about business context and review code like you give a damn — it’s this:

Chase un-comfortability.

Being around people who know more than you and studying them is the most efficient path towards being slightly above average in any arena.

Hope that’s helpful.