Progression in mindset of a developer trough professional life:

1. I'm going to make my code so efficient and beautiful that everyone will envy it!

2. I'm going to make sure I keep separation of concern.

3. I'm going to make my code at least maintainable for other developers.

4. Well shit. At least it works, for now.

A fight story (separation of concern) : work vs life

IT Director (IT'D) forwarded a client message (false detection) to my whatsapp (personal number). I am sitting next to his cabin.

After an hour,

ITD : what was the issue with the client x?
Me : (proved false detection),
ITD : did you emailed client?

Me : no, don't send me these in WhatsApp, if any issues, email me since I won't check whatsapp and there is no guarantee that I will reply you back.

ITD : why, don't be negative. Either you have to or me have to do it.

Me : Tell them to email.
ITD : That is not right.

Me : I don't care if you provide support via WhatsApp. But I don't. Unless you provide a separate mobile and connection.

End of story.

Things I hate the most at the moment:
- PHP
- jQuery
- The person that coded this before me
- The fact that this person is swtiching from jQuery and native javascript over and over for no f*cking reason. Just why?
- My job
- My boss
- The big pile of sh*it that this code is (overall not just the screenshot), no separation of concern, logic code in the middle of the file, no proper slacing and indentation
- devRant no allowing me to put multiple images in one post, because the picture is just one of this whole mess, it's not even the worst part, you'd have nightmare if I showed it to you
- The mental breakdown I'm having

# Retrospective as Backend engineer

Once upon a time, I was rejected by a startup who tries to snag me from another company that I was working with.
They are looking for Senior / Supervisor level backend engineer and my profile looks like a fit for them.
So they contacted me, arranged a technical test, system design test, and interview with their lead backend engineer who also happens to be co-founder of the startup.

## The Interview

As usual, they asked me what are my contribution to previous workplace.
I answered them with achievements that I think are the best for each company that I worked with, and how to technologically achieve them.

One of it includes designing and implementing a `CQRS+ES` system in the backend.
With complete capability of what I `brag` as `Time Machine` through replaying event.

## The Rejection

And of course I was rejected by the startup, maybe specifically by the co-founder. As I asked around on the reason of rejection from an insider.

They insisted I am a guy who overengineer thing that are not needed, by doing `CQRS+ES`, and only suitable for RND, non-production stuffs.

Nobody needs that kind of `Time Machine`.

## Ironically

After switching jobs (to another company), becoming fullstack developer, learning about react and redux.
I can reflect back on this past experience and say this:

The same company that says `CQRS+ES` is an over engineering, also uses `React+Redux`.
Never did they realize the concept behind `React+Redux` is very similar to `CQRS+ES`.

- Separation of concern
- CQRS: `Command` is separated from `Query`
- Redux: Side effect / `Action` in `Thunk` separated from the presentation
- Managing State of Application
- ES: Through sequence of `Event` produced by `Command`
- Redux: Through action data produced / dispatched by `Action`
- Replayability
- ES: Through replaying `Event` into the `Applier`
- Redux: Through replay `Action` which trigger dispatch to `Reducer`

---

The same company that says `CQRS` is an over engineering also uses `ElasticSearch+MySQL`.
Never did they realize they are separating `WRITE` database into `MySQL` as their `Single Source Of Truth`, and `READ` database into `ElasticSearch` is also inline with `CQRS` principle.

## Value as Backend Engineer

It's a sad days as Backend Engineer these days. At least in the country I live in.
Seems like being a backend engineer is often under-appreciated.
Company (or people) seems to think of backend engineer is the guy who ONLY makes `CRUD` API endpoint to database.

- I've heard from Fullstack engineer who comes from React background complains about Backend engineers have it easy by only doing CRUD without having to worry about application.
- The same guy fails when given task in Backend to make a simple round-robin ticketing system.
- I've seen company who only hires Fullstack engineer with strong Frontend experience, fails to have basic understanding of how SQL Transaction and Connection Pool works.
- I've seen company Fullstack engineer relies on ORM to do super complex query instead of writing proper SQL, and prefer to translate SQL into ORM query language.
- I've seen company Fullstack engineer with strong React background brags about Uncle Bob clean code but fail to know on how to do basic dependency injection.
- I've heard company who made webapp criticize my way of handling `session` through http secure cookie. Saying it's a bad practice and better to use local storage. Despite my argument of `secure` in the cookie and ability to control cookie via backend.

Today I think it became apparent why we have so many data and prod issues...

No one understands SOLID design principals... Particularly Separation of Concern. No wonder all the Spring (DI) modules look like a mess of God functions that are impossible to reuse and difficult to extend...

A React dev in our company proudly announced a script they built for handling data processing of over 200 lines of code, no separation of concern, and all responsibilities mixed together in a large cocktail of bullshit.

Thank our servers, it's Wednesday!

What's your thoughts on stored procedures(of DBs)?
What are the pros and the cost you found or perceived?
When they are opportune?
Overusing them more than a programming language is an abuse?

I was introduced to a software started initially by economy\finance people which knew a little bit programming, nonetheless their doing became messy though time and at a certain point hired a team of 4 people(from my company) to deal with it, but the approach of the two programmers to build most of the framework on calling stored procedures or queries makes me want to puke, there are almost no layers of separation of concern in place x_x

Why is everyone saying we should be doing DRY but we really end up defining the same shit everywhere?

Does separation of concern breach DRY principle?

I have dtos, entities, viewmodels all throughout different layers I have to define. I swear I've changed 8 files just to introduce a new field!!!

Started doing CakePHP because of a project I’m taking over. What in the world is that? Dependency injection? Separation of concern? Single responsibility? What did I get myself into…

we were taught separation of concern when getting into webdev, don't write html inside your js codebase, don't write js inside html code base, don't write css inside your js codebase. People who taught us this, are violating this same principles by introducing stupid frameworks.

Today I deeply understood/learned that if anything complex has to be built, tested and maintained by a single person the most important factor to don't go crazy is the concepts of "separation of concern".

Even though it makes the development slower (*) and quite some times boring it gives back in almost absence of uncertainty and because of repetitive patterns also ease on going back to work on a new/old part/feature.

(*) Because of planning and organisation of the code flows and layers flows, but also compartmentalization of actions (a bad example would be the mix of validation code with CRUD code)

How do you experience the separation of concern? (If you have ever had the chance)

Ps: still earning ~1400€/m, am I worth more? 🤔