3 June 2020

Today marks one year of working full-time as a software engineer. While I’m still learning the trade, here are some things I wish I knew when I first started off.

–

1. It’s hard Don’t be fooled by people around you who claim to just get it, they’ve put in their due diligence. It’s normal to experience many moments of helplessness at the start of the journey. With experience and expertise, these moments will start to get rarer. You will feel yourself getting better at solving not just problems you’ve seen before, but also at those you haven’t. This is because your job is to solve complex problems. You’re not only learning - you’re also learning to learn. Technologies will change faster than you can keep up with, unless you try. The world of technology is a fast-paced and constantly evolving one. The learning can never stop, and you need to accept that.

2. Asking for advice Talk to senior engineers. Talk to engineers you respect. Watch how they work. Pair programme. Asking for advice is not just a great way to learn things the easier way, but it also gets senior engineers invested in your growth. Do note though that if you’re always asking someone for advice and never following through, you’re doing one of three things: asking the wrong person for advice, lacking discipline, or a jerk.

3. 2 categories of problems There are 2 categories of problems you generally face as a software engineer. Let’s call them Category A and Category B. Category A problems are problems that you can solve yourself in a short period of time. Some examples of such problems are figuring out the syntax of a for loop in a new programming language, learning the difference between errors and exceptions, and understanding small functions in a codebase.

   Category B problems, however, are quite different. You may not be able to solve these problems immediately, no matter how hard you try right now. This is because these problems may be abstract or esoteric in nature. For these problems, the best thing to do is to “suspend understanding” for now, try to grasp just enough to get by, and revisit your understanding next season. Some examples of Category B problems include understanding design patterns, containerization concepts, and how database migrations work.

   Sometimes, you don’t even know which category the problem you are facing fits into. I think that this gets better with experience, like many things.

4. Looking back and feeling embarrassed There are moments when I look back at code I wrote, and feel embarrassed by either my approach to solving the problem or why I didn’t get there faster. Don’t be mistaken - this is a great thing. If you’re embarrassed, you’ve grown. You’ve understood concepts. You’ve digested information. You’re no longer that same engineer.

5. Reading code Writing code is hard. Reading code is even harder. Reading code requires you to step into the minds of the many engineers who have worked on the codebase before you, and think like them. This is not a skill that comes easily, but definitely a skill that is necessary to excel as an engineer. It’d be foolish to think you’d be working on green fields projects for the rest of your life. Sit down and train this skill. When you’re stuck, git blame and ask author about it. If given the opportunity, pair programme with a senior engineer. You may just learn about a new way of approaching problems.

6. JFGI Stay away from engineers whose response to your every question is to “jfgi”. While it’s not conducive to run to someone for help every time you face a problem, it’s also not fair if senior engineers are not interested in helping you out at all. When you’re new or inexperienced, there are just too many things you don’t know, and you might not know where to start. In these situations, some guidance can go a long way. Some of the best teachings I’ve gotten from senior engineers are not just how to fix a bug, but how to diagnose and analyse so you can get there yourself. Of course, do be respectful and not disrupt someone else’s state of flow when asking questions. Preferably group questions together so it’s less distracting for the other party. This is even more important right now when everyone is working remotely and you can’t physically see if someone else is busy or already off work. And of course, please play that part for the new face once you know what you’re doing.

7. Contributing I often felt small and insignificant because of how little code I was contributing at the start of my career. I still feel like that sometimes. However, the more you know and the more you learn, the faster you’ll be able to contribute. In other words, your contributions will grow exponentially with your growth. While the workplace is not a university where your raison d’être is to learn, I it’s perfectly fine to spend time sharpening the knife as long as it’s in the spirit of what you do. It’s important to pick up new projects and work breadth-wise, especially at the start. Specialising so early on is over rated, or rather, doesn’t even make sense if you don’t even know what you don’t know.

8. Investing in your tools Sometimes, it’s hard to see the big picture, but investing in tools, both hardware and software, will pay off in the long run. Instead of brute-forcing, spend some time, money, and energy on resources that will make your life easier. If you’re going to be staring at a monitor 12 hours a day for the next 5 years, it makes sense to get the one that you enjoy looking at. If you’re going to be using an IDE/text editor a lot, it’s worth spending some time getting to know the shortcuts. It’s probably also worth exploring tools that have stood the test of time, like Vim. People claim it can match the speed at which you think. That’s a bold claim.

9. Burning out The feeling of burning out is normal. I’ve rarely met engineers who never burn out. When I feel burnt out, I take a couple of days off. I turn off notifications, and stay away from the computer. I go on walks without my phone. In less than a week, I’m raring to go again. That’s how I know I’m passionate about what I do.

–

I think we’re extremely fortunate to be in this field at a time hardware is mature, resources are abundant, and opportunities are plentiful. I think the internet has brought more disruption to our lives in the past two decades than anything else has in the past 6 million. I look forward to what the future has in store for us - or rather, where we, engineers, decide to take technology.

Credits A special shout out to David, Mani, KH, Shaun, and TH for being excellent mentors in my journey as a software engineer thus far. I learn a lot from you guys. Thanks also to Vignesh, Ahan, Nicky, Rohan and Varun for reading drafts of this.