I was pursuing my engineering in Mechanical when I realized it wasn't my thing. I dropped out. I wanted to pursue a career in psychology. I started following Paul Ekman and the science of lie detection. At some point, I realized that micro-expressions last for 1/25th of a second on face, and it's difficult for humans to catch these to detect deception. That is the first time I wondered if I should learn programming to see if this could be automated. Fast forward, I started working as a web developer to meet expenses. During this job, training became a regular part of life. Problem-solving became my go-to fun activity. New framework hypes do not fascinate me. I love the good old fundamentals of how networks work, how operating systems work, design patterns, and the etymology of CS jargon. I've been inspired by software junkies like Martin Fowler, Kent Beck, Bredent Gregg, and countless others. Patterns of Enterprise Application Architecture, Linux system programming, High-performance MySQL, System performance by Bredden Gregg, Crafting Interpreters, Engineering at Google, and many more such wonderful books have given me the ability to enjoy software engineering. Naturally, I love talking about things like: 1. How do you approach performance issues? Where do you begin, and how do you use tooling (or build some)? 2. How do you avoid bugs with static analysis? (I feel, ALL bugs are communication gaps.) 3. Why all frameworks should ship with advanced code generators? Only frameworks can do this right. After all, a framework is a bunch of conventions (I'm oversimplifying this!) I've been able to leverage this knowledge to: 1. Reduce infra costs by 53% at my current workplace. 2. Design exercises for fellow engineers to be better debuggers. 3. Reduce operational costs by developing tools that reduce toil.