Interview with: Csaba Okrona

Introduction

In this edition, we sat down with Csaba Okrona, Senior Engineering Manager and author of ‘The Managers Guide’ to discuss the evolution of his career from hobbyist beginnings in the 90s to navigating professional growth in modern software engineering environments.

Talking about coding - owning computers started to become a thing in the 90s in Hungary. At that time, my grandpa was working at a press and when they refreshed their line of PCs he bought an older one for me.

Obviously, I wanted to play with it, but it was mostly too old of a model for that - so there I was with a machine I’d been dreaming of, and not being able to use it. Then a family member hinted to me that I could start programming, it’s fun - started out with QBasic, drawing shapes on the screen, then animating them, all that jazz. It felt like magic!

This was already during high school and I shared my interest in programming with a friend there, so we started hacking a lot, from low-level hardware programming to even writing viruses.

One year we had an IT teacher who was a real programmer, teaching was only his side job - that was my first experience of how “real” programming would look like - basically we could pick a project, come up with the project proposal, run it by him, and then spend the semester however we wanted, as long as we came back with a working project at the end. We’d consult him during execution and it was super fun!

At this point, we were doing it because it felt cool and because it felt good to be good at something only a very low percentage of our mates even knew about.

Obviously a lot has happened since - found out professional development is quite a bit more than me hacking away in my room, found the human side of things and how building organisations and enabling them gives me much more joy.

Nowadays, I mostly learn new languages for fun and for deeper understanding. I have the luxury to do this as I’m not programming in my day-to- day job.

There are a couple of languages I’ve enjoyed a lot working with over the past 30+ years:

Python for how well it scales both in terms of the kinds of projects and engineer seniority. It might not be the fastest language in the benchmarks and it doesn’t have all the bells and whistles when it comes to language design (though it has some unique features), it’s catering for very straightforward, easy-to-understand things and quite complex ones too. We ran a python shop back at Prezi for a couple of hundred million users.

C# for its language features, maturity and performance. The whole .NET stack evolved into something amazing over the years, it’s not a Microsoft playground anymore.

Lisp for its simplicity and expressiveness. I had maybe the most fun with this family of languages. Wouldn’t use it in a serious company project because of the shortage of engineers who know it, but it’s mind-blowing. I think every engineer should learn lisp, it gives you a completely different, pure view on programming.

That highly depends on the environment and the type of company/problem space - in general what you want is a well-rounded team, not a uniform pool of individuals. There’s room for a few highly skilled specialists, alongside a larger set of generalists.

If I had to pick a couple of traits, here’s my list:

• They are good communicators: they know how to talk to different kinds of people with different experience / level of understanding of the topic, e.g. junior developers vs. seniors, PMs, business people, customers.
• They take ownership of their stuff: I don’t mean working after hours! I mean thinking about the project and the system holistically, feeling a sense of responsibility for it and acting accordingly.
• They have a product mindset: they understand how what they do day by day and project by project fits into the bigger picture. They don’t need to be product experts, but they care about the ‘why’, not only the ‘what’. They are not afraid to challenge the product directions and even suggest alternatives. Your best technical solution is meaningless if it doesn’t help with the goals.
• They are problem solvers: they understand that programming is a tool and are excited about the problems that can be solved with or without it.
• They are team players: They understand that it takes a village. They know when to step up and when to step back and enable others. They don’t come with strong egos. They get excited when they work with smarter people vs. feeling threatened.

When it comes to me being a software engineer, it was definitely me joining Prezi. I used to be a CTO and then went back to engineering, all my friends called me crazy for it.

Before, I built things “my way” — it worked out, but I made most of the calls and designed the system with my very limited experience. It was success by chance.

At Prezi, there were a ton of experienced people and I learned a lot in that environment. Proper scale, proper approach to software engineering, proper engineering culture.

My advice: once you know your next level, find a place which helps you get there. Prioritise this over titles and salary.

Oh, that’s a tough one. AI seems to be the next big thing, and a lot of people say it’ll take away our jobs — I personally don’t think so (I might be horribly wrong here of course). I think AI will streamline the way we work, take away a lot of the mundane repetitive things and will make us more efficient. The danger of it, though, is like the danger with e.g. frameworks, too — less and less people will have a deep understanding of their stack, because it’s so easy to ask ChatGPT to write a certain functionality for us. That knowledge, of course, is very infrequently required, but when it is, the people who’ll have it will be crucial.

AI might lower the entry barrier for new startups and thus delay when they need to hire their first engineers. (low-code, no-code, or codegen) — though it’s a tradeoff that founders need to be aware of (the solutions might not be future-proof and will probably require a lot of re-engineering once the product-market-fit phase is done).

Juniors can already use AI as a sparring partner to improve, but they need to be aware that AI is very incorrect sometimes. It can be a great tool to e.g. explain existing codebases, which is something you’d only be getting from a colleague otherwise.

All in all, I don’t think engineers are going away anytime soon. Utilising AI as a tool will show up as a new essential skill.

I don’t think a lot of how I grew applies today, the 90s and early 2ks were a different environment. That said, I’d tell myself to pick one good stack and stick with it until I get really good at that, only diversify after. Be more deliberate in my growth. Then again, that might have taken some of the fun out of it for me, so who knows.

Another thing I’d do is double down on the human side earlier. Soft skills aren’t only for managers. How you work with others matters way more sometimes than your raw coding skills. It’s a team sport.