I didn’t write much this year. The projects that I worked on (at work) used up most of my creative mental capacity leaving little for writing. The backlog is brimming, however. Targets for 2024 ❌ Publish at least 40 posts 11 ❌ Reach at least 200k readers Don’t have an accurate number ❌ Have at least 6 posts on the front page of something Probably would have met this if I had posted more – I had one successful post on Jan 14, which is encouraging ❌ Make at least $50 from writing. Nope, did no monetization whatsoever Breakdown Some stats: Number of posts: 11 Total word count: 3125 Longest post: When am I “allowed” to quit and not be labeled a quitter? (630) Shortest post: Speaking at Hasso-Plattner-Institut (0, because it’s just a link to a LinkedIn post) Breakdown by category: business: 1 startups: 1 ethics: 1 robots: 1 architecture: 1 interviewing: 1 productivity: 1 selenium: 1 doctolib: 1 No trend there. Feedly still reports 18 followers - no movement. But it also marked the blog as inactive which is a shame. Targets for 2025 I would like to commit to writing more in 2024, but I’m not very confident that I will have the time. Regardless, the 2024 goals were quite lofty but achievable so it makes sense to try them again Publish at least 36 posts (3 per month) Reach at least 200k readers (not sure how to track this accurately since I’m not keen to add analytics and GoAccess doesn’t seem to be super accurate) Have at least 6 posts gain traction (front page of HN, 10 reactions on LinkedIn, etc) A review of the blog in 2024 was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on January 01, 2025.

From the links in the sources, the following code snippet can be used to track the cursor: <style> .dot { background: red; position: absolute; width: 2px; height: 2px; z-index: 10000; } </style> (function () { "use strict"; document.onmousemove = handleMouseMove; function handleMouseMove(event) { var dot, eventDoc, doc, body, pageX, pageY; event = event || window.event; // IE-ism // If pageX/Y aren't available and clientX/Y // are, calculate pageX/Y - logic taken from jQuery // Calculate pageX/Y if missing and clientX/Y available if (event.pageX == null && event.clientX != null) { eventDoc = (event.target && event.target.ownerDocument) || document; doc = eventDoc.documentElement; body = eventDoc.body; event.pageX = event.clientX + ((doc && doc.scrollLeft) || (body && body.scrollLeft) || 0) - ((doc && doc.clientLeft) || (body && body.clientLeft) || 0); event.pageY = event.clientY + ((doc && doc.scrollTop) || (body && body.scrollTop) || 0) - ((doc && doc.clientTop) || (body && body.clientTop) || 0); } // Add a dot to follow the cursor dot = document.createElement("div"); dot.className = "dot"; dot.style.left = event.pageX + "px"; dot.style.top = event.pageY + "px"; document.body.appendChild(dot); } })(); You can then wrap that into a helper that you can call in your test. You can just page.execute_script(helper_js) and you can inject the CSS similarly. Then binding.pry after that’s done and move the cursor around to get the correct offsets. Note that if you add this javascript snippet hover will no longer trigger on your elements because a new dot element will always be under the cursor. Tracking the cursor in Selenium driven Chrome was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on January 27, 2024.

There was a great post about doing unforgettable work. Absolutely. Go above and beyond. Do what’s right. But also, do forgettable work. Work that you won’t remember the following week. Do a lot of it. In fact, do at least 30 minutes of utterly forgettable work on something you’re trying to improve every day. Very soon it’ll stop being forgettable. Do forgettable work was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on January 27, 2024.

Over the past year or so I’ve done about two dozen systems design interviews (as an interviewer) and have two somewhat subtle observations that would help some candidates. 1. The word system has two meanings The definition most engineers reach for immediately is the one relating to computers. But the organization itself is a system, in a generic meaning of the word. It’s important to consider the organization for two reasons: 1. Its structure informs the computer systems Boundaries between domains are often strong indicators that boundaries between computer systems should also exist. 2. Tech exists in service of the business And putting systems in the context of the orga demonstrates the understanding that business requirements take precedence over technical convenience. These two considerations get considerably more important with seniority. While junior developers often don’t consider the organization aspect, their area of influence is local so it’s not too relevant to their everyday work. On the other hand, for staff+ engineers who are supposed to influence entire domains or even the whole organization, it’s crucial. 2. The interview is about design Several candidates shy away from designing a system using tech they theoretically know about but wouldn’t be able to implement themselves. It mostly happens to senior engineers who are in a transitionary phase to staff where they have a wide overview of tech and understand much of the implications to the organization. They have an overview of a lot of tech and can discuss tradeoffs. But, they do not have hands-on experience in all of them. The second is that candidates often don’t recognize that design is iterative. As the interview progresses the experienced engineer re-evaluates assumptions, re-checks constraints and iterates on the design. Components can be changed, replaced or removed entirely. The less experienced candidates typically just add components. The third is that design is about trade-offs. What are you willing to sacrifice and most importantly why? And you’re not being evaluated on the final decision but on the process you take to get there. As silly as it sounds, system design interviews are about systems and design was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on January 20, 2024.

In a recent conversation with some colleagues, we were talking about how startups make the trade-off between design, domain-driven specifically, in favor of speed. They intentionally take on debt, technical and otherwise, to move faster. I wasn’t in favour of employing DDD in a startup because it’s expensive and slow for a small system. There comes a time when the startup code needs to transition into enterprise DDD-style code, but I think it can be made if and when necessary. After the conversation, I thought about the shortcuts I took building Supplybunny but noticed a few things that I did that were DDD-like. E-commerce as a domain seems to encourage the same practices that DDD advocates for. Ubiquitous language When we started Supplybunny I knew little about the food and beverage industry. That’s what prompted me to learn the jargon. Besides, the different actors used different language. For instance, a supplier would call a product an “SKU”, while a buyer would call it an “ingredient”. A supplier would care about an order and a logistics partner would care about a delivery or shipment. The difference in language made it plenty clear that there were different contexts at play even if I wasn’t intentionally trying to separate them. Bounded contexts In e-commerce bounded contexts are clearer than in most other domains. There is a public search for which you don’t need to log in. The way a supplier and a buyer interact with orders and the information they need to see is different. On the admin side, different departments need to see different things: logistics don’t care about customer support information, and vice versa. Aggregates A big part of e-commerce is dealing with the financial aspect of it. A key part of that is that the order information must be isolated and not change as a result of changes elsewhere. For instance, the product name in an order item, the supplier address in the invoice, and the delivery charge. Not only that, but several fields have multiple values. Take, for instance, the delivery charge: one amount is shown to the buyer, one to the supplier, one to the admin, and one might be sent to an external provider. And not just that, but each of these must be independently traceable - that is, you must be able to generate an account statement for each of those actors. This naturally encourages duplication and isolation of data. Two patterns I used to manage that were the functional model and the actor model. All these requirements naturally lead to clearer boundaries between contexts. Lessons in DDD from building an e-commerce platform was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on January 19, 2024.