5 Things More Important Than Intelligence in Software
When you talk about software engineering, the focus always converges on one thing: technical prowess. There’s a somewhat pervasive tendency to over-value intelligence, and it permeates into every part of the industry.
For example, the interview process is misguided as hell in software.
There’s typically a disconnect between the interview problems and the actual job’s problems. And there’s no good reason for it — seems like current software engineers like to get off on feeling smarter than the candidates they grill.
I was frustrated and humiliated when I walked into an interview for a Developer Advocate job and was asked to write a board game AI.
I kid you not; the DA role’s responsibilities included making videos, writing blog posts, attending conferences, and testing out new APIs.
But since I couldn’t implement a modified minimax algorithm in 10 minutes, f*ck me I guess. Next!
I digress: even after you’ve overcome the software interview and gotten the job, a lot of the focus in companies tends to fall on meaningless metrics:
- Sprint velocity
- Story points
- # of bugs fixed
- # of lines of code written (← this is the worst. I’ve got a horror story here)
- # of tickets shipped
- # of goats sacrificed
The industry is growing rapidly and so there’s a mad scramble to hire the “best” engineers. Problem is, most people believe “best” means “smartest”…conveniently disregarding everything else important surrounding the software engineering process.
As your team grows, the key to success is how you onboard new engineers and disseminate key information to stakeholders.
How quickly can your security team answer questions for your sales people? How easily can a support engineer get info from product engineers? How quickly can developers dive in and patch critical problems?
The transferring and sharing of knowledge between parties is so key that it’s frankly disappointing how little people focus on it.
Before you realize it, you will have people at your company who know everything yet somehow nothing gets done.
“Never mind the fact you don’t communicate well and would be a terrible team member. I’m really impressed by the efficiency of your indexing algorithm!”
—Every Bad Interviewer Ever
I’ve said it before, and I’ll say it again as many times as needed: the hardest part about coding is not actually writing the code. It’s everything around it, including the planning and collaboration.
There are three ways you get unmaintainable code:
- Disparate ideas and visions for architecture / design
- Bad engineers who don’t understand best practices
- Good engineers who over-engineer everything
The first is when the team doesn’t have a lead architect or a unified view of the overall system. What does this lead to?
People writing software the way they think is best. Then your code base becomes a giant hodge-podge of lukewarm bullsh*t containing everyone’s convictions and pride.
Sorry, but just like in any team sport, software engineering doesn’t need heroes. What it does need is a cohesive vision and everyone pushing in the same direction. When you’re all on the same page, it makes collaborating easier and your applications come out cleaner.
Bad engineers don’t follow or understand best practices, making mistakes and inefficient usage of variables, bad naming conventions, terrible logging, etc. This one is self-explanatory.
The last one is not so obvious to many but is a key point in the context of this article: there are great, intelligent engineers who write code that’s extremely optimized but practically impossible to understand.
Unless you’re working on cutting edge search tools or the latest decision-making AI, the focus shouldn’t be on hyper-optimized code — it should be on writing code that your team members understand.
Don’t condense 6 lines of readable for-loop into one giant
map().stream().f*ckEverything() unless you really, really need those marginal performance advantages.
Also, writing code only you understand won’t secure your job anymore. This is because more and more companies are starting to value…
Different companies value different traits and skills. But no matter what company you end up working for, you’ll almost certainly have to work in a team. Subsequently, most people will look for things like:
- Agreeableness — Generally speaking, are you pleasant to be around? It doesn’t matter how smart you are if nobody wants to work with you. This means not whispering about people behind their backs, not being a dick, and just generally not being a sleaze. It also means not being a complete grump that keeps to themselves all the time and never has anything good to say about anything.
- Reliability — Can you be trusted? Can you finish what needs to be done? People want someone they can lean on. You do too, even if you don’t admit it. Be the teammate you’d want to have.
- Drive — It’s hard to work with someone who doesn’t put in at least as much effort as you. Imagine sitting there cranking out work and then looking over to see your teammate packing up at 2pm. That’s like a pallbearer just giving up halfway and ditching the funeral.
If you have at least the above 3 traits, then there’s a much higher chance you’ll be perceived as a good fit with most teams at most companies you apply to.
I know that software engineering isn’t a martial art (or maybe it is), but discipline is hugely important.
There will oftentimes be moments where you have to buckle down and burn the midnight oil. You’ll be frustrated, you’ll be tired, and you’ll probably find yourself lacking in patience and focus.
It is these key moments that test your limits as a developer. If you slip up and start disregarding best practices or procedure, you’ll end up regretting it later.
I can’t tell you how many times I’ve come in the next day after a tiring evening just to scrap nonsensical code I’d written. I also can’t tell you how many times I’ve beaten myself up because me-from-yesterday made poor choices like procrastinating key tasks.
Even during times of non-duress, if you start getting lazy and allowing tech debt to accumulate, you’ll just cause future headaches for everyone including yourself. Doesn’t matter how smart you are.
As you all well know, the software industry is ever-evolving.
Practices are always changing. New tools or concepts are always emerging and replacing old ones. Subsequently, the ability for an engineer to learn, absorb, and adapt will make or break their innovation.
I’ve worked at companies with stubborn, experienced engineers who absolutely refuse to concede that they’re wrong about anything.
They refuse to adopt cloud because “it’s insecure.” They refuse to use Infrastructure as Code because “it’s too complicated.” They refuse to containerize their applications because “we’ve already spent so much money on VMWare.”
Or, in my personal experience, they don’t participate in morning standup with everyone because, “I already know what I’m doing and you’re all plebs.”
These people are the death of innovation and growth.
By and large, this is the most important trait. No matter how smart you are, you’re not perfect. There’s probably someone at your company who’s smarter and more experienced than you.
Hell, even if you’re the smartest ever principal engineer, it’s possible you’re not up-to-date on new practices or tools. You are not above growing and learning.
Smartness is over-hyped. You could know all the algorithms in the world or you could solve every hard problem on HackerRank with optimal solutions.
But if you don’t communicate well and document anything, you don’t write maintainable code, you’re not a good team member, you have no discipline, and you’re too prideful to learn and adapt, you’re just not a great engineer to have at any company.
Whether you’re an interviewer or interviewee, manager or individual contributor, there are so many more important things to assess and gauge in yourself and others besides intelligence.
I hope desperately that the industry starts to do a better job of fixing this culture and the various aspects affected by it (e.g., interviews).