How to be a Decent Developer
Based on my experiences as an engineer at Google, I’ve aggregated a few tips for becoming a good software developer.
I am not a prodigy or a genius, and I despise the terms rockstar, code ninja, and hackstar.
Becoming a decent developer is not some genetic gift.
It’s certain habits that allow you to excel in the tech workplace. Like all behaviors, they can be learned. If someone like me can discover them, you can too.
‘Good’ is always highly subjective, and I know there are people who can code circles around me. That being said, I went from someone who couldn’t code at all at the beginning of college, to year after year of getting positive feedback on the job.
Maybe a lot of it was luck, but maybe some of it wasn’t.
So that being said, here they are:
- Put in your Hours.
- Be an expert in the Codebase.
- Manage your Manager.
- Don’t ask for Help.
- Become a Master Debugger.
- Manage Expectations
1) Put in your hours.
Working hard is the most important advice I can offer.
It’s simple. It’s cliché. But it’s still the best thing you can do.
You can overcome any disadvantage by working hard.
Let’s do some math. An average programmer shows up for 40 hours per week.
Yes there are developer sweat shops out there, but I don’t know anyone who works at one.
Almost everyone wastes at least half of those 40 hours, sometimes more.
People take long lunches and spend their days browsing the internet. They handle house chores when they should be working, and they spend huge chunks of time in meetings.
What about when a co-worker interrupts you? That act alone carries a huge cost:
It takes an average of 23 minutes and 15 seconds to get back to the task.
If your workplace is anything like mine, interruptions are constant. People talking about random crap. The football game from Sunday. Office gossip.
After accounting for all workplace distractions, the average engineer is left with 20 hours of real work per week.
And many people wind up with much less time.
The 10,000 hour rule has been proven by study after study.
It takes so much longer to reach 10,000 hours at 20 per week.
In medicine, students aren’t allowed to work more than 80 hours a week. And I know doctors who complain about those students not learning anything in such little time.
80 hours per week! This limit is probably good for patient welfare.
But if a doctor can’t learn his craft in 80 hours, where does that leave you at 20?
Imagine if you were able to work 50 hours per week. You’d be 2.5X better than your coworkers.
I don’t buy the “good hours” argument. The gist being that the guy working 20 hours a week is putting in way more “good hours” than the guy working 50.
It’s probably true, but 250% is too massive to overcome.
Yes, a correlation exists between working less and success at creative tasks. But whenever someone uses this argument, I sense that person feeling threatened by the person who works more.
Plus, the Googles and the Microsofts of the world were built by founders sleeping under their desks.
I’m not telling you to become a workaholic. You don’t have to. Imagine working the same but improving your efficiency by 50%. That’s 10 more hours per week, or 500 hours a year.
12.5 more weeks per year! What could you build in 12 weeks!?
So put headphones on and people won’t bug you. Discipline yourself to not check Facebook so often. Install website blockers on your work computer.
Ignore your coworkers and put in your hours.
Do what others are unwilling to do.
2) Know the code base.
The most valuable engineer in the room is the one who best knows the company’s codebase.
It takes 3-6 months for a new engineer to become productive. Learning coding practices, architecture, developer tools, and deployment practices is time consuming.
If a company has proprietary technologies, you can double that time. During orientation at Google, they say it takes between 6 and 18 months for new engineers to ramp up.
So the most valuable workers are usually the ones who have been around the longest. You’re more productive if you know exactly how the code works, where to add a feature, how it fits into the test harness, and how you deploy that code when you’re done.
Engineers who were around for key product or technical decisions are even more valuable. Watch their desks and observe how many people stop to ask about history.
In fact, length of tenure can be a great mask for competence.
When you start a new job, your goal is to get up to speed as quickly as possible. The sooner you know everything, the more valuable you’ll be.
Get outside your area of expertise.
Notice how coworkers develop expertise in limited areas of the code base.
Most engineers are known for 1 or 2 areas of core competency, usually because those areas are where they began working on features or bugs.
They never evolve.
It does not feel good to learn new things. It takes effort, and the willingness to feel like a moron for awhile.
Most people don’t like feeling like morons. So they don’t, and they stay pigeon holed in one area.
Additionally, most engineers can only expand their expertise after business hours. They’re too busy during the day.
Feeling like a moron + working late without getting paid = screw that.
All of this means you’ll have a huge advantage by showing competence in multiple areas. Better yet, be the person who knows how the entire system fits together. You’ll be the only one.
An obvious counter-argument is that generalists are shallow. They don’t have depth in any one area. You’ll shut those people up when you add complex features in all the areas you’re a part of.
How do you gain enough competency in multiple areas?
Again, put in your hours. If you work 2-2.5X more than your peers, it’s not inconceivable that you’ll be competent in 2-3 times as many areas as them.
Work on areas of the System nobody else knows.
Every system has areas that nobody knows. Usually the learning curve in these areas is steep.
It’s incredibly easy to stand out if you’re the one person who shows competence in that area.
I worked on one team that was full of web engineers and one PhD in Machine Learning. Part of the website was a stats module using elementary predictive analysis.
Unfortunately, Mr. PhD was the only one who knew how the stats module worked. To everyone else it was a black box.
I found the area interesting, so I read up on the subject in my free time. I added a couple of features in the process.
A few months later, Mr. PhD decided to leave the company.
Guess who became the leader of that part of the codebase?
3) Manage your Manager
In Managing Oneself, Peter Drucker advises:
It is incumbent on the people who work with them to observe them, to find out how they work, and to adapt themselves to what makes their bosses most effective. This, in fact, is the secret of “managing” the boss.
Figure out how your boss judges performance. What annoys and excites him or her?
At Google, I had one boss who loved startups. He talked about them all the time, constantly read TechCrunch, and eventually left to join one.
I always talked startups with him. Every little idea or side project I had, I brought it to him for advice and feedback. Normally this would be a horrible idea at any company. You run the risk of the company claiming ownership of what you’re doing on your own time, with your own equipment. But it was a huge source of rapport between us.
I had another boss who was irritated by late people. He never said anything, but you could see the negative expression cross his face when one of my fellow developers strolled in at 11 AM.
At the time, I was on a later schedule, and I struggled to get up early. But I was always 2nd or 3rd in the office when working for this guy. He eventually thanked me for “being one of the early ones.” Fortunately, my coworkers were always later.
Learn to align yourself with what makes your boss successful
Look at your boss and try to evaluate how he’s judged by his boss.
What makes him successful? Can you do something that will help with that success?
4) Don’t ask for Help
Controversial. But when debugging an issue, 90-95% of the time you should sit there until you figure it out.
Don’t ask your coworkers for help. Even if it eats up half your day. Even if it takes 2 days.
I’ve noticed senior engineers rarely, if ever ask for help. And junior engineers ask for it constantly.
To become a decent developer, you need to act like a senior person.
Let’s break down the obvious objection to this:
- It’s a better use of my time to ask someone who will know the answer right away, instead of sitting here all day trying to figure it out.
It’s never a “waste” of time for you to figure things out for yourself.
- Learn the codebase and tools better than the majority of your team. See Point #2.
- Become more resilient when debugging issues.
- Increase your self confidence about being able to do things yourself.
Your co-workers act as a crutch. It requires dramatically less effort to ask your cube-mate than it does to think about the problem.
But then you interrupt her, and interruptions are costly. And you don’t gain anything long term.
So develop a thick skull. Get comfortable feeling confused for long periods of time.
Make it a habit not to ask for help. Start small if you have to. Wait an extra 10 minutes before asking in the beginning.
The long-term benefits are worth it, both in how you look to your team, and by raising your self esteem.
5) Become a Master Debugger
If you follow rule #4, your debugging skills will improve automatically.
Our goal is to have people ask:
How in the world did you figure that out?
And then you can smile and act like it was no big deal. As the master debugger you eat nasty bugs for breakfast.
- 40% experience
- 10% intelligence
- 50% stubbornness, perseverance, and believing there is a solution.
This is why developing resilience is so important. It’s an essential trait when debugging the worst issues.
Equally important is believing that you will find a solution.
Most people give up because they believe the issue is “too hard,” or they’re not smart enough, or any other number of erroneous excuses.
Take the case of the 4 minute mile in running. The 4 minute mark was broken by Roger Bannister on 6 May 1954, after he and many others had been pursuing the goal for years.
Within only 2 months, 2 more runners broke the record, and many more followed.
The belief in a solution was part of the solution itself. Most runners thought breaking 4 minutes was impossible, despite the fact that many already had the capability to run that fast.
Once the mental barrier was gone, those runners blasted through 4 minutes.
The same psychology has played out between researchers in math and physics, and it also applies to you when debugging.
So don’t let the stubbornness of an issue get to you!
6) Manage Expectations
The easiest way to get ahead: When your team thinks it’s impossible to do something, and you do it anyway.
Listen for statements like the following:
Well that would be awesome, but it would be extremely difficult.
I’m not sure we can do that, I’m afraid it would be too much work.
or my personal favorite
That would be so cool, but the performance would be unacceptable.
Most of the time your team members are right. But once in awhile, an issue will come along that’s perfect for you.
You might have to work late a couple of days to get something working, but the result will be shock and awe. Your team won’t believe you were able to do what you did.
Repeat this 3 or 4 times, and your reputation will be set for the remainder of your stay at the company.
Thanks for reading! I would love to hear your thoughts and comments below.
Photo Credit: Lloyd Dewolf