My year 2023 in review

I had learned a lot this year. In spring 2022, I took over a small team that should have been finishing a project, and helped bring it to a successful though much delayed conclusion. In the summer we started a new big project, a complete rewrite of our dashboards on both backend and frontend, to provide more flexibility and power, and better "storytelling" capabilities. I would love to say that we finished on time and budget, alas, we did not. Yet it was a marked improvement over the previous project. And I learned about the difficulty of estimation, the need to discover and track dependencies early, flexible scoping, and the importance of good communication. Our users are happy. We nerds are also happy, with how we managed to extend and leverage our existing abstraction for this use case, and ended up deprecating and cleaning up a bunch of old code, simplifying the whole thing, and also getting rid of the need to store huge amounts of raw data.

Throughout the whole year, I have strived to find ways to balance the many conflicting needs: maintaining and improving existing features, delivering new ones, cleaning up and improving the platform itself. Resources are always limited, so how do we ensure that we put them where they produce the biggest effect? How to measure and compare the value of improving existing vs. adding new functionality? What is "good enough," and could we actually be harming ourselves by delivering more good features over fewer great ones? Or the other way around? And what about the cost vs. benefit of improving the codebase? These are hard product and technical questions. A good colleague has recommended the book "Escaping the Build Trap: How Effective Product Management Creates Real Value" which I found insightful and helpful, but not enough to help me resolve this conundrum. I think I believe in fewer, simpler, but awesome features. A deep understanding of your customers and users is a must - but there is no single person possessing it (though some people may have crucial pieces of the puzzle). I believe that a team needs to work on actively building this understanding, to propose, test, and often throw away hypotheses. We need to define value and measure it, not just blindly deliver features. Most of all, we need a clear and strong vision of the product to guide us. My nightmare is drowning people and the product in a flood of half-baked features in an attempt to satisfy disparate, unclear groups of users. Fortunately, we have a very good product culture and deep understanding of the market. Though there is always an opportunity for improvement - at least on my side.

My second big struggle was balancing all my roles: leading people and making sure they are happy, productive, and develop their potential; contributing to project management; contributing to product management; evolving the development process; being the tech lead; troubleshooting production issues; coding; contributing to company-wide culture and efforts. I love coding and solving technical problems. I hate context switching - yet some days felt like that was the only thing I was doing. For some 9 years now I have worked only 70%, but the last year I wasn’t able to work little enough, so I increased it to 80%. Yet there are still periods where I am overwhelmed by the amount of work. Fortunately, I have now managed to hand over a key responsibility, and have been in some promising discussions about making my role more flexible and delegating some more responsibilities. I don’t need to (and am not) great at everything, so let’s explore ways to make us all the most effective, together. I am curious to see where we will get…​

I have found a bunch of great ideas in 📖 The Team that Managed Itself: A Story of Leadership, a "business novel," which is easy to read. Sadly, I wasn’t able to prioritize applying any of them, yet.

I have written 9 posts, primarily about Fulcro, Rama, and learnings from my paid and open-source work:

I have also published a couple of Fulcro live-codings.

In December 2022, I have started building a tiny ERP system for a friend and his tiny company, both to help him automate and as a real-world learning experience. I have spent many hours building fulcro-rad-asami and the application itself, then migrated it to embedded Datomic when Cognitect made it free. Picking Asami in the first place wasn’t the best business decision, but it was an awesome learning decision - and that’s what this was about. Among others, I gained deep insight into RAD persistence adapters, and learned to really appreciate some Datomic features. These efforts also produced multiple small contributions across the Fulcro ecosystem, including fulcro-rad-datomic and fulcro-rad-semantic-ui.

My main community contributions were improving further fulcro-troubleshooting, starting Fulcro Cookbook, and reviving FulcroDemos with its small examples. The Cookbook has currently one (very useful) recipe, and ideas for couple more, when I (or somebody) get the time.

I had only few mentoring engagements this year, which is a pity, because I always learn a ton from these. On the other hand, it gave me more time for my other projects 🤷.

I have contributed in small ways to a bunch of projects, such as the Clojure static blog builder Cryogen, Honey SQL, my own clj-tumblr-summarizer. The one I am most proud of, and which also took most time, is adding support for Fulcro to Borkdude’s Small Clojure Interpreter and leveraging it to build an interactive web code editor so that you can play with Fulcro directly in your browser. (Also available in their own SCI Playground.) I have also spent an unreasonable amount of time adding search and other improvements to my blog 😅.

One thing I was very curious about and hoped to try but didn’t was Electric Clojure, which promises radical simplification of frontend-backend communication and far simpler webapps. Next year…​ 🤞

Other things I am excited about: ClojureDart, a Clojure dialect for Flutter and Dart. My highly respected ex-colleagues were very excited about using Flutter, and ClojureDart opens it for me without having to switch a language 😍. (If I ever need to write a mobile app.)