DR

7 Lessons Learned as a Software Engineer

1. Focus

“Deep work is so important that we might consider it…the superpower of the 21st century.” - Cal Newport

The best way to be a productive software engineer is to focus. It sounds simple, but in practice, it is quite difficult.

Some habits that I have found helpful to prioritize focus and get more done:

  • Pomodoro sessions
  • Time blocking
  • Meditation
    • Force multiplier on your attention and productivity
    • If meditation seems like a waste of time, consider that if meditating makes you just 10% more efficient, then if you work a 10 hour workday, you are really getting 11 hours of work done.
  • Eliminating distractions
    • Work with my phone in another room
    • Use software that blocks distracting mobile apps
    • Not checking email and IM’s during focus blocks
  • Working on one thing at a time
    • Clearly define the one task that you intend to complete. Then, ensure that your attention doesn’t drift from it.
    • Eliminate task switching
  • Tracking time spent focusing
    • I am consistently surprised how few hours of deep focus are needed to complete big tasks.
  • Focusing during your biological peak hours
    • I am most productive about an hour after waking up, until lunch time. Therefore, as much as possible, I focus on my most cognitively demanding tasks in the morning and (when possible) do meetings, admin tasks, easier coding tasks etc. in the afternoon.

Optimizing my workday for focused work pays serious dividends. Cal Newport’s equation from “Deep Work” rings true:

Work Accomplished = Time Spent X Intensity of Focus

2. Simplicity

“Simplicity is the ultimate sophistication.” -Leonardo da Vinci

When I began software engineering, everything seemed so complicated. Therefore, I assumed that coding is meant to be complicated.

The more I code, the more I realize that the best code is simple. Well-written code is clear. It is obvious what the engineer was thinking. It is written to get the job done, but importantly, it is written to be easily understood.

Simple code makes it easy to add to the codebase. Your fellow engineers will greatly appreciate it. Plus, your solutions will tend to be better.

It is tempting to just figure out a solution that works, then push it to prod. Taking a bit more time and ensuring that your solution is as simple as possible will pay dividends in the long run.

3. Fixed time vs. fixed amount of work

“Is this a fixed amount of work or a fixed amount of time?” -Nathan Barry

A common mental model for career growth as a software engineer is to relate years of experience to level. For instance, one might consider engineering levels to be something like the following:

  • Junior Engineer: <3 years
  • Mid-Level Engineer: 3-8 years
  • Senior Engineer: 8-15 years
  • Staff Engineer: 15 years+

First of all, titles aren't everything. A senior engineer at one company can be staff or mid-level at a different company.

After listening to Nathan Barry (founder of ConvertKit) on the Danny Miranda podcast, one question that stuck in my mind was: “Is this a fixed amount of work or a fixed amount of time?”

Many achievements in life appear to be “fixed amount of time.” Graduating high school, for instance, seems to be an achievement that takes a fixed amount of time: everyone graduates when they’re ~18. In Nathan’s case, he was homeschooled. He asked his mom “is high school a fixed amount of time or a fixed amount of work?” And she said “it’s a fixed amount of work.”

Completing high school simply means completing a curriculum. There is no reason it cannot be done in far less time, given the right approach.

Software engineering levels are the same. While many people and companies believe in the years of experience model, I choose to believe in the skills developed model.

If one engineer has 10 years of experience but progressed slowly and touched on a limited range of topics, they should be less senior than someone who developed greater skills over a 1 year period.

Figure out what the fixed amount of work necessary to get where you need to be. Then realize that there is no speed limit. You can cut years off the duration of leveling up with hard work and the right approach.

4. Master the fundamentals

I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.” -Bruce Lee

Learning new topics is great. I love learning about new front end frameworks and libraries. I love learning about new AI tools.

Will that information really last?

Spending time learning the things that will not change has led to a ton of growth in my skills as an engineer. It has allowed me to see behind the abstractions of the tools that I use daily. And while the software industry seems poised for massive change, I believe that a strategy for future-proofing oneself should favor investment in areas that do NOT change.

5. Abstractions

“It’s turtles all the way down.” -Richard Feynman

Abstractions are prevalent in software. Almost anything that you’re doing relies on a number of processes that are abstracted away from you. When I first began learning JavaScript I was blissfully unaware of all the processes going on underneath the hood.

By the way, that’s ok! It’s not necessary to understand absolutely everything related to the task at hand.

However, once I knew just enough to recognize just how much I didn’t know, I felt overwhelmed. I was terrified of the mountain of knowledge out there that I didn’t know.

The best approach I’ve found takes into account both short term and long term. Short term, I try to learn just enough to complete the task I’m currently facing. Long term, I figure out all of the topics that I would like to know, then I stack rank them, I create a simple curriculum to learn them, and I learn each concept one-by-one. I don’t allow myself to become overwhelmed by the sea of knowledge out there, but I ensure that I chip away at the most useful chunks of wisdom over time.

6. Soft skills matter

“Hard skills get you in, soft skills get you far.” -Sahil Lavingia

Obviously, to be a great software engineer, you need to be excellent at coding. Your technical skills need to be on-point.

However, technical skills are not enough. Teamwork, communication, time management, leadership, public speaking, and rapid learning are all skills that are greatly valued as a software engineer.

Definitely strive to grow technically, but also invest in developing your soft skills. The good news is, these are not fixed abilities. Like any skills, soft skills are malleable, and it is well worth taking the time to improve them.

7. Learn via doing and teaching

“If somebody offers you an amazing opportunity but you are not sure you can do it, say yes – then learn how to do it later!” -Richard Branson

I strive to be a learning machine. When it comes to learning, there are one thousand ways to skin a cat. I have experimented with reading, flashcards, watching videos, and many more techniques.

I have found that the best ways to learn are to do and to teach. Whenever I’m looking to learn something new, I create a project that requires that I learn it. I used to read about the topic for hours and hours before finally diving in to use the information. I find that knowledge sticks when I start doing.

After I’ve done a project, teaching the material is another incredible way to sharpen the saw. When I seek to teach material, I suddenly realize that I have a bunch of gaps in my knowledge that I didn’t know were there. I thought I had a complete understanding of the material, but sure enough, there are gaps.

One of my favorite aspects of my current job is creating educational videos about the software that we develop. I lead development on an Angular and Angular Material based component library. For each component that we create, release that we push out, or concept that would benefit the development community, I create a video explaining the knowledge that an developer consuming the project should know. I am regularly told that people love the videos, but selfishly, I benefit from creating them just as much. The process of breaking down and explaining difficult concepts magically solidifies the underlying knowledge.