Daniel Moka

interview prep VS the actual job

If you look at your application and you only see folders like these:

❌
📁 App
|__ 📁API
|__ 📁Models
|__ 📁Views
|__ 📁Controllers
|__ 📁DTOs
|__ 📁Database
|__ ...

Then your app does not tell anything about the problem it solves.

It is driven by technology instead of the domain.

If you want to add a new feature you would need to add files to all these places.

Features are mixed, leading to maintenance hell.

Now look at this folder structure:

✅
📁 CarRentalService
|__ 📁AutoPicker
|__ 📁UserManager
|__ 📁PaymentProcessor
|__ 📁InvoiceGenerator
|__ 📁SupportCenter
|__ ...

It is called screaming architecture. It screams the domain.

It is easy to navigate, with clear domain separations.

If you want to add a new feature, you just add a new main directory.

It has better discoverability, and results in low entry curve for new developers.

A clean folder structure is like a well-organized room; everything has its place, and it's easy to find what you need.

Your folder structure should communicate the domain, not the technology.

--------

PS: If you liked this post, you will love my FREE newsletter.

Subscribe here: craftbettersoftware.com

You are not paid to write code.

You are paid to solve problems.

Half of the solution is understanding the problem.

When it comes to producing quality software, you need to focus on two things:

- doing the right thing
- doing the thing right

In this particular order.

You are not paid to write code.

You are paid to solve problems.

Half of the solution is understanding the problem.

When it comes to producing quality software, you need to focus on two things:

- doing the right thing
- doing the thing right

In this particular order.

Writing bad code feels fast. But it's an illusion.

The cost of writing bad code might be cheaper in the beginning.

But over time, it slows you down more and more, making it worth the effort to write clean code.

Quality costs less. Invest in quality today, win time tomorrow.

Too real

Many software engineering teams don't have time to do it right.

But surprisingly, they have time to do it twice.

CI is NOT a build server.

TDD is NOT equal to testing.

DevOps is NOT a role in a team.

Code coverage is NOT a quality metric.

Rewriting is NOT the same as refactoring.

Using feature branches is NOT a best practice.

Software engineering is NOT only about coding.

While most developers think otherwise, we shouldn't be surprised by all the low-quality software products

By changing these beliefs, we can create better software.

Programming is 98% thinking and 2% typing.

True skills involve planning, problem-solving, and creativity before your fingers hit the keyboard.

Start with understanding the problem domain.

Think first, code second.

Your best work comes from your thoughts, not from your keystrokes.

If I interview you, I don't care which language or framework you use.

All I care is:
• how you treat people
• if you have a broad interest, and empathy for others
• your curiosity to learn whatever it takes to solve customer problems

If you are good at these, you are hired as we can teach you everything else.

But unfortunately, we can't teach a jerk not to be a jerk.

A developer should never ask permission for:

• writing clean code
• refactoring the code
• documenting the code
• writing automated tests

They should be mandatory tasks for every developer.

Producing well-designed code is our territory, and the management should have nothing to say about it.

We should do these as a part of being good software professionals.

The daily standup is NOT a status meeting!

It's a planning meeting and our most important task is to talk about blockers.

It should never be used to report to anyone. It's for the team, by the team, and not for the managers.

Every developer must be a tester.

Most QA teams would disappear if devs followed a good testing strategy.

Pushing testing to another team shows a lack of responsibility.

"It's fine, our testers will test it" - they say.

It's time for developers to grow up and take ownership of the quality of their work.

QA is not a separate team. It's part of your team. It includes QA experts who help achieve high-quality culture.

Quality is not something that you fix at the end.

It is something that you build in from day one.

---

Join 35,000+ software crafters to learn AI: craftbettersoftware.com

Seniors can learn a lot from junior developers.

Juniors have a beginner's mindset.

They constantly ask questions and challenge the foundations.

As you gain more experience, the danger increases.

The feelings of expertise can lead you to be dogmatic against new ideas, resulting in less efficient software solutions.

That's why you should always ask the WHY, question everything, and approach your tasks with a beginner's mindset.

The first rule of microservices: Never start with microservices.

People want to scale like Netflix before even getting 10 users.

Kubernetes is cool, but unnecessary complexity for most.

Start with a monolith instead.

It’s faster to build. Cheaper to run. Easier to reason about.

Most your “microservices” could be just a function inside one well-structured app.

Don’t chase hype.
Ship value.

Then scale with microservices only if needed.

"We used to write all code by hand"

I can finally see my tailwind classes without scrolling

Career tip: You don’t need much to be a great developer.

Not a CS degree.
Not a $2500 MacBook.
Not 3 monitors, 5 coffees a day, or 12-hour workdays.

You also don't need to work at FAANG companies.

Here’s what you actually need:

• An average laptop
• A love for learning
• And the drive to get a little better every day

That’s it.

Everything else is noise.

Clean Code tip: Write clean commit messages

It’s the best tool to document the reason for change in your code.

Here are 5 tips on how I write commits in my team:

1. Explain the WHY

❌ Add endpoint
✅ Add endpoint to enable users to download purchase history

2. Summarize WHAT the commit does, not HOW it does it:

❌ Changed the button color by updating CSS file
✅ Update primary button color for better contrast

3. Use present tense with imperative mood

❌ I have removed
✅ Remove ...

4. Add link reference to the actual work item

❌ Fix login bug when user is inactive
✅ d342da: Fix login bug when user is inactive

5. Don’t include file names - they are in the Git details
❌ Update dependencies in package.json
✅ Update dependencies to address security vulnerabilities

Clean commit messages are part of internal software quality.

For more GIT best practices, check out my FREE newsletter: craftbettersoftware.com

Rate my new keyboard

GitTub

A good software architect writes code.

There is nothing worse than an architect who hasn't opened a code editor in years.

They are called ivory-tower architects. It is a red flag.

Knowing how to implement solutions with recent technologies is essential to develop a good design.

A good architect works closely with the team to create a design that maximizes productivity and efficiently solves the problem domain.

---

Join 35,000+ software crafters: craftbettersoftware.com

If Bilbo asked ChatGPT

A senior developer in one stack might be a junior in many others.

But their expertise is not defined by their stack.

It is defined by their language-agnostic mindset.

A mindset that is transferable across all languages and frameworks.

If someone develops this mindset, picking up a new language or framework takes only a couple of weeks.