Here‘s What I‘ve Learned 9 Months into My Software Engineering Career

Alt Text

As I approach my 9 month anniversary as a full-time software engineer, I‘ve been reflecting on the multitude of lessons I‘ve learned on the job. The transition from coding bootcamp graduate to professional developer has been thrilling, humbling, and challenging in equal measure.

In this post, I want to share some of the most impactful realizations and pieces of advice I wish I could go back and tell my bright-eyed, bushy-tailed self on day one. Whether you‘re a new grad, coding bootcamp alum, or self-taught developer starting your first engineering job, I hope these insights will help you navigate some of the common pitfalls and expedite your growth. Let‘s dive in!

Imposter Syndrome is Real (And Normal)

One of the most pervasive challenges I‘ve faced, especially in my first few months on the job, is dealing with imposter syndrome. That nagging feeling that you‘re not good enough, that you somehow slipped through the cracks of the interview process, and that at any moment you‘ll be "found out" as a fraud.

If this sounds painfully familiar, you‘re not alone. A 2020 study by Blind found that 58% of tech professionals experience imposter syndrome. Anecdotally, I‘ve yet to meet an engineer who hasn‘t grappled with self-doubt at some point in their career.

Knowing how common it is doesn‘t make it any easier to deal with in the moment. When I‘m deep in the throes of imposter syndrome, these tactics help me reframe my thinking:

  • Remember that you were hired for a reason. The experienced engineers who interviewed you saw potential and believed in your ability to learn and contribute. Trust their judgment.
  • Reframe challenges as opportunities for growth. When you‘re struggling with a difficult bug or complex system design, try to view it as a chance to expand your skill set rather than an indictment of your intelligence.
  • Celebrate your wins, big and small. It‘s easy to fixate on what you don‘t know or the mistakes you‘ve made. Make it a habit to reflect on your successes, whether it‘s shipping a tricky feature or getting props from a teammate on your elegant code.
  • Talk to other engineers. I guarantee you‘ll be hard-pressed to find a single developer who hasn‘t experienced self-doubt. Sharing your struggles and hearing how others have overcome similar challenges can be incredibly cathartic.

Imposter syndrome may never fully go away – I still wrestle with it from time to time. But with practice, you can learn to recognize and manage those pesky thoughts so they don‘t hold you back.

Code Quality Matters More Than Quantity

As a new engineer eager to prove myself, I fell into the trap of measuring my worth based on the sheer quantity of code I could produce. I puffed up with pride seeing my commit count rise and new features shipped at a rapid clip.

However, I quickly learned that not all code is created equal. Sure, I could hack together a clunky, brute-force solution and ship it to production. But did that make me a good engineer? Was it code I could be proud of and that would be maintainable over time? Questionable.

In the wise words of renowned computer scientist Harold Abelson, "Programs must be written for people to read, and only incidentally for machines to execute." Clean, readable code is a cornerstone of software craftsmanship.

Consider these two contrasting code snippets:

// Convoluted, hard to read code
function calculateAverage(arr) {
  let t = 0;
  for (let i = 0; i < arr.length; i++) {
    t += arr[i];
  }
  return t / arr.length;
}

// Clean, expressive code
function calculateAverage(numbers) {
  const sum = numbers.reduce((acc, cur) => acc + cur, 0);
  return sum / numbers.length;
}

Both functions achieve the same end result, but the second is far more readable and expressive. As a general rule of thumb, strive to write code that your future self or another developer could easily understand and modify six months down the line.

Some key tenets of clean code include:

  • Descriptive naming of variables and functions
  • Concise functions that do one thing well
  • Consistent formatting and indentation
  • Judicious use of comments to explain complex logic
  • DRY (Don‘t Repeat Yourself) and modular

Writing clean code is an art that takes time and practice to master. But it‘s a worthy investment that will pay dividends over your entire career. Not only does it make you a more effective engineer, it also makes collaborating with others and maintaining a large codebase much more manageable.

As Seth Godin astutely said, "clean code is not written by following a set of rules. You don‘t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines." Strive to internalize the values of craftsmanship rather than blindly memorizing a list of "best practices".

Effective Communication is Just as Important as Technical Skills

I used to believe that being a great engineer was purely about technical prowess – the ability to code fast, solve complex problems, and have an encyclopedic knowledge of algorithms and system design. And while those skills certainly don‘t hurt, I‘ve learned that communication and collaboration are equally fundamental to success.

Think about it – unless you‘re a solo founder, you‘ll spend a significant chunk of your time interacting with others. You need to be able to clearly articulate your ideas, give and receive feedback gracefully, and work effectively in a team.

Some communication tips I‘ve picked up:

  • Be proactive in asking for help or clarification. If you‘re spinning your wheels on a problem, don‘t suffer in silence. Reach out to a manager or teammate for support.
  • Practice active listening. When a coworker is explaining something, give them your full attention. Ask clarifying questions and reflect back what you heard to ensure you‘re on the same page.
  • Assume positive intent. In the heat of a discussion or code review, it‘s easy to misinterpret feedback as a personal attack. Remember that you‘re all on the same team working towards a common goal.

One framework I‘ve found helpful is the concept of "Radical Candor", popularized by Kim Scott. It‘s based on the idea that the kindest thing you can do for someone is to be direct with them while also deeply caring about them as a person.

Radical Candor Framework
Source: Radical Candor

Aspire to give and receive feedback that‘s both caring and direct. It‘s a difficult balance to strike, but it‘s a powerful tool for growth and maintaining healthy working relationships.

Prioritize Learning and Experimentation

The field of software engineering evolves at a breakneck pace. New frameworks, languages, and tools are constantly emerging and falling out of favor. It‘s impossible to keep up with it all.

Instead of getting overwhelmed by the sheer volume of things to learn, I‘ve found it helpful to adopt a mindset of continuous learning and experimentation. Some strategies that have served me well:

  • Set aside dedicated learning time. Each week, I block off a few hours to work through an online course, read technical blogs, or practice coding challenges. Consistent, incremental progress really adds up.
  • Teach others what you‘ve learned. The best way to solidify your understanding of a concept is to explain it to someone else. Write a blog post, give a lunch and learn presentation, or mentor a more junior engineer.
  • Build small side projects. Tinker with that shiny new JavaScript framework or CSS trick you‘ve been meaning to try. Having a fun, low-stakes environment to experiment in is a great way to learn.
  • Don‘t be afraid to fail. Experiment with a new technology or technique, even if it doesn‘t pan out. The most valuable lessons often come from failure.

A recent Stack Overflow survey found that 75% of developers learn a new technology at least every few months.

Frequency of learning new technologies
Source: Stack Overflow Developer Survey 2020

Embracing a growth mindset and carving out time for deliberate practice will serve you well in the long run. As author and software engineer Edmond Lau said, "the more you learn, the more you realize how much you don‘t know." Let your curiosity guide you.

A Day in the Life

To give you a sense of how these principles translate to the day-to-day life of a junior software engineer, here‘s a glimpse at a typical workday for me:

Time Activity
9:00am – 9:30am Check emails, Slack messages, and calendar. Review pull requests and merge any approved code.
9:30am – 10:00am Standup meeting with engineering team. Share progress updates, surface blockers, and set priorities for the day.
10:00am – 12:00pm Heads down coding time. Work on feature tickets, write unit tests, debug issues.
12:00pm – 1:00pm Lunch break. Step away from my desk and eat with coworkers (when working in office).
1:00pm – 2:00pm Code reviews. Leave feedback on teammates‘ pull requests and address any comments on my own code.
2:00pm – 4:30pm More heads down coding. Pair program with a senior engineer on a tricky bug. Refactor a legacy component to be more modular and reusable.
4:30pm – 5:00pm Reflect on the day‘s work. Update ticket statuses, document any key decisions or learnings, and plan tasks for tomorrow.
5:00pm – 6:00pm Learning time. Work on a side project, read blog posts, or complete a coding challenge on Leetcode.

Of course, no two days are exactly the same. There are plenty of meetings, interruptions, and unexpected fires to put out. But I try my best to carve out chunks of uninterrupted focus time for deep work.

Resources for Leveling Up

If you‘re looking to accelerate your growth as a new software engineer, here are some of my favorite resources:

Books:

  • Clean Code by Robert C. Martin
  • The Pragmatic Programmer by Andrew Hunt and David Thomas
  • Cracking the Coding Interview by Gayle Laakmann McDowell

Online Courses:

Coding Challenge Websites:

Engineering Blogs:

I‘m also a big fan of the Software Engineering Daily podcast for keeping a pulse on industry trends.

The Journey Ahead

As I reflect on how far I‘ve come in the last 9 months, I‘m filled with gratitude for the incredible learning opportunities and growth I‘ve experienced. At the same time, I‘m acutely aware of just how much I still have to learn. The pursuit of mastery is a lifelong endeavor.

I‘ll leave you with this quote from poet and philosopher Rainer Maria Rilke, which encapsulates the spirit of curiosity and continuous growth that I strive for:

"Be patient toward all that is unsolved in your heart and try to love the questions themselves, like locked rooms and like books that are now written in a very foreign tongue. Do not now seek the answers, which cannot be given you because you would not be able to live them. And the point is, to live everything. Live the questions now. Perhaps you will then gradually, without noticing it, live along some distant day into the answer."

Let the questions and challenges you face as a new engineer fuel your growth. Embrace the struggle and have faith in the process. With dedication, hard work, and a healthy dose of curiosity, there‘s no limit to what you can achieve. Onward and upward!

Similar Posts