Let me start with a simple quote:

“The only way to do great work is to love what you do.” — Steve Jobs

The best way to learn deeply is to do what you genuinely enjoy. Whether it’s software dev, farming, carpentry, or any other task — if you like it, you’ll enjoy doing it and you’ll learn from experience. Our minds naturally grasp the things we care about. Put in more effort where your interest lies, and you’ll get better. I say this up front because it’s something I’ve always told myself.

Understanding the problem well

This is, in fact, the starting point for anything we do. Understand the problem so well that, when given any question from that domain, you can see possible ways to solve it. You don’t always need to “learn” something new to do this — sometimes it’s simply about standing where you are, looking around, and noticing the directions you can move in.

This is something I’m still working on: understanding the problem or the need clearly. Often, when a big problem feels hard, it boils down to very basic questions. If the problem statement itself is unclear, everything becomes harder. So understanding the basics is the first task. I don’t mind spending more time understanding the problem than rushing to a solution — sometimes the real question is the complex part, and that depends on the people and the context.

Breaking the problem down

I wish I could share more personal examples here, but the high-level idea is useful: take any project or problem X and figure out which part of X you’re working on. For example, imagine you’re handed a large OpenCV codebase (thousands of lines) and asked to draw a rectangle around people detected by the camera — but you’ve never used OpenCV before.

If you don’t know where to start, that’s where breaking the problem down helps. Understand the need, and before you touch the main codebase, create a small prototype on your own. If you’re using Python, you might:

  • Create a venv and install the requirements.
  • Import OpenCV (cv2) and explore the available methods.

Try the core idea in a fresh file or the interpreter: capture frames, detect humans, draw a rectangle.

You don’t need to read the entire manual — just get comfortable with what the library can do by skimming function descriptions. The rest is Google and Stack Overflow. If you know exactly what to look for, you’ll find it quickly. That’s the advantage of people who truly understand the problem: they know which search terms will lead to answers.

Be flexible and ready to do everything (within your domain) Obviously, we can’t do everything in life — no superpowers here. By “everything” I mean being willing to do the range of tasks inside your domain, or to stretch when you need to. Short quotes can be misleading or leave out nuance; everyone interprets them differently.

To me, anyone who plans and studies before committing is an engineer. Maybe someone plans a two-acre banana plantation — that’s engineering too. As a software engineer, you should be flexible: one day you might work on an ML project, another day on a Java app. It’s easy to say “I don’t know X,” and I’ve felt that way. But often, teams don’t expect you to finish everything instantly — they want support and willingness to learn. That’s your chance to pick up something new. And it ties back to the first point: love what you do — it makes learning easier. If you can opt out, that’s fine too; sometimes it’s better to stick to what you know.

Where I work, I saw senior devs jumping between projects: Java, JavaScript, Kotlin, and so on. I wondered how they were so productive. Once I asked one of them how they managed multiple languages. His answer stuck with me:

“Programming languages are just tools. I worked in Java for 3+ years — that taught me how languages are structured. A few weeks ago I joined a Kotlin team. I didn’t know Kotlin, but I started working on it. It felt like a mix of Java and JavaScript. You can always look up syntax and get moving. The syntax takes a little time, but the concepts carry over.”

That made me think. Once you learn one language well, switching to another becomes much easier — it’s like speaking your mother tongue and learning a foreign language: the idea is the same, only the words differ. Programming is largely English-like; once you learn the patterns, learning syntax is the remaining step. Frameworks of course have their own curves, but flexibility as an engineer is real and valuable.

You’re always learning

This is the takeaway. Find enjoyment in whatever you do, and pause sometimes to notice what you’ve learned after a few days or hours of work. Appreciate those small wins. Admitting you don’t know something opens the door to getting better — opportunities will follow if you’re willing. At the end of the day, take things easy and slow. Don’t push yourself into burnout. That matters more than productivity metrics.

As always, send your suggestions, opinions - [email protected]

All right! A pleasent week is coming up. Do your best guys!

Remember, you’re awesome!