## 4 years ago:
- Principal Architect: We are using IO1 storage type. What if we used GP2?
- Perf team: IDK, let's test it!
*we run tests*
- Perf team: results are OK, but we're exhausting Burst IO capacity, effectively hard-limiting number of tests we can run per day
- PArch: ahhh, I see. Then Gp2 is a no-go.

## 3 years ago
*PArch quits. New one is hired*
- PArch2: We are using IO1 storage type. What if we used GP2?
- Perf team: We've already tested that a while ago, results were THIS and THAT
- PArch2: I see. Let's test it again anyway
- Perf team: *wtf???*
*we run the same tests, we get the same results*
- PArch2: I see, so GP2 is a no-go.
- Perf team: *you think....? How did that thought never cross our minds, we wonder...*

## 2 years ago
*new DBA is hired*
- DBA2: We are using IO1 storage type. What if we used GP2?
- Perf team: We've already tested that a while ago, results were THIS and THAT
- PArch2: We've already tested that a while ago, results were THIS and THAT
- DBA2: I see. Let's test it anyways. I've read somewhere that GP2 might be a better bet
- PArch2: you might be right, let's do that
- Perf team: *wtf???*
*we run the same tests, we get the same results*
- DBA2: I see, so GP2 is a no-go.
- Perf team: *you think....? How did that thought never cross our minds, we wonder...*

## 1 year ago
*DBA manager left; new one was hired*
- MGMT_dba2: We are using IO1 storage type. What if we used GP2?
- ........

Should we even bother bringing up the history.....?

Yepp.. The older you get, the faster the time flies by. Remember how long days used to be when you were 10? How much you used to do then? And now? You barely skim through your emails and it's already lunch time.. And soon after that it's already time to go home, go to sleep. And the next day is the same. Round robin, round robin... And when you think that the pooft-you're-gone moment is approaching faster and faster every year, you wonder what are you leaving behind, to remember you by.. A few dev projects that will drown to oblivion a few years after you're out, a few modules in other projects that will live longer but your code lines will soon be overwritten and forgotten in git's history, where noone ever scrolls to. Your own projects you have never released. Your fam who will remember you until their grandchildren - after that older generations are forgotten...

What is it that will keep people saying your name after you're gone? What significant have you given to the life?

This is getting annoying.

For the past >half a year I've been chasing windmills. This is what my BAU day looks like:

- We login to client's network
- We start running some Sanity tests before the actual runs (actual runs are hell of an expensive (financially and time-wise) thing to launch) to make sure environment is OK.
- Sanity tests fail. wtf? Nothing's been changed since y-day!
- Spend ~3-4 hours digging logs, code, more logs,... Apparently some genius decided to change a single parameter.
- Spend another 1-2 hours trying to work around that parameter (since apparently that genius did have a task to do that, so we'll most likely have to find a way to live with it)
- Restart the whole env (~30min).
- Launch a Smoke, Sanity tests to verify env state.
- Launch the actual test
- Go home.

Next day:
- We login to client's network
- We start running some Sanity tests before the actual runs to make sure environment is OK.
- Sanity tests pass.
- Run the actual test
- Concurrency on RDS database is sky-rocketing! WTF did that come from??? Nothing's been changed since y-day!!
- Spend ~1-2 hours looking for anything changed, dig some logs for anything unusual. Nothing.
- Escalate to DBA. 2 hours later DBA says "fix the app". thanks for nothing mate....
- Spend remaining 2 hours analysing AWR. Give up, restart the whole RDS instance. Another hour wasted.
- Time to go home. Out of curiosity run Sanity test -- all good. Run the actual test -- all good. wtf??
- Go home

Next day
- We login to client's network
- We start running some Sanity tests before the actual runs to make sure environment is OK.
- Sanity tests fail. wtf? Nothing's been changed since y-day!
- Spend ~3-4 hours digging logs, code, more logs,... Apparently some genius decided to change a single parameter.
- Spend another 1-2 hours trying to work around that parameter
- ..... I think you know where this is going.

And this keeps going on and on, day by day. Spending the better half of the day chasing windmills and doing our actual work on the last hour of the working day or even after that.

We have plenty of interesting tasks in our Jira but we're squirels spinning in the wheel and never being able to touch them.

It feels like I'm wasting my time. I could do so much more with my time!

[just needed to vent ]

Phone call with customers and their minutes-of-meeting writer.
Me: Blabla round robin algorithm.
Customer's MoM writer: What? How do you spell "robin"?
Me: Robin like in Batman.
Customer's MoM writer: Ah, ok.

# 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.

So happy about being about to convince management that we needed a large refactor, due to requirements change, and since the code architecture from the beginning had boundaries built before knowing all the requirements...

pulled the shame on us, this is a learning lesson card.. blah blah blah

Also explained we need to implement an RTOS, and make the system event driven... which then a stupid programmer said you mean interrupt driven ... and management lost their minds... ( bad memories of poorly executed interrupts in the past).... had to bring everyone back down to earth.. explained yes it’s interrupt driven, but interrupt driven properly unlike in the past (prior to me)... the fuck didn’t properly prioritize the interrupts and did WAYYY too much in the interrupts.

Explained we will be implementing interrupts along side DMA, and literally no message could be lost in normal execution.. and explained polling the old way along side no RTOS, Wastes power, CPU resources and throws timing off.

Same fucker spoke up and said how the fuck You supposed to do timing, all the timing will be further off... I said wrong, in this system .. unlike yours, this is discreet timing potential and accurate as fuck... unlike your round robin while loop of death.

Anyway they gave me 3 weeks.. and the system out performs, and is more power efficient than the older model.

The interrupting developer, now gives me way more respect...

Allrighty, so we have a huge migration upcoming. The planning started early this spring. We've split the whole process into separate tasks and estimated each of them. Also marked all the tasks client should take care of itself so save funds and time. All-in-all the whole thing estimated like 4 months if we did it [single dev, tremendous amounts of communication with various parties, buy and prepare the infra, adapt app to the changes, testing, monitoring, etc.] and like a month if client did the tasks we shouldn't be doing. The funding for migration is time-bound and can only be used before December. Cool! We got notified that by the end of April we should be good to go! Plenty of time to do things right!

April comes. Silence. Mid-april we resch out to the client. Since there's plenty of time left migration is getting lower priority to other tasks. Well allright, sort of makes sense. We should migrate mid-July. Cool!

July comes. Client replies that everyone's on vacation now. Gotta wait for August - will do the quicker version of migration to make it on time. Well allright....

August comes. Everyone's vusy with whatever they've postponed during summer. Hopefully we'll start migration in September. Mhm...

September comes. We're invited to a meeting by project funders to explain tasks' breakdown, justify the time needed to make the migration. We're being blamed for surreal estimations and poor organization of tasks as nothing's happened yet... [they were the ones who always were postponing things....]. Moreover, they can only spare 20% of infra resources required for data alone anf they want us to make that enough for all environments, all components, all backups, all databases,... You get the pic.
The leader of the meeting semi silently mumbled to other participants 'Well then I'm afrsid we can't make a full migration in time.. Only partial. That's very unfortunate, very. That's why we should not have incopetent vendors [*glancing at us*]'

somehow we agreed we'll get the resources mid-November and we should be thankful for him bcz he'll have to pull some strings for... us..

I left the meeting with my fists squeezed so hard! But it's okay, we got smth useful: resources and start date. Although it leaves us with less than a month to do smth requiring a month for a sunny-day scenario. Nvm, still doable.

Last week we get an email that resources will be available at the beginning of December [after deadline] and we should start a full migration no sooner than Nov 12. Which leaves us with 50% of our estimated fucking optimistic scenario time and not enough resources to even move a single db.

Fuck I hate politics in dev... Is it wrong for me to want to tie them to a pole, set them on a veeery slow fire and take a piss on them while they're screaming their shitty lungs out? I'd enjoy the view and the scream. I know I would. And while enjoying I might be tempted to take a burning 20cm diameter wooden stick and shove it up their assholes. Repeatedly. Round-robin. Promissing them I'll take it out in 5 seconds and pulling it out after 2 minutes.

Can I?

I called the hack "blow up bunny", was in my first company.

We had 4 industrial printers which usually got fed by PHP / IPP to generate invoices / picking lists / ...

The dilemma started with inventory - we didn't have time to prepar due to a severe influenza going round (my team of 5 was down to 2 persons, where on was stuck with trying to maintain order. Overall I guess more than 40 % ill, of roughly 70 persons...)

Inventory was the kind of ultimate death process. Since the company sold mobile accessoires and other - small - stuff.

Small is the important word here....

Over 10 000 items were usually in stock.

Everything needed to be counted if open or (if closed) at least registered.

The dev task was to generate PDFs with SKUs and prefilled information to prevent disaster.

The problem wasn't printing.

The problem was time and size.

To generate lists for > 10 000 articles, matching SKUs, segmented by number of teams isn't fun.

To print it even less. Especially since printers can and will fail - if you send nonstop, there is a high chance that the printer get's stuck since the printers command buffer get's cranky and so on.

It was my longest working day: 18 hours.

In the end "Blow up bunny" did something incredibly stupid: It was a not so trivial bash pipeline which "blew up" the large PDF in a max of 5 pages, sent it to one of the 4 printers in round robin fashion.

After a max of 4 iterations, bunny was called.

"bunny" was the fun part.

Via IPP you can of course watch the printer queue.

So...

Check if queue was empty, start next round with determined empty printer queues.

Not so easy already. But due to the amount of pages this could fail too.

This was the moment where my brain suddenly got stuck aft 4 o clock in the morning in a very dark and spookey empty company - what if the printer get's stuck? I could send an reset queue or stuff like that, but all in all - dead is dead. Paper Jam is paper jam.

So... I just added all cups servers to the curl list of bunny.

Yes. I printed on all > 50 printers on 4 beefy CUPS servers in the whole company.

It worked.

People were pretty pissed since collecting them was a pita... But it worked.

And in less than 2 hours, which I would have never believed (cannot remember the previous time or number of pages...)

Ideas I've had over the years that could pan out and be useful:

SMS-DB: Stands for SMS-Data Burst. Used to allow those with low cell signal or no data plan to transfer data between a phone and some client via the standard SMS text space. Would be slow, but would act kinda like dial-up over SMS (as mobile lines are compressed on all service levels, even LTE, so traditional dial-up wouldn't work!) I have a general idea on how packets would be laid out, but that's about it so far...

everything2PNG: Allows one to transpose any file's data into a PNG with a 3 byte per pixel (full color RGB), which allows for a "compression" of sorts (about 91, 93% on preliminary tests) AND allowing further, more efficient compression of the resulting file. (Plus... it's just kinda cool to see files transposed as PNGs.) I actually have a simple transposer to go to PNG, but can't yet go back. Large files (around 600MB) use upwards of 4GB with efficient paging and other optimizations via NumPy so far, so it's not *viable* yet, but it's coming along nicely.

RPi-GPIO Interconnection Bus: A master/slave or round robin method to allow for Raspberry Pis to communicate using GPIO, which can help free up network bandwidth in RPi cloud computing clusters. At most, this'd allow for 4 bits used for pushing to the GPIO "bus", and 4 bits used for pulling from the "bus". 8 pins total are usually unused minimum, so either 3 or 4 pins for upload, 3 or 4 for download, and potentially 1 or 2 for commands, general non-data communication, etc. I made a version of this concept using Round Robin for a client, but it was horribly slow. (I also don't have distribution rights for the code, so i'm working from scratch.) Definitely doable.