You know that meme where a guy asks a genie to grant his wish, and the genie's sole purpose is to twist that wish to make him miserable? Like he wishes for $1 million and gets it, but inflation is 300,000,000% so he can't even afford bubble gum with it.
After a month of experience with vibe/AI-augmented coding, I have a similar feeling.
I built my own split ergonomic keyboard from scratch and watched my typing speed plummet. Through 3D printing failures, soldering mishaps, and firmware battles, I discovered a new hobby. Despite struggling to type at 25% of my normal speed, I've created something that feels uniqu mine – and now I can't wait to build another one.
A chance encounter at the airport leads to insights into the real nature of technical debt in software development. Through the lens of Stoic philosophy and Lord of the Rings metaphors, this post explores how better communication between engineers and management can prevent our own Mines of Moria situations. Practical tips included for both technical leads and managers on how to discuss, document, and decide which technical dragons are worth slaying.
I had several chances to try a few ways of multiplatform software development. However, I was curious about the Kotlin Compose Multiplatform way. So I could use the technology I already know to build Android, desktop, and iOS apps, sharing internal logic, and UI elements. How hard can it be?
'I did not study computer science to work with people’—sounds familiar? Well, I’ve got news for you: you’re still working with people, you just communicate not in the way you might think. Your code speaks volumes about your intentions and ideas. Design Patterns can amplify your coding ‘voice’ when used wisely.
Ever felt overwhelmed by endless choices when starting a new project? Join me as I dive into the chaos of backend development, battling analysis paralysis and procrastination. Discover how I learned to focus on building rather than endlessly researching, and find tips to keep your own projects on track.
Ever felt like your code is an engineering marvel, only to realize you overengineered and built the wrong thing? Or maybe you over-abstracted, blindly following instincts and so-called good practices? I surely did, and I want to share some thoughts on this topic. Let's explore a path toward more practical, sustainable software engineering.
Have you ever thought that your project needs to be rewritten completely from scratch? I share a story of a mobile app rewrite, that didn't went well on few levels, and it got me thinking how other companies approach this topic. And why you shouldn't think about it, there are other ways to address the issues.
I was surprised how much utilizing the UseCase pattern in my last Android app helped with the development. It naturally created a clear structure, created boundaries, and accidentally extracted the app domain. Maybe it will work for you too.
I recently made observations on my limitations due to my 'develper dependencies'. Anything outside my comfort zone feels bad, and I don't like that. My plan is to create a developers survival kit and stick to it. Reducing dependencies and distractions, focusing on craft.
