I sat with my dad for coffee this morning. Told him I’m about to finish this series today, which I did. He wondered what’s my gain from this. I told him that I don’t expect people to actually read it, but at the very least it brings an order to my thoughts, making it easier for me to share and teach. “Share and teach what exactly?” he asked. “If I’ve done this right”, I said, “and it’s a big if, I’ve shed a light on the process of software engineering through the perspective of a process/industrial engineer”. “One day”, I continued, “I hope it will help anyone who reads it, no matter who it is. Because there is a lot of time wasted to save”.
I started writing this series back in May 2020, when I was under the first Covid lockdown. It was named “Applicative Evolution”. I stopped around August 2020 when I got a new job at RapidAPI as a Group Manager. About a year or so later, I decided to take a break from work. I was over burned and needed time off in order to keep doing what I love to do in the future, something called “my career”. And in order to keep myself busy, I went back to writing my book/blog which I enjoy so much.
So I was back to this series in November 2021. Re-read what I wrote in May 2020.. And I hated it. It was an incoherent mess to me and I was emotionally detached from it. As the last piece was about refactoring.. I thought maybe I need to stop refactoring it. I threw it all away and started from scratch. This time with a different goal and tool in mind: explaining the evolution process through the aspect of time itself. My tools were a coherent Event Stream, State Machines and the Change Event. That’s where the section name “The Change Factor” came from.
About a month and a half afterwards I finished its first draft along with the first draft of the next series. I started editing it and saw there was no point to it. Although it might be insightful to read, it was not a beneficial enough series. It was missing a reason for anyone to care about these processes. Then something funny happened. Something funny always happens to me.
I’ve got a few friends down at the dog park, fellow software engineers. We were talking about these evolutionary processes and one said “Sounds to me like you’re documenting the obvious!”. I laughed my heart out. “But”, he continued, “isn’t it a waste of time?”. He referred to my work as a waste, so I asked if he has ever read the obvious somewhere. He didn’t, which turned this into the greatest compliment ever. I love documenting the obvious, maybe even loving being called that. It also turned out, he gave me an epiphany: to write on the causes and consequences of these processes, in the form of time wasted. Inefficiencies. And I do have plenty of actual experience resolving the issues I was writing about. I do know first hand of it.
On the contrary, I was avoiding writing “a how to guide”. Although I do have some experience, my actions are not one size fits all, as there is no such. What I did was correct for the time and place, but does not guarantee it to be a fitting solution to the reader or his workplace. Instead, I’ve decided to leverage what I’ve done as an example of consequences for removal of inefficiencies. I had to describe my actions, but did not deep dive into it (mostly because it came out boring). I leave it up to the reader to decide whether an action is needed and what the action should be. As you, the reader, know best.
With these in mind, I rewrote some of the chapters and restructured them. One chapter describes an evolution process, another the waste it causes and the third is what happens when you overcome the waste. After another month, about 10-15 hours weekly, I was done with it.
I hope you enjoyed this series as much as I loved the journey of writing it.