5 Things I Have Learned in 4 Years of Software Engineering
Three years ago in May 2016, I walked across the stage to receive my Bachelor’s. You can imagine how happy I was — years of lectures and homework finally done.
A new environment, an adult job (with salary!), and no more homework… I was ready. What I did not realize is that the following three years would be filled with more learning and pain than I ever had in college.
My professional life started off innocuously enough. I was happy just to have a job. I finally started applying a few concepts I’d learned from textbooks to real-life scenarios and learned a variety of tools and languages:
We used CloudFormation and Ansible (Infrastructure as Code!). We experimented with ELK Stack and Splunk. We picked up Vue.js. We learned about microservices architectures and how to index files with Apache Lucene. We did cloud deployments with AWS, CI/CD w/ CircleCI, and much more.
All of these different tools, languages, and constant learning… they’re great. But ultimately they’re par for the course. Everything listed above is either a standard or an alternative to a standard — learning them or being able to use them is nothing special.
But somewhere along the way, I had started believing that we (and I) were totally incredible, “progressive”, and “advanced” software engineers. And the result was arrogance and tunnel vision.
When I finally switched to a new job, I saw just how much there still was to learn. This leads me to lesson 1:
This advice sounds elementary, but I never realized it. Many people settle and don’t progress beyond their day-to-day. It’s easy to fall prey to the availability heuristic (e.g., “what you see is all there is”).
At my first job, I took no notice of anything outside the walls of our office. I barely followed the occasional Hacker News article, I paid no attention to industry trends, and I attended zero conferences. The idea of “networking” gave me anxiety.
The result? It meant my idea of “best” or even “good” was extremely misguided.
My workplace was an echo chamber. After all, how can you learn about something if you don’t even know it exists? The past few months I’ve been learning tools and processes I’d never even heard of.
I’m now blessed with an extremely great opportunity to attend conferences, learn new tools, and build relationships.
I’ve met many people — intelligent, ambitious, and with vast knowledge and skill. I’ve discovered an equal number of new applications and tools, and even industries within software, all with their own complex nuances and niches.
And I am still reeling at just how little I actually knew. If there’s anything I’d like you to get from this lesson, it’s to:
- Go to conferences and network. Ask your company to pay or set a budget for conferences, along with continuous education. Get to know other engineers — they’ll teach you plenty.
- If your company does not pay for your continued education, search for another employer. Stagnation is certain death for your career, especially in rapidly-changing tech.
Rude awakening aside, I have the pleasure of working with extremely competent leaders, engineers, and salespeople. There’s something liberating about working together with strong individuals.
We’re thoughtful in our communications, efficient in execution, and we document processes and knowledge religiously.
You’re driven to achieve more. You’re empowered to make decisions. And most of all, team members give you the space you need, professionally and personally, to do your best work.
This is more than most could ask for in a job. All of this brings me to the realization of another lesson:
It’s planning. It’s management. It’s maintainability of the code.
It’s the ability to collaborate with a team and achieve a unified vision. And it’s the ability of each team member to carry their weight in the right direction.
Like a three-prong stool, the team falls over when any leg is compromised. Good software needs strong engineers. But strong engineers mean nothing under disorganized leadership and poor communication.
So the key things to take away from this lesson are not just to improve technical skills, but also the following:
- Improve Communication Skills: Short, concise, and clear messages. Answer all questions. Bullets and listicles are king.
- Improve Management: Clear deliverables, clear timelines, and clear responsibilities, along with strong vision, strong organization, strong metrics, and strong processes… there’s a lot. This is why directors and executives are paid lots of money.
- Improve Planning and Design: All relevant team members should have an overview of the solution and how their part fits in. Good documentation answers lots of questions and prevents lots of problems.
Along the same lines, this led to another realization that changed my entire outlook on learning and hiring:
Sure — some people are just better at logical computation than others. But you don’t need to be a computational genius to be a good software engineer.
What you can’t easily learn are intrinsic traits. You can’t reasonably motivate unmotivated people. You can’t instill integrity in people who lack it, or compassion and understanding in a hateful person.
You likely won’t humble an arrogant prick, and you definitely won’t enforce your values or vision on people who don’t believe them.
Too many software companies focus on hiring “rockstar” developers over well-rounded team players. These rockstars are, without a doubt, highly intelligent — but the world doesn’t run on only intelligence.
So the key takeaways are:
- Don’t just focus on technical qualifications — likability is just as important. Demonstrate an eagerness to learn, an openness to taking feedback, and a willingness to work with people. Be the team member you would want to work with.
- If you’re on the hiring side, don’t just focus on “rockstars”. Make sure they’re coachable, pleasant people with strong potential. The wrong person can easily tear your teams apart, fast or slow.
Especially in the last half year, I’ve been focusing on self-improvement. For all of my college years and the 2.5 after, I had established a constant pattern of “feeling motivated, doing something, and then fizzling out and giving up.”
Usually, failure is encouraged because it’s the fastest track to learning — but it largely depends on why you failed.
Making genuine mistakes is helpful and educational, but failing simply because you “didn’t try hard enough” is… useless. It’s a waste of time and money, and it’s repeated damage to your confidence.
So I want to help you avoid this by telling you now:
Motivation is temporary. It’s short-lived.
None of us drives a car that “sometimes” turns on (ideally). Nobody would visit a surgeon who’s “periodically successful.” So why, then, would you stake your future on something as fleeting as your motivation?
I grew as a software engineer not because I was always passionate about it — in fact, I sometimes hated it, especially when it was late and I was debugging code line by line in a pool of sweat, tears, and potato chips.
No, I grew because I opened my laptop for 8+ hours a day, 5+ days a week, 45+ weeks a year, and for multiple years, doing my due diligence and writing code.
So whether it’s with software, or losing weight, or anything you want to pursue in your life, ditch your feelings. If you want to make progress, just keep doing it, regardless of how motivated you feel.
Finally, the last major thing I’ve learned:
#5 — We’re all traveling on the same stretch of road, so it’s ultimately beneficial to help each other.
This sounds naive and sentimental, but it’s a true statement.
You can antagonize and squash everyone around you on the road to greatness, but there will be nothing left for you at the end except an empty throne room.
None of us knows for sure where our lives or careers will take us twenty years from now, or five, or even one. Companies rise and collapse — but relationships with people persist.
Your competitor may one day be a coworker, and a stranger will one day be your best friend. So remember: people are not enemies; they’re competitors.
Enemies stress and harm each other; competitors excite and motivate each other. Enemies destroy each other and all innocent bystanders; competitors drive each other to create and innovate, thereby benefitting bystanders.
This is true not just for software engineering — reputable people swap companies fairly often in pursuit of the next career achievement. And the consistent trait I’ve seen in the most successful people is that they maintain amicable relationships with almost all they meet.
So go out there, do great things, and make a lot of friends.
The lessons I’ve learned are things people struggle with their entire lives. It’s my hope these lessons I’ve taken over three years to learn can be absorbed and acted upon by you in a shorter amount of time. In short:
- Travel, meet new people, and learn new things.
- There’s more to software engineering than just writing the software.
- Focus on more than just technical knowledge when evaluating yourself and others.
- Motivation doesn’t always deliver results — consistency does.
- Making friends and helping them is better than making enemies and destroying them.
Whoever you are or whatever industry you work in, I wish you the best moving forward. Connect with us and let’s talk!