At Clay Token, our software development engineer Serdar Oygen shares the challenges he faced while developing Steel Swarm: Apocalypse, the best advice he received in software engineering, and how he stepped out of his comfort zone in this project. 🚀

🔹 Can you briefly introduce yourself?

I have been working as a software development engineer at Clay Token for about 1.5 years. I love listening to music and outdoor sports.

🔹 What music genres and bands do you listen to while developing?

I can't write down a long list here, so let's just say I pick whatever comes to mind at the moment and go with it.

🔹 What is the best piece of advice you’ve received about software development?

There are two types of software engineers: those who understand computer science well enough to do challenging, innovative work, and those who just get by because they’re familiar with a few high-level tools.

Both call themselves software engineers, and both tend to earn similar salaries in their early careers. But Type 1 engineers progress toward more fulfilling and well-remunerated work over time, whether that’s valuable commercial work or breakthrough open-source projects, technical leadership, or high-quality individual contributions.

Type 1 engineers find ways to learn computer science in depth, whether through conventional means or by relentlessly learning throughout their careers. Type 2 engineers typically stay at the surface, learning specific tools and technologies rather than their underlying foundations, only picking up new skills when the winds of technical fashion change.

🔹 What was the most challenging bug you encountered in this project, and how did you solve it? Also, what was your last "developer panic moment," and how did you handle it?

A build automation script was silently crashing every once in a while, and I couldn’t find what was wrong for a long time. Eventually, I had to implement a preventive measure to detect silent crashes and do whatever was necessary.

As for my developer panic moment, while people were waiting to join a test match, I accidentally killed one of our backend services. Unfortunately, there was no quick fix. People just had to wait until I got the service running again.

🔹 What’s something you did in this project that pushed you out of your comfort zone, and you’re glad you did?

When I first started with the project, I was assigned gameplay-related tasks, and there were many aspects that challenged me. Using different systems instead of what the game engine provided helped me step out of my comfort zone and learn new things.

Over time, as my tasks grew in scope, I found myself spending a lot of time outside my comfort zone. In my opinion, for someone at an early stage in their software engineering career like me, staying in a comfort zone doesn’t mean much.

🔹 What are you currently learning? How do you prioritize your "next things to learn" list?

Right now, I’m reading essays by Fred Brooks. As the scope of my work expands, I find myself needing to explore the social aspects of software engineering. After this, I’ll move on to topics that will require me to get under the hood and do low-level stuff.

When deciding what to learn next, I focus on a few key things:

• First, I have a main goal for what I want to achieve.
• Then, I choose smaller objectives that contribute to that goal.
• As I learn and gain new insights, I adjust my learning path accordingly.

Sometimes, I pause. Sometimes, imposter syndrome kicks in. I don’t see these as failures, just part of the process—another reason why I don’t rigidly stick to a priority list. I don't see these things as black and white, which is why I find the idea of a "strict priority list" a bit rigid. So, I can’t give a definitive answer here.

🔹 How many cups of coffee do you drink per day?

Zero. The cliché of programmers and their love for coffee will remain a cliché for me.

🔹 What advice would you give to a newly graduated developer?

Don’t turn every piece of advice you receive into a personal problem just because you lack experience.

This is your journey—walk your own path.

🔹 Among the features you developed in this project, which one makes you the proudest and why?

I take pride in any feature that increases efficiency, remains functional for a long time, adapts to new needs with modifications, and is easy for my teammates to use.