Software Engineering: Year 2 Retrospective

I started my journey as a professional in software engineering two years ago, on December 2019 where I was also in my last semester at college. A lot of things happened. Today I try to take a retrospective look over my career, looking back to what I've learned along the journey.

What's the goal of this writing

Although it is short and there's still a long way to go, I've learnt and improved a lot, both professionally and personally. I've been through quite few ups and downs, made mistakes here and there.

One day, I tried to summarize what I've learnt for the past two years, and it turns out to be a lot. I also found a lot of them to be very important to know early in the career, and wished that someone could teach me that lesson instead of learning it the hard way. So it just came up to me to write these down, and perhaps it could be any useful for others, especially those who are just starting out.

Another goal of this writing is to create a yearly retrospective for myself, sort of written checkpoint as I go further into my career in Software Engineering.

Some things will be obvious and might be a bit questionable or rather wrong, But I think that was also the reason why it's good to have a written retrospective. Because I believe that as I go further into the field, I will learn more things, unlearn some of them, understand why some things work certain way, and perhaps there will be a point where I've changed my mind about things. It's Growth™ in a nutshell.

My writings here is based on my experience as a Software Engineer. While most of the topics are specifically discussed around it, I believe that many takeaways are applicable to other area in different career, or even life in general. So a bit of healthy disclaimer there and off we go!

Things I Wish I'd Have Known Early

When I first landed in the field, it was a complete dark. I don't know what to do, I have zero idea what's people talking about, face is as blank as my notes, and then there's sudden surge of thought Am I even ready for this?. I believe we've all been through this in all kind of scenario, not just career, the difference is that some handled it better or worse than others.

My first years are rough, but fortunately I got all the help I needed and could reach the point where I am now. However, I see recurring pattern of behavior among those who are just started. I sensed this when there's new joiner in my team, and seeing them behave like I was in my early days. It feels like looking through a time-glass, seeing past-version of myself. That's when it came up to me that it will be helpful if some lesson could be learned early, and hence why a mentor is proven to be useful.

If you are just started on your career (not just in Software Engineering), hopefully this might help.

Everybody got a starting point

Everybody sucks at the beginning, that's the truth I think everyone should know first.

What I see in myself and a lot of others when first starting is that there's internal feeling that we should know everything and able to perform as well as others, right off the bat. We have tendency to feel bad if unable to do so, which could lead us to overthink, and forces ourselves to overwork as much as it takes just to barely catch up.

The thing is, it's normal to have a rough time when starting a new job, it's okay to be confused and overwhelmed, especially in the first job. We do not know how the team communicate, plan, and execute tasks. The tech stack could be fairly new for us. The codebase is usually a legacy, a pile of tech debt and weird logic flows. It's hard and unrealistic even for experienced engineer to be able to blaze in and whip out thousands line of code in this situation.

What could we do instead in this situation is to maximize our ramp-up period by setting up realistic milestone with manager, asking for a designated mentor to help us to work with codebase and such. And honestly, just take your time. Do your best and everything will feel easier, you will get familiar with the team, the codebase, and you will grasp the design pattern.

It will come around, just not in an instant.

Do not hesitate to ask for help

My biggest issue when first starting out is that I'm afraid to ask for help. I have been in college for 4 years, I have made many projects, I passed the interview, I should be able to do my job, right?

Truth is, engineers got stuck all the time. What I've seen is that actually, experienced engineer ask a lot of questions. I think this issue stems from an understanding that if we are capable, then we should know how to do it. Not only that this is wrong, but also very limiting, how will we know and grow if we don't ask more?

Another issue is that I fear that it will burden my senior if I ask too much, but as someone who now has mentored new joiner I could say, please do ask as early as possible. If you think your senior peers are bothered with your piling questions, they will be far more burdened with bugs and unfinished tasks caused by uncleared questions, which sometimes fatal. Think of it this way, accept that you will be a burden for your peers anyway, and it's okay. Try to minimize it by asking and clearing the problem at hand as early as possible.

Another thing is I used to ask bare questions, such as How to do my task? how to apply X?. This kind of question is heavy to answer, not because it's hard, but it's too far wide of a question and takes a lot of time to answer. If you are struggling with this too, try this. First, try to gather and find as much as you can within 30-60 minutes. Then, if you are still stuck then ask right away with additional context you have gathered. Such question could be:

Hey umm so for my task I have to add X logic to Y usecase, but I don't think I understand Y usecase, if I'm not wrong Y usecase does A B C, which if I add X logic it will break existing ones, can you help?

This questions already gives clearer context for your peers, and they can give contextual answer too, and perhaps additional knowledge to the logic. A more targeted answers could clear many blockers.

It's about acknowledging what you don't know

There's a lot of things to know in Software Engineering, it's so much you might be wondering whether a stack is real or a pokemon name.

I used to be on the chase for knowing all things happening on the desk, and feeling insecure for not knowing it. I always looked up to my peers and wondering how these people could know all these things, and know when to use what, until people started looking up to me for the same reason, now I know why.

It's not about knowing everything, it's more about acknowledging what you don't know. Objectives in Software Engineering are often presented unclear, and engineer gets confused all the time regardless their experience. However, more experienced engineer tends to be better on breaking down these objectives into smaller, executable items. And even though it's still unknown how to do it, they can find how to do it through trusty Google search and ol' Stackoverflow... most of the time.

Let's say you are assigned to implement a usecase to send regular summary update through email, that sound thick already, isn't it? but what if we break it down to these list

• create a scheduler to run something at specified time
• query and process said summary
• send some data to certain email

Now it's more manageable, and we can derive some keywords to look for any ways to implement, a quick search and now we learn what a cron is, and also an email package to fulfill our needs. In real scenario, problems are far more complex, but I believe the method still applies.

I'm still learning how to do it efficiently - and I'm still far from it, but it seems that it gets better with more experience, sort of building muscle memory for problem-solving.

Better Approach when Picking a Career

I used to consider which job worth picking based on simple -mostly egotistical- factors, such as company brand, hype, and salary. Until one day I saw an article by Gergely Orosz that discussed there's more to it. (see the article here. , it mainly talks on trimodal nature of software engineering salaries, a great insight)

Then it also came to my mind, it's easy to pick what we want in our career, we want everything. huge salary, good work-life balance, hyper growth, aspiring career, etc. But I think we rarely realize that in real world, each of these costs something in return, or even contradicts each other (e.g. hyper growth usually comes with poor work-life balance). It's just impossible to have it all without any consequences.

We also need to consider that employer are also trying to maximize output for every cents spent, which is very reasonable, that's how business operates after all. That's why I think it's better to have a method to calculate it.

The Give-Take Ratio

When looking for a career, It's wise to put in all possible factor into some sort of ratio, such as these.

Illustration of Give-Take ratio I try to use

What makes this ratio important is that most, if not all, things we look for usually come with a cost. A career with faster promotion ladder could come with tense politics. A senior role is usually expected to have high ownership and responsibility. Working at a pre-seed startup has high uncertainty, but offers high return when it's successful.

I think the inverse of this ratio could also works for employer when looking for potential candidate. After all, an ideal ratio should be anything near 1 -a stalemate-, meaning that both parties give and take equally from each other. What makes it unfair is that when the ratio is either too small, or too big.

Many factors can be swapped in/out or changed entirely depending on what we value when looking for a career, or what is available for consideration. So, how we decide which factors should be included in the equation, and how much portion should it take? Listing down and considering these things might help.

Pain tolerance you can afford

Every career path we take has its own pain. Engineer has to deal with their system continuously. Manager has to deal with all kind of good/bad humanity could bring. Business owner must face with a risk of going down any moment.When it comes to pain tolerance, it greatly varies among people. And knowing what we could fathom could help us pick which career path will suit us better.

I have a real case for this one, One friend of mine loves working as academics, he can endure going back and forth doing revisions. Taking harsh, blatant (but constructive) feedback from his seniors. But on the other side, he has freedom to choose his research topic. He has flexibility to pick joint-research program that generates money and build credentials, pushing his career forward. And he's currently living the best moment in his life.

It's easy to get envy and having an internal debate Well I think I should do that too, it seems good, I don't have to go 9-5 for god knows forever!, but can you endure the pain? the uncertainty, non-stop pressure to keep researching, and having to back a single argument with tens of journals, and get it dismissed because it is not strong enough?

The good news is that pain tolerance can be built, after all it's a principle. Another friend of mine is considerably great in doing stock trading and investing, and I honestly think he could quit from his coding job and making more money from stock trading instead. Stock trading requires high amount of patience and high discipline when it comes to managing profit/loss. And he built it from scratch years ago, from investing small leftover money, learning theories, and probably experiencing a huge loss first-hand (we learn the most from immense mistake and regret, after all).

Knowing which pain tolerance we have, or we could dedicate into, opens to which opportunity we can endure through.

Things you can/cannot let go

For every things we take, we have to let go of something else. Being an engineer means we have to let go of our comfort zone as we have to eternally keep up with absurdly ever-changing tech stack, or get left behind.

Common situation I see (and experience it myself) is that we are happy to finally do something we want, and then regretting it down the road because we have a hard time dealing with its consequences.

We have a thriving, high-earning career, then we regret it because we don't have time for anything else. We finally got a chance to work abroad, then regret it because we feel alone and far from our loving friends and family. Some people could deal with that, heck even excel at it, but we don't, and it's okay, we have our own things we cannot let go.

So now, I propose that rather than listing down our dreams, we write everything we can/cannot let go, so that the remaining options left are the one we can deal with at least a little peace. Here's an example.

An example table to list down things we can/cannot let go

The goal of writing these down is that, hopefully, in the end we can make an option with consequences we can deal better. It seems harsh and limiting, but in the choice-consequence economy, I believe it is mandatory.

Things I Should Keep in Mind Moving Forward

This section is for things that I still struggle for, and I should seek and prioritize to handle moving forward.

Comparison is the death of joy

I can't stop comparing myself to others. Specifically, I can't stop comparing my failures with others' successes. It's unhealthy and it need to stop.

Everyone has their own share of success and failure in their life, but in today's age, especially with social media, it's easy to get exposed to the highlight (or the extreme should I say) of these moments, and comparing that with our, mostly normal, life will only invalidate what's happening in ours. It's unfair to compare those with ours, especially comparing our losses with others' wins. As we also have our moments, a share of success and failure of our own.

Be mindful, acknowledge it, and move on.

It's mandatory to have a boundary

It's hard for me personally to set a boundary between life and work, and it costs me big time.

I now understand that career (especially in software engineering) is a life-time journey, not a 2 weeks sprint, and surely not a whackful 2 days hackathon. Going all in all out is not sustainable. It might be good for a couple of months or even years, but for decades? Good luck with that.

Another thing to note is that going extra miles are oftentimes went unrewarded, and only set expectation higher. I know some people who have experienced this, it's not good.

So it's good, even necessary to have boundary, a breakpoint where we can disconnect and recharge. A point where we are a resource, a means to an end, and another where we can be ourselves. It's necessary for prosperity of company too as stable, healthy, performing employees pay off in the long run than high-burst, short-lived ones.

Things will get harder, but you will get stronger too

I always have thought that things get will easier as time goes by, but then again I was wrong.

Things will get more complex over time. First you struggle with adapting, then you will get used to it, and now you are assigned to something big, and then something harder come. You get used to your work then your life outside work gets harder too. The circle never ends.

Come to think of it, that's the nature of life. We stand up, gets whacked, stand up again, gets whacked even harder. But then again, we will get through it, learnt from it and being better with every storm. Perhaps it is the base suffering necessary for growth.

But as a cliché saying that's been said many times, this too shall pass.

There's more to life than this

It's rather unhealthy to attach our identity to singular, temporary things (such as career). As there's more thing to seek out for. We could try something new, a hobby, execute business idea, or go on an adventure. Or we could deepen what we already have, connecting with friends and family.

At least we can try to just live at the present moment and be open to other activities in life, writing a blog is one example. I honestly don't know where writing will get me to, perhaps I will abandon it later, or it could change the course of my life.

What's next

This writing shall conclude my career retrospective as Software Engineer in 2021. I'm very thrilled and looking forward to what's available in store for 2022. Gotta expect the unexpected. It might be better, but it also could be so worse I will be spiraling down (please I hope not), but sometimes a leap of faith is necessary in pursuing a better future.

Until next year.