Thinking in tech

How I learned to design software

I sat in my reading chair yesterday reading a book and thought about a new feature for a SaaS I’m building over weekends.

I saw a mental image of all data structures, endpoints, and a slightly fuzzy state structure for React components in a split second. No drawing, no diagramming; I had a solution straight away. I could begin coding right there and now.

It reminded me of how I learned English as my second language 10 years ago.

The breaking point was when I began to think in English.

Engineers are translators

Building software isn’t much different from being a translator.

I visited my auntie in Poland a few years ago with my ex. My auntie didn’t know a word in English, and my ex didn’t know a word in Polish. I was the translator, allowing them to talk to each other, which would have been impossible otherwise.

As an engineer, I gather words told and written by stakeholders and translate them into a language that computers understand, from flesh and blood to silicon and electricity. It’s my job to ensure that the code I write reflects well what I’ve been told business needs. Without engineers, it wouldn’t have been possible, or at least it would have been horribly inefficient.

Engineers are translators.

Engineers think in tech

Business is a collection of people — leaders, managers, workers.

Each position succeeds through a different way of thinking and effective communication. When a CTO thinks like an engineer, the company will need help, and when engineers think like CTOs, they will get in trouble. The structure exists for everyone to excel at what they know best.

1. CEO thinks in general strategy

2. CTO thinks in technical strategy

3. COO thinks in operations strategy

4. Head of engineering thinks in department efficiency

5. Team Leaders think in their team's efficiency

6. Engineer thinks in the tech they build

Running a business is too complex for one person to handle. There are 100 (probably more) specialisations. Some think about business, some think about customers, and some think about getting bananas for Thursday.

Engineers think in tech.

Practice enables thinking

It took me 3-4 years in London to begin thinking in English.

At that time, I first thought about my sentence in Polish, then translated it into English in my mind before I could speak. Because of that, my grammar wasn’t good, and I often used Polish grammar. I could hear how bad it sounded.

But what does it have to do with tech? You may ask.

Engineers-translators face the same challenge of flawed grammar.

You see it when features are implemented precisely as described, ignoring the fact that software design rules differ from spoken English (or any language you communicate with). This leads to crude designs and teams waking up one day with a terrible “ball of mud” in their editors. They write programs in spoken language grammar.

How do you begin thinking in tech?

Thinking in English took me years of speaking in English.

Thinking in tech takes speaking tech. You do this by creating software. The magic trick is to learn the basics and balance coding with thinking.

My preferred way of thinking initially involved a pencil and 500 sheets of printing paper. I picked a problem that interested me and tried to solve it by drawing classes, methods and how they can communicate. Drawing is 10x quicker than coding.

Next, I implemented the best design I could. Often, it wasn’t as great as I thought, and implementation proved me wrong. This was good because I discovered a design that didn’t work.

Do it intentionally for 3 years, and you’ll see the results.

Note the goal is to create the best design. You want to limit-test your understanding of software architecture. The value is in the process, not the result itself.

Practice enables thinking.

Thinking in tech

Hello, I’m Dariusz, and I had a break from writing a newsletter for about a year now.

I believe there are no silver bullets or magic pills in engineering. Every business has unique issues, and no one solution fits all. AI and ever-growing tech doesn’t make it easier.

In 2025 (and beyond), software engineering needs more (Critical) Thinking in Tech.

This post marks the end of Code.Lead.Succeed. Next week, you’ll hear from me in the Thinking in Tech Newsletter.

Have a great weekend, Thinkers!