Working at a hyper-growth tech startup has provided me with both technical and non-technical learnings. My experience changed the way I thought about software engineering and what skills and actions lead to the delivery of projects that provide short and long term impact.

Table of Contents

Introduction

Everyone talks about how important “soft skills” are to being successful at your job, but it wasn’t until this role that I was able to break “soft skills” down to more detailed components and iterate on them.

This post details my main learnings and how I reframed my mindset towards what it means to be a professional software engineer.

Reframing my Mindset

Being a software engineer requires a balance of skills. Prior to joining my current company, I believed that the ratio would be approximately

programming soft skills
80 20

for an individual contributor.

If I had prescribe quantitative numbers now, it would be something like:

programming writing pragmatism strategic thinking other
40 25 15 10 10

This ratio will differ depending on your team, seniority and your role.

Let’s talk about all of these components.

Programming

This is just the raw skill of programming. How well you understand the codebase, the tradeoffs between different implementations and how fast and accurately you can implement code.

There’s no shortcut to this unfortunately. You have to code a lot, think about coding a lot, read other people’s code a lot and constantly challenge yourself with technical problems of breadth and depth. Doing side-projects also helps (for me, especially!).

Originally I was going to give this 50% - but that would more than likely be my own bias towards technical competency rather than a reflection of my day-to-day reality.

Writing

A large chunk of the drop in programming ratio went to “writing”. When I first joined, I had the habit of jumping into coding straightaway, trying to build and ship things.

This was a great display of initiative, but had 2 shortcomings. First was that during PR reviews the senior developers had many questions about how the implementation is done and value of the feature being built. This meant that I often had to re-write substantial amounts of code and progress was blocked for a long time on review.

Second, as I became responsible for more complex and larger pieces of work, having to assemble all the moving parts inside my head became more difficult. As part of my feedback from my manager and out of my own initiative, I started to write more (I was also inspired by Eugene Yan - who has a great blog).

In tech companies, there’s a common concept called a design doc. Basically it’s a document that explains the context, problem, solution and implementation (at a high level) to the project you’re working on or trying to solve.

Writing design docs takes substantial effort and gaining approvals from stakeholders and senior engineers can often take weeks if not months.

In a single quarter, I might write only 1-2 design docs but would be involved in multiple projects. As a result, I talk to different stakeholders, often async due to WFH.

Since design docs are meant to be lengthy and involve multiple review cycles, I decided to rebrand my writing to other forms of documents. For example, I would call them mini docs, analytic docs, Q&A docs - basically anything except design docs!

I think this subconsciously encouraged readers to read and approve quickly since its not a full-blown document.

The purpose of these documents were straightforward - succinctly express my thoughts on paper, have everyone’s questions and feedback in writing and leave a visible trace of all the sweat that I poured into the decision-making process.

This made it so much easier to align with multiple stakeholders and once approval was granted - I no longer worry about being blocked by decision-makers - they’ve already made their decision!

I strongly recommend getting into the habit of writing and doing it often at work. It’s been so helpful and like any skill - the more you do it, the faster and better you become.

Oh, and in case you’re wondering - the professors at UC Berkeley seem to take their design docs pretty seriously too! 😛 I leave a direct quote for you below

We will grade your designs harshly. The design is essentially the most important part of the project. Having a good project design can literally cut your total coding time by a factor of 10.

Pragmatism

“Pragmatic excellence” is one of our values. In both performance reviews, I received feedback asking me to “be more pragmatic”. To be completely transparent - I think I’m a pretty results driven person, don’t fuss too much about technical implementation and get job satisfaction from delivering features to users.

That being said, I tend to prioritise things that will bring a 100x multiplier value in the medium-long term.

Unfortunately, we work on a cycle of 3 months. Hence it was essential to break the tasks down into 3 month chunks so that we can show results. This is how we worked as a team to pave the road towards long-term success whilst shipping incremental value.

This way of thinking is how I plan my own work now. Think about the north-star objective and execute on delivering small value-adds and slowly but surely build the features that will propel the team towards achieving success in the long-term.

Being able to slow down and prioritise, argue for a set of ideas based on their “quick-win” AND long-term value, is a skill I had to develop.

Strategic Thinking

As you become more senior, you are expected to bring more impact and value to the company. Either you write better code faster or you bring ideas and assemble a team to deliver them.

Whichever process you choose - learning how to develop a strategy is crucial. At the end of each quarter my biggest self critique is always; “3 months have passed but I haven’t really thought about what all this means for the long term.”

As an individual contributor, the responsibility of setting the direction of the team does not fall on me. Despite this, I couldn’t help but notice that the more senior someone was, the better they were at crafting strategy and articulating that to the people around them.

My advice to self would be - keep listening to others, read through team roadmaps and bring up discussion points for the team. Try to kickstart conversations about things you think are important. Even if it’s knocked back - at least you better understand why others things are a bigger priority.

Fortunately, I recently had a team discussion and we de-prioritised one of our deliveries in favour of a project we planned for the next quarter. It goes to show that sometimes all you need to do as a junior is to bring people together and ask the right questions.

Another thing I found effective is to volunteer to work on projects you think are important. Actions speak louder than words - it shows you that you care enough to put more hours into it.

Other

Here is where I get a bit lazy and lump the last 50+ skills into other. It is what you would expect, communicating with colleagues, handling PR reviews, taking the initiative with meetings and projects, knowing when and how to ask for help etc.

All that good stuff.

Oh and one more thing - selling your own work to your manager and senior leadership (who decide your promotion 🤭).

Conclusion

I no longer think of software engineering as just programming and “soft skills”. There are so many components to it and the composition of skills required to succeed will be different to everyone.

My change in mindset has come from feedback, my own aspirations to grow as well as my intent to get a promotion.

I will talk about my promotion in another post - there’s a few nuggets there as well!

Stay tuned! 😉