Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Ognjen Regoje • ognjen.io
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.
More in programming
I know I said we'd be back to normal newsletters this week and in fact had 80% of one already written. Then I unearthed something that was better left buried. Blog post here, Patreon notes here (Mostly an explanation of how I found this horror in the first place). Next week I'll send what was supposed to be this week's piece. (PS: April Cools in three weeks!)
Ask any B2C SaaS founder what metric they’d like to improve and most will say reducing churn. However, proactively reducing churn is a difficult task. I’ll outline the approach we’ve taken at Jenni AI to go from ~17% to 9% churn over the past year. We are still a work in progress but hopefully you’ll […] The post Notes on Improving Churn appeared first on Marc Astbury.
Meditation is easy when you know what to do: absolutely nothing! It's hard at first, like trying to look at the back of your own head, but there's a knack to it.
Discover why 'if not mylist' is twice as fast as 'len(mylist) == 0' by examining CPython's VM instructions and object memory access patterns.
In a fit of frustration, I wrote the first version of Kamal in six weeks at the start of 2023. Our plan to get out of the cloud was getting bogged down in enterprisey pricing and Kubernetes complexity. And I refused to accept that running our own hardware had to be that expensive or that convoluted. So I got busy building a cheap and simple alternative. Now, just two years later, Kamal is deploying every single application in our entire heritage fleet, and everything in active development. Finalizing a perfectly uniform mode of deployment for every web app we've built over the past two decades and still maintain. See, we have this obsession at 37signals: That the modern build-boost-discard cycle of internet applications is a scourge. That users ought to be able to trust that when they adopt a system like Basecamp or HEY, they don't have to fear eviction from the next executive re-org. We call this obsession Until The End Of The Internet. That obsession isn't free, but it's worth it. It means we're still operating the very first version of Basecamp for thousands of paying customers. That's the OG code base from 2003! Which hasn't seen any updates since 2010, beyond security patches, bug fixes, and performance improvements. But we're still operating it, and, along with every other app in our heritage collection, deploying it with Kamal. That just makes me smile, knowing that we have customers who adopted Basecamp in 2004, and are still able to use the same system some twenty years later. In the meantime, we've relaunched and dramatically improved Basecamp many times since. But for customers happy with what they have, there's no forced migration to the latest version. I very much had all of this in mind when designing Kamal. That's one of the reasons I really love Docker. It allows you to encapsulate an entire system, with all of its dependencies, and run it until the end of time. Kind of how modern gaming emulators can run the original ROM of Pac-Man or Pong to perfection and eternity. Kamal seeks to be but a simple wrapper and workflow around this wondrous simplicity. Complexity is but a bridge — and a fragile one at that. To build something durable, you have to make it simple.
