Growing as a Software Engineer

Growth #

I wonder if you've ever felt helplessness, an overwhelming aura, or pressure (or motivation from a positive mindset) while observing other developers' capabilities. I have, many times. Sometimes it was from colleagues at work, sometimes from strange artists (?) residing in open source, and sometimes from people I'd heard about through others who were my age. While such opportunities can act as strong growth catalysts for some, for others, they can be a trigger point for burnout... Why is that?

It's likely due to cognitive load. The field of software is vast, and then some, truly immense (!). Because of this, when you encounter someone overwhelming, you might feel compelled to do this and that, and what you're currently working on might seem worthless, leading you to covet what others have. I'm the same way. It's natural. Why? Because, as I said, the field of software is incredibly vast, making it very difficult to grasp where you stand, how proficient you are, or what you lack.

Software engineers clear given missions through the act of programming. Not just clearing them, but doing so while conserving as much as possible and producing as much as possible. The decision I've made right now might not be the best, nor the optimal one. However, it's hard to recognize whether it's optimal or not. Therefore, I might mistakenly believe it is the best. Developer growth is similar. Have I truly grown as much as I aimed for? Is my position average for my years of experience? I don't know. There's no one who can accurately evaluate that with precise metrics. (Of course, there might be someone who offers simple feedback and guidance.)

So, how can I understand my current position and identify what I need most right now?

Retrospection #

You've probably heard it countless times, but the method is retrospection. You've likely encountered growth theories about cycles like Plan -> Do -> Fail -> Retrospect -> Plan... (The terminology might differ, but you'll get the general idea.) Why is that? If you don't plan, you can't try; if you don't try, you can't fail; and if you don't fail, you can't find your problems. I have many weaknesses. They're just not visible. Or perhaps I see them but don't want to. That's why I need to confront them. I need to develop metacognition.

Our brains are designed to compute to solve problems when presented with them. This is directly linked to survival. When we perceive hunger, we conclude that we need to eat. The closer a given mission is to survival, the more desperately the brain starts working. While the weight might differ, the point is that it's important to pose questions and clear those questions. This is a topic often mentioned not only in retrospection but also in studying. For now, just retrospect. I'm sure I have many problems; it's just a black box state right now.

However, you can't turn this black box into a white box all at once. The reason is that you haven't faced the situations where your weaknesses become apparent. Therefore, experience many things, have many regrets, and make many attempts. And retrospect. If you don't retrospect, that experience cannot be considered an experience. Whether you write a retrospective, update your resume, or reflect through meditation, the 'how' is up to you, but I personally recommend writing it down. The human brain easily forgets memories, so the act of recording is best.

Writing carries a unique weight, and it has the characteristic of being retrievable later. Don't think you need to write thousands of lines for a retrospective; I believe about 10 lines are sufficient. Regarding retrospection, the framework I use is winswoopswow (www). It involves writing 3-5 sentences on three topics: what went well, what was regrettable, and what was surprising or discovered. I recommend doing this quarterly. First, identify your strengths from what went well, and looking at what was regrettable, formulate strategies to further leverage your strengths and eliminate what was regrettable. And what was surprising is good for reminiscing or inspiration.

Second Career Path #

The title of software engineer seems to imply developing across various fields rather than being confined to just one. (Server, Frontend, DevOps, IoT, SRE, etc.) However, most developers will have their own specialization. But if you plan to stick with just one for 10 years, I wouldn't particularly recommend it. I won't say 'I respect stable values'. Because the era where specializing in just one thing guarantees stability is gradually coming to an end.

If you're a server developer and hungry for growth, you'll study servers in depth. But eventually, a moment will come when you know most of what there is to know, and review accounts for over 80% of your learning. At that point, you could deep dive further, and while server technology itself isn't a narrow field that can be fully mastered and is indeed vast, I tend to think that the necessary content for working and developing can be easily mastered. So what now? It's time for a second career path. If you're interested in machine learning, study machine learning. If you're interested in DevOps, study that field.

Do you feel like you have to start from zero again? Do you think you have to take a long detour? Absolutely not. The experience you've learned and accumulated previously will help you reach the truth faster. They say it's easier to achieve success by being 25% proficient in two fields than 1% proficient in one. That doesn't seem wrong. Of course, being 25% proficient in each is easier. (While 25% itself is difficult, it's undeniably much easier than 1%. Being in the top 1% on Earth is extremely difficult.) Therefore, try learning various things. But please keep one thing in mind: pursue what you genuinely want as your second career path. Please refrain from opening books out of obligation, feeling like you have to do something you don't even want to.

Conclusion #

The job of a developer might seem incredibly difficult, but in fact, it also seems to be the simplest. You implement business logic with code, improve it, and automate it. Then you implement new things again, improve them, and automate them. Going further, you might write high-end queries, tune systems, or combine it with management to increase organizational productivity. Ultimately, whether it's management or being a generalist, the conclusion is that you shouldn't just stick to one field. The formula for a developer's capability isn't just depth. You can also multiply depth by breadth.

Capability = Depth x Breadth

If the capability you currently believe you need is depth-based, I don't recommend a second career path. That's because you yourself believe you haven't grown enough in your current field of software to your own satisfaction. As you develop, there will come a time when you start thinking, 'I've done enough of this, I want to try something else,' and when that 'what' becomes clear, I hope you'll gradually start. Let's begin with Hello World.

Developer growth is a repetition of attempts, failures, and retrospection. This resembles the success formula of entrepreneurs, but the difference seems to be the burden. It's okay to fail because you can try again more freely and broadly than in business.

I think that's the charm of software development, in my opinion.