My tech year in review (2025)
As AI tools improve, many programming activities seem to move faster. This year, I merged more pull requests, touched more repositories, resolved more bugs, paid down more tech debt, built more prototypes, and explored more new tools than ever before.
In comparison, some other things felt surprisingly slow. In this post, I want to reflect on them.
Table Of Contents
Conferences
Before I fully switched to JavaScript tech stack in 2023, I regularly attended Drupal conferences and meetups, often as a speaker. I enjoy the creative challenge of presenting to a like-minded crowd and learn a ton while preparing.
Iāve started applying to JS conferences in 2023 with several proposals from software architecture to interviewing tips to web performance. At first, it was all rejections. In 2024, I finally got an approval for a lightning talk at React Alicante. And in 2025, I had the pleasure of speaking at five (!) conferences:
Interestingly, all conferences selected the same talk, āAt the top of the pyramid: Playwright testing at scaleā. Indeed, my 2024 was all about testing, and I learned Playwright quite well.
Building a speaker profile, growing my network, developing talk ideas, rehearsing, and physically traveling to conference locations all takes a lot of time and energy.
Blogging
Since I was busy with conferences, I didnāt have enough energy left for blogging. For me, the most intense part of writing is thinking, reflecting, and discovering insights from my own experiences. It takes time and patience.
Proofreading and adding interactivity became much easier, though. I wanted to make āBalancing Coupling in Software Designā (book review) easier to read, so with AI assistance, I migrated my blog to Astro and built interactive quiz components.
To keep this blog alive while on āwriting holidaysā, Iāve added a quick āThis Week I Learnedā section.
Reading
AI gives accurate, personalized answers to dozens of my questions daily. Thatās great for getting the task at hand done. But these effortless interactions rarely leave me with deep understanding. For that, I still prefer high-quality, curated content written by domain experts.
A couple of examples from healthcare analytics, since thatās what Iāve been exploring lately:
- The Book of OHDSI - basics of healthcare analytics (focused on the OMOP Common Data Model)
- R for Data Science - a great intro to how scientists think and work in R
Domain-Driven Design
Iāve been practicing DDD to various extents since discovering it in 2022 (āLearning Domain-Driven Designā - the software architecture š book that makes sense). Instead of sharing how amazing and impactful it is, I want to reflect on some challenges Iāve faced so far.
In 2024, I joined Aetion (now part of Datavant) to work on a complex healthcare business domain. I followed my own advice from āOnboarding yourself as a Senior Software Engineerā, got promoted to Staff Engineer, worked in two teams, and contributed to both code and culture in several meaningful ways. Yet, Iām still figuring out the business domain.
Recently, I spent a few months redesigning a drug analytics module. While my official task was to conduct a technical design, most of the time was spent figuring out what the hell we were trying to build. It took several months of using the product, reading documentation, and talking to experts before I could write a first draft. Not exactly the timeline youād expect in the age of AI. Of course, I used AI to support my explorations, but the core thinking was on me and my colleagues.
This is the cost of building something unique in the ācoreā business domain, the one that brings companies their competitive advantage.
While Domain-Driven Design is supposed to simplify this process, in practice itās not always that easy.
DDD Obstacle 1: The name is overloaded
Most backend developers are aware of the Domain-Driven Design methodology. Some practiced tactical DDD focused on aggregates and value objects. Lucky ones participated in EventStorming sessions a few times, but most of us only read or heard about it.
As a result, when developers talk about applying DDD, it usually leads to misunderstandings. The best solution Iāve found is to avoid talking about DDD in the first place.
DDD Obstacle 2: Domain learning is a side quest
Iāve met developers with years of experience in the same company and yet not knowing much about its core business domain. Some intentionally avoid investing in less transferable niche knowledge; others simply donāt have enough time.
In day-to-day work, we developers often prioritize writing code over learning the product. Building software is already hard and requires a lot of technical learning, from programming languages to distributed systems to frontend frameworks and everything in between.
As a result, developers have neither the time nor cognitive capacity to learn the business domain. In my particular case, I have been in healthcare analytics for almost two years now, and I still have a lot to learn.
DDD Obstacle 3: Itās not interesting
Many of us became developers because we genuinely love building software. The idea to learn something completely different, like medicine, law, or insurance, might not sound that exciting.
On the other hand, not all domain experts are equally excited to explain the basics again and again to the disengaged engineering crowd.
Many facilitation activities exist to help overcome these issues. Needless to say, one has to practice a lot to master EventStorming, Domain Storytelling, or similar techniques.
Whatās next
This post was partially inspired by the talk āSlow down to speed up your decision-makingā from Gien Verschatse at GSAS Barcelona 2025. In the age of AI, itās important to remember that some things should be slow. Next year, Iāll continue my DDD journey with the book āCollaborative Software Designā, which Gien co-authored.
Another inspiration of the year is DuckDB. It can process enormous volumes of data super fast on a typical macbook. In combination with my data analytics experiences at work, DuckDB made me curious about data processing beyond traditional relational databases. Slowly, and with a lot of handwritten notes, Iām finally reading the āDesigning Data-Intensive Applicationsā book.
Yet another area Iām curious about is local-first and sync engines, a topic that became even louder after the TanStack DB release.
Iām excited about AI acceleration in coding and looking forward to spending more time on the slow things! š
