HH

Think like an Architect

[HH @JustifiedCode]

Hello hello, i made some changes to JustifiedCode recently. I wanted it to become a place where experienced developers moving toward senior and architect roles can follow a clear path.👇

[HH @JustifiedCode]

Design and architecture decisions are also financial decisions.

[HH @JustifiedCode]

We have a way to deal with tech dept with ai assisted development. Now, we have to deal with cognitive dept or more precisely cognitive surrender.

https://t.co/oqzm6OqRmR

[Seb @plainionist]

With coding agents, everyone can now observe live
the effects of technical debt:

If there is no proper architecture,
no clear boundaries,
no clear responsibilities,

agents start running in circles,
and features take longer. 🤷‍♂️

[HH @JustifiedCode]

Going back to the foundations

[Fernando @Franc0Fernand0]

It's always surprising how Program, Process, and Thread get mixed up.

Here is a simple breakdown that makes everything clear:

1. 𝐏𝐫𝐨𝐠𝐫𝐚𝐦

It is a file saved on a disk that contains a collection of instructions.

A program can start several processes.

Firefox, for instance, starts a new process for plugins.

2. 𝐏𝐫𝐨𝐜𝐞𝐬𝐬

It is a program that is executed.

A program turns into a process when it is loaded into memory and run.

The program counter, stack, and registers are among the resources a process needs to operate.

3. 𝐓𝐡𝐫𝐞𝐚𝐝

A Thread is the smallest execution unit that runs in a process.

A process can run many threads.

For example, a browser runs more than one thread at the same time.

A thread loads content, while others display animations, play videos, and so on.

There are 5 main differences between processes and threads:

- Processes are independent; threads exist as parts of a process

- Each process has its own memory space, while threads that are part of the same process share memory.

- Context switching between processes is more expensive.

- Inter-thread communication is faster than inter-process communication.

- The process of creating and ending a thread is lighter and faster.

[HH @JustifiedCode]

Attempting to divide a cohesive module would only result in increased coupling and decreased readability. —Larry constantine

[HH @JustifiedCode]

Data is a precious thing and will last longer than the systems themselves. —Tim Berners-Lee

[HH @JustifiedCode]

“Don’t strive to find the best design in software architecture; instead, strive for the least worst combination of trade-offs.”@neal4d

[HH @JustifiedCode]

@Franc0Fernand0 Then we get cream de la cream 🙏

[HH @JustifiedCode]

@plainionist Is this part of the shift left thing? 🤔

[HH @JustifiedCode]

@Franc0Fernand0 I miss that voice :)

[HH @JustifiedCode]

Systems Thinking path: The path I wish someone had laid out for me years ago. System design patterns, modernization, reliability, scalability, and putting the pieces together in real systems.
🥂https://t.co/IwRCocTyWz

[HH @JustifiedCode]

Hello hello, i made some changes to JustifiedCode recently. I wanted it to become a place where experienced developers moving toward senior and architect roles can follow a clear path.👇

[HH @JustifiedCode]

Foundations path: If I were starting today, this is where I would start. Code structure, Hexagonal Architecture, Clean Architecture, and refactoring.
🍻https://t.co/WmCWevcaZY

[HH @JustifiedCode]

@alexbunardzic They feel you

[HH @JustifiedCode]

@Franc0Fernand0 The problem is we don’t stand anymore 😂

[Fernando @Franc0Fernand0]

There's a difference between knowing how a system works and understanding why it was built that way.

The first you can get from a diagram in 30 seconds. The second takes real time, and it's the only one that lasts.

Most technical content today sells you the first one. You read that a database uses an LSM tree, nod, and move on. Two weeks later it's gone, because you never learned what problem the LSM tree was solving in the first place.

The engineers I trust most learned it the slow way.

They didn't remember that writes go to a log first. They knew that random writes are bad for disks, so they need to be converted into sequential writes and paid later on through compaction. Now they can trace the entire design back to that one trade-off, years later.

That's the difference. Facts you memorize decay. A tradeoff you understand stays with you and transfers. The moment you hit a new system, you already know which questions to ask.

It's slower to learn this way. It's also the only way I know that compounds.

That's why I write @EngPolymathic the way I do. From the ground up, tradeoffs first, no shortcuts.

[Fernando @Franc0Fernand0]

The best engineers I've met all shared one trait:

They knew a little about a lot of things.

Not experts in everything, but they had working mental models of databases, protocols, design choices, and how different systems solve problems.

This kind of breadth didn't come from their day job. They were always interested in new things, so they read articles, watched talks, and looked into interesting topics when it wasn't related to their current work.

The payoff is huge. When you've seen how a lot of different systems solve their problems, you start drawing parallels and connecting dots other people can't. That's where out-of-the-box solutions actually come from.

And it doesn't take all your weekends. 30 minutes every weekday, on something you genuinely find interesting, is enough to become a much better engineer.

The hard part isn't the time. It's the consistency. But once it becomes a habit, complex topics stop feeling intimidating, and you find yourself navigating the whole landscape with ease.

[Fernando @Franc0Fernand0]

Most engineers learn system design by memorizing diagrams for the interview.

The moment the question changes, it all falls apart.

Here are the 12 topics I wish I had learned first to truly understand how large systems work, one per week (bookmark this): ↓