Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Ognjen Regoje • ognjen.io
Many (most?) engineers go from university to a sizable company significantly distancing them from the actual value their code creates. They labour under the delusion that they’re paid to write code. In fact, they’re paid to make money, and writing code is probably the most expensive way that they can do that. They will often say things like “We should scrap this entirely and re-write it, it will only take 8 months” – often about code that generates 8 figures in revenue and employs several dozen people. Code that pays for their smartwatches. But, of course: Engineers are hired to create business value, not to program things – Don’t Call Yourself A Programmer, And Other Career Advice In my estimate it takes about a decade of experience before engineers start to really internalize this. This can be significantly sped up by having a shorter feedback loop between the code written and the value realized by the engineer. There are two ways to do this: Freelancing Founding Freelancing By freelancing, and doing it well, the reward, is very directly tied to the code written. The best way to do freelance, for the sake of learning, would be to work on fixed cost contracts – which isn’t great freelancing advice, but is excellent for the longterm career. Delivering to someone elses specs makes engineers focused on delivery only the necessary and sufficient code to make that happen. All the correct decisions result in an improvement of the engineers earnings per hour and all mistakes in a reduction. That feedback loop very quickly teaches: The importance of quality and automated testing Architecture and keeping options open Communication and requirements gathering, asking the right questions All of these are factors that come into play once an engineer is breaking the barrier from Senior to management or Staff. Founding a company Founding a company, where the code that you produced secures your salary, teaches those lessons, plus a few others: Understanding the importance tradeoffs that companies make betwen velocity and tech debt It is also an opportunity to learn how to make those tradeoffs well, something engineers aren’t always great at Experience creating the most value possible with the least code Very few enginers pre-emtively suggest ways to test product hyptheses using cheaper appoaches Pragmatism and bias towards shipping and avoidingg gold-plating functionality that is immature Plus you very quickly start to understand why “We should re-write it” is almost never the right business decision. All software engineers should freelance or found a business was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on April 18, 2025.
In The Innovator’s Dilemma Christensen talks about how when acquiring a company you might either be acquiring its product or its processes. Depending on which it is, you need to handle the integration differently. I’ve realized that hiring a new manager follows a similar pattern: either they’re expected to integrate into the organization, or be independent and create some change. That expectation depends on whether the team, and possibly the wider organization, function well. If the team is high-performing, why would adding or overhauling processes make sense over fine-tuning existing ones? But new managers often join and immediately start suggesting ways to fix things. In many of these cases, they aren’t suggesting some best practices but are simply trying to have the new company function in a similar way to their previous one. But they never have enough context to justify these changes. What they should do is take a step back and understand why they were hired and what already works. Are they there to run the team as it is and perhaps look for marginal gains in efficiency and effectiveness? Or are they there because things are fundamentally broken and they need to overhaul the organization? In 9 out of 10 cases, it’s the first one. They’re there to ensure the continuity of the team. Therefore in 9 out of 10 cases the objective should be to integrate into the processes as quickly as possible and help iterate. Why are you here, manager? was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on April 18, 2025.
I love Ben Brode’s Design Lessons from Improv talk. It presents techniques that we could all use more frequently. I particularly took the “Yes, and…“ to heart. It is an excellent technique, or attitude really, that keeps the conversation going. Conversations often start slow but get progressively more interesting the deeper you go. And “Yes, and…” makes it possible to get there. One of my favorite uses of “Yes, and…” is when someone sends you an article that you’ve already read or a video you’ve already watched. The typical response might be 👍 seen it (A whole site is named after the fact that you’ve already read it) If the other person is interested in having a conversation, you’ve just stopped it in its tracks expecting them to put in all the effort to keep it going. A “Yes, and…” response such as “Yes, I’ve read it, and something you found interesting” opens up the conversation. Even if the other person just wanted to share something they thought you might find interesting, you’ve: a) created an opportunity to exchange opinions and b) put in slightly above the bare minimum of effort to acknowledge that what they shared with you was indeed interesting At work At work, specifically, it is useful in all manner of discussions. Conversations about product, or code, or architecture, or team activities, or customer service all get better when you don’t dismiss but build on top of each other. The value of "Yes, and..." was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on April 17, 2025.
One of the best pieces of advice I’ve ever gotten is to take a minute, or a week, after you’ve had a difficult conversation. By and large, people are not unreasonable. They’re not out to get you. They’re not trying to make your life miserable. They’re probably trying to do what they think is right. But tough conversations happen and when they do it’s important to take time to process the information and formulate a more nuanced opinion. To take a work example: picture a conversation where you’re being some particularly heavy feedback You’re confused, you’re sad, you’re angry. You disagree. You want to protest, defend yourself, argue, explain. Doing so, however, would accomplish nothing in the immediate, and probably set you back in the long-term. The other person is probably also upset and stressed about having to have the conversation. Getting defensive would get make them to do the same and the conversation would quickly devolve into one run by emotions. Instead, listen and gather as much information as possible. If possible, try to write as much as you can down. Don’t say much except ask questions and then politely ask for a follow-up meeting in a few days. That will give you the time to process all the information and figure out if they were right, if it might not have been a big deal at all, if there is nuance in the situation or if you were indeed right. Or, as is most likely, some combination of all of the above. You’ll be able to formulate a cohesive model of the situation in your head, which will help you make a better decision or counter-argument if needed. It’ll also give you, and the others, time to cool down and prevent anyone from reacting too emotionally. Come to the follow-up meeting with humility and a willingness to compromise. Recap the previous meeting and make sure that everyone is on the same page. Then explain your understanding of the situation and present your opinion. The end result should be a much more amicable outcome without the need for a third meeting. And while my example is in the context of work, the same is true for personal conversations. So, take a minute. Or a week. It’ll help you make better decisions. During a difficult conversation, remember to take a minute was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on April 17, 2025.
There is nothing as inevitable as a re-org when a new VP joins. When a new executive joins they’re often overwhelmed by the amount of context they need to absorb to start being effective. The more seasoned ones aren’t pertrubed by this: they understand that gathering this context is their full-time job for the next several weeks or months. There’s even a book about this period. The less savvy ones, on the other hand, often reach for one of the following coping strategies, depending on the type of role they occupy. This organization makes no sense, we must re-organize it immediately Spoken by a newly joined VP who needs to assess the organization and understand why it is set up the way it is. It results in several workshops about boundaries, Conway’s law and team topologies result in a slightly different, but not materially significant organization. And a VP with a much better understanding of their people, the culture, the product and the challenges. We must document/map it Spoken by a product manager getting to grips with the features they’ll be working on before having read the abundant sales, technical and product reference materials. This usually results in several workshops where there is a lot of “discovery” and “mapping”. In reality, the product manager is getting an in-person crash course. It rarely results in any new discoveries or documentation or maps being produced but always results in a much more confident product manager. We must have a process for that Spoken by a new engineering manager who’s not yet familiar with the existing processes and ways of working. This usually results in the engineering manager starting to write a Confluence page on how the process should work, until one of the team members sends them an existing, but finished, Confluence page on exactly that, but with slight differences. The new page gets a link to the existing ones and is promptly forgotten. Does this process really work for anyone? A sub-category of the above then the process in place is different from their previous employer. This code is so bad, we must re-write it entirely Spoken by a senior but not yet quite staff engineer who’s just getting to grips with a new codebase – often about code that generates 7 or 8 digits in revenue. It results in the engineer spending several hours on an alternative architecture and running it by their team several times. Eventually, they understand that what they’re suggesting is quite similar to what is actually in place, that there is some refactoring and improvements to be done, but it’s nowhere near as tragic as they imagined it to be. Why does this happen? A week or two after joining, depending on how generous the company is, the engineer gets a ticket to work on, the PM is asked about the backlog priority and the EM why their bug injection rate is so high and what they’re doing about it. And they naturally feel lost. The problem is that most companies don’t set an expected timeline for having a person become effective in their position. How to do better? The amount of context required to be effective increases with seniority. But everyone needs a couple of weeks outside of the default onboarding programme to read through their team’s wiki space, to look through the backlog, to pair with their colleagues, to get an understanding of the work the team is doing, to be present at the retrospectives to listen and not have to lead and facilitate. Only after they get the lay of the land can they start contributing in a meaningful way. The managerial fear of the unknown was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on April 17, 2025.
More in programming
Email is your most important online account, so keep it clean.
Kubernetes is not exactly the most fun piece of technology around. Learning it isn’t easy, and learning the surrounding ecosystem is even harder. Even those who have managed to tame it are still afraid of getting paged by an ETCD cluster corruption, a Kubelet certificate expiration, or the DNS breaking down (and somehow, it’s always the DNS). Samuel Sianipar If you’re like me, the thought of making your own orchestrator has crossed your mind a few times. The result would, of course, be a magical piece of technology that is both simple to learn and wouldn’t break down every weekend. Sadly, the task seems daunting. Kubernetes is a multi-million lines of code project which has been worked on for more than a decade. The good thing is someone wrote a book that can serve as a good starting point to explore the idea of building our own container orchestrator. This book is named “Build an Orchestrator in Go”, written by Tim Boring, published by Manning. The tasks The basic unit of our container orchestrator is called a “task”. A task represents a single container. It contains configuration data, like the container’s name, image and exposed ports. Most importantly, it indicates the container state, and so acts as a state machine. The state of a task can be Pending, Scheduled, Running, Completed or Failed. Each task will need to interact with a container runtime, through a client. In the book, we use Docker (aka Moby). The client will get its configuration from the task and then proceed to pull the image, create the container and start it. When it is time to finish the task, it will stop the container and remove it. The workers Above the task, we have workers. Each machine in the cluster runs a worker. Workers expose an API through which they receive commands. Those commands are added to a queue to be processed asynchronously. When the queue gets processed, the worker will start or stop tasks using the container client. In addition to exposing the ability to start and stop tasks, the worker must be able to list all the tasks running on it. This demands keeping a task database in the worker’s memory and updating it every time a task change’s state. The worker also needs to be able to provide information about its resources, like the available CPU and memory. The book suggests reading the /proc Linux file system using goprocinfo, but since I use a Mac, I used gopsutil. The manager On top of our cluster of workers, we have the manager. The manager also exposes an API, which allows us to start, stop, and list tasks on the cluster. Every time we want to create a new task, the manager will call a scheduler component. The scheduler has to list the workers that can accept more tasks, assign them a score by suitability and return the best one. When this is done, the manager will send the work to be done using the worker’s API. In the book, the author also suggests that the manager component should keep track of every tasks state by performing regular health checks. Health checks typically consist of querying an HTTP endpoint (i.e. /ready) and checking if it returns 200. In case a health check fails, the manager asks the worker to restart the task. I’m not sure if I agree with this idea. This could lead to the manager and worker having differing opinions about a task state. It will also cause scaling issues: the manager workload will have to grow linearly as we add tasks, and not just when we add workers. As far as I know, in Kubernetes, Kubelet (the equivalent of the worker here) is responsible for performing health checks. The CLI The last part of the project is to create a CLI to make sure our new orchestrator can be used without having to resort to firing up curl. The CLI needs to implement the following features: start a worker start a manager run a task in the cluster stop a task get the task status get the worker node status Using cobra makes this part fairly straightforward. It lets you create very modern feeling command-line apps, with properly formatted help commands and easy argument parsing. Once this is done, we almost have a fully functional orchestrator. We just need to add authentication. And maybe some kind of DaemonSet implementation would be nice. And a way to handle mounting volumes…
Here are a few tangentially-related ideas vaguely near the theme of comparison operators. comparison style clamp style clamp is median clamp in range range style style clash? comparison style Some languages such as BCPL, Icon, Python have chained comparison operators, like if min <= x <= max: ... In languages without chained comparison, I like to write comparisons as if they were chained, like, if min <= x && x <= max { // ... } A rule of thumb is to prefer less than (or equal) operators and avoid greater than. In a sequence of comparisons, order values from (expected) least to greatest. clamp style The clamp() function ensures a value is between some min and max, def clamp(min, x, max): if x < min: return min if max < x: return max return x I like to order its arguments matching the expected order of the values, following my rule of thumb for comparisons. (I used that flavour of clamp() in my article about GCRA.) But I seem to be unusual in this preference, based on a few examples I have seen recently. clamp is median Last month, Fabian Giesen pointed out a way to resolve this difference of opinion: A function that returns the median of three values is equivalent to a clamp() function that doesn’t care about the order of its arguments. This version is written so that it returns NaN if any of its arguments is NaN. (When an argument is NaN, both of its comparisons will be false.) fn med3(a: f64, b: f64, c: f64) -> f64 { match (a <= b, b <= c, c <= a) { (false, false, false) => f64::NAN, (false, false, true) => b, // a > b > c (false, true, false) => a, // c > a > b (false, true, true) => c, // b <= c <= a (true, false, false) => c, // b > c > a (true, false, true) => a, // c <= a <= b (true, true, false) => b, // a <= b <= c (true, true, true) => b, // a == b == c } } When two of its arguments are constant, med3() should compile to the same code as a simple clamp(); but med3()’s misuse-resistance comes at a small cost when the arguments are not known at compile time. clamp in range If your language has proper range types, there is a nicer way to make clamp() resistant to misuse: fn clamp(x: f64, r: RangeInclusive<f64>) -> f64 { let (&min,&max) = (r.start(), r.end()); if x < min { return min } if max < x { return max } return x; } let x = clamp(x, MIN..=MAX); range style For a long time I have been fond of the idea of a simple counting for loop that matches the syntax of chained comparisons, like for min <= x <= max: ... By itself this is silly: too cute and too ad-hoc. I’m also dissatisfied with the range or slice syntax in basically every programming language I’ve seen. I thought it might be nice if the cute comparison and iteration syntaxes were aspects of a more generally useful range syntax, but I couldn’t make it work. Until recently when I realised I could make use of prefix or mixfix syntax, instead of confining myself to infix. So now my fantasy pet range syntax looks like >= min < max // half-open >= min <= max // inclusive And you might use it in a pattern match if x is >= min < max { // ... } Or as an iterator for x in >= min < max { // ... } Or to take a slice xs[>= min < max] style clash? It’s kind of ironic that these range examples don’t follow the left-to-right, lesser-to-greater rule of thumb that this post started off with. (x is not lexically between min and max!) But that rule of thumb is really intended for languages such as C that don’t have ranges. Careful stylistic conventions can help to avoid mistakes in nontrivial conditional expressions. It’s much better if language and library features reduce the need for nontrivial conditions and catch mistakes automatically.
Unexamined life is not worth living said Socrates. I don’t know about that but to become a better, faster, more productive programmer it pays to examine what makes you un-productive. Fixing bugs is one of those un-productive activities. You have to fix them but it would be even better if you didn’t write them in the first place. Therefore it’s good to reflect after fixing a bug. Why did the bug happen? Could I have done something to not write the bug in the first place? If I did write the bug, could I do something to diagnose or fix it faster? This seems like a great idea that I wasn’t doing. Until now. Here’s a random selection of bugs I found and fixed in SumatraPDF, with some reflections. SumatraPDF is a C++ win32 Windows app. It’s a small, fast, open-source, multi-format PDF/eBook/Comic Book reader. To keep the app small and fast I generally avoid using other people’s code. As a result most code is mine and most bugs are mine. Let’s reflect on those bugs. TabWidth doesn’t work A user reported that TabWidth advanced setting doesn’t work in 3.5.2 but worked in 3.4.6. I looked at the code and indeed: the setting was not used anywhere. The fix was to use it. Why did the bug happen? It was a refactoring. I heavily refactored tabs control. Somehow during the rewrite I forgot to use the advanced setting when creating the new tabs control, even though I did write the code to support it in the control. I guess you could call it sloppiness. How could I not write the bug? I could review the changes more carefully. There’s no-one else working on this project so there’s no one else to do additional code reviews. I typically do a code review by myself with webdiff but let’s face it: reviewing changes right after writing them is the worst possible time. I’m biased to think that the code I just wrote is correct and I’m often mentally exhausted. Maybe I should adopt a process when I review changes made yesterday with fresh, un-tired eyes? How could I detect the bug earlier?. 3.5.2 release happened over a year ago. Could I have found it sooner? I knew I was refactoring tabs code. I knew I have a setting for changing the look of tabs. If I connected the dots at the time, I could have tested if the setting still works. I don’t make releases too often. I could do more testing before each release and at the very least verify all advanced settings work as expected. The real problem In retrospect, I shouldn’t have implemented that feature at all. I like Sumatra’s customizability and I think it’s non-trivial contributor to it’s popularity but it took over a year for someone to notice and report that particular bug. It’s clear it’s not a frequently used feature. I implemented it because someone asked and it was easy. I should have said no to that particular request. Fix printing crash by correctly ref-counting engine Bugs can crash your program. Users rarely report crashes even though I did put effort into making it easy. When I a crash happens I have a crash handler that saves the diagnostic info to a file and I show a message box asking users to report the crash and with a press of a button I launch a notepad with diagnostic info and a browser with a page describing how to submit that as a GitHub issue. The other button is to ignore my pleas for help. Most users overwhelmingly choose to ignore. I know that because I also have crash reporting system that sends me a crash report. I get thousands of crash reports for every crash reported by the user. Therefore I’m convinced that the single most impactful thing for making software that doesn’t crash is to have a crash reporting system, look at the crashes and fix them. This is not a perfect system because all I have is a call stack of crashed thread, info about the computer and very limited logs. Nevertheless, sometimes all it takes is a look at the crash call stack and inspection of the code. I saw a crash in printing code which I fixed after some code inspection. The clue was that I was accessing a seemingly destroyed instance of Engine. That was easy to diagnose because I just refactored the code to add ref-counting to Engine so it was easy to connect the dots. I’m not a fan of ref-counting. It’s easy to mess up ref-counting (add too many refs, which leads to memory leaks or too many releases which leads to premature destruction). I’ve seen codebases where developers were crazy in love with ref-counting: every little thing, even objects with obvious lifetimes. In contrast,, that was the first ref-counted object in over 100k loc of SumatraPDF code. It was necessary in this case because I would potentially hand off the object to a printing thread so its lifetime could outlast the lifetime of the window for which it was created. How could I not write the bug? It’s another case of sloppiness but I don’t feel bad. I think the bug existed there before the refactoring and this is the hard part about programming: complex interactions between distant, in space and time, parts of the program. Again, more time spent reviewing the change could have prevented it. As a bonus, I managed to simplify the logic a bit. Writing software is an incremental process. I could feel bad about not writing the perfect code from the beginning but I choose to enjoy the process of finding and implementing improvements. Making the code and the program better over time. Tracking down a chm thumbnail crash Not all crashes can be fixed given information in crash report. I saw a report with crash related to creating a thumbnail crash. I couldn’t figure out why it crashes but I could add more logging to help figure out the issue if it happens again. If it doesn’t happen again, then I win. If it does happen again, I will have more context in the log to help me figure out the issue. Update: I did fix the crash. Fix crash when viewing favorites menu A user reported a crash. I was able to reproduce the crash and fix it. This is the bast case scenario: a bug report with instructions to reproduce a crash. If I can reproduce the crash when running debug build under the debugger, it’s typically very easy to figure out the problem and fix it. In this case I’ve recently implemented an improved version of StrVec (vector of strings) class. It had a compatibility bug compared to previous implementation in that StrVec::InsertAt(0) into an empty vector would crash. Arguably it’s not a correct usage but existing code used it so I’ve added support to InsertAt() at the end of vector. How could I not write the bug? I should have written a unit test (which I did in the fix). I don’t blindly advocate unit tests. Writing tests has a productivity cost but for such low-level, relatively tricky code, unit tests are good. I don’t feel too bad about it. I did write lots of tests for StrVec and arguably this particular usage of InsertAt() was borderline correct so it didn’t occur to me to test that condition. Use after free I saw a crash in crash reports, close to DeleteThumbnailForFile(). I looked at the code: if (!fs->favorites->IsEmpty()) { // only hide documents with favorites gFileHistory.MarkFileInexistent(fs->filePath, true); } else { gFileHistory.Remove(fs); DeleteDisplayState(fs); } DeleteThumbnailForFile(fs->filePath); I immediately spotted suspicious part: we call DeleteDisplayState(fs) and then might use fs->filePath. I looked at DeleteDisplayState and it does, in fact, deletes fs and all its data, including filePath. So we use freed data in a classic use after free bug. The fix was simple: make a copy of fs->filePath before calling DeleteDisplayState and use that. How could I not write the bug? Same story: be more careful when reviewing the changes, test the changes more. If I fail that, crash reporting saves my ass. The bug didn’t last more than a few days and affected only one user. I immediately fixed it and published an update. Summary of being more productive and writing bug free software If many people use your software, a crash reporting system is a must. Crashes happen and few of them are reported by users. Code reviews can catch bugs but they are also costly and reviewing your own code right after you write it is not a good time. You’re tired and biased to think your code is correct. Maybe reviewing the code a day after, with fresh eyes, would be better. I don’t know, I haven’t tried it.
A little while back I heard about the White House launching their version of a Drudge Report style website called White House Wire. According to Axios, a White House official said the site’s purpose was to serve as “a place for supporters of the president’s agenda to get the real news all in one place”. So a link blog, if you will. As a self-professed connoisseur of websites and link blogs, this got me thinking: “I wonder what kind of links they’re considering as ‘real news’ and what they’re linking to?” So I decided to do quick analysis using Quadratic, a programmable spreadsheet where you can write code and return values to a 2d interface of rows and columns. I wrote some JavaScript to: Fetch the HTML page at whitehouse.gov/wire Parse it with cheerio Select all the external links on the page Return a list of links and their headline text In a few minutes I had a quick analysis of what kind of links were on the page: This immediately sparked my curiosity to know more about the meta information around the links, like: If you grouped all the links together, which sites get linked to the most? What kind of interesting data could you pull from the headlines they’re writing, like the most frequently used words? What if you did this analysis, but with snapshots of the website over time (rather than just the current moment)? So I got to building. Quadratic today doesn’t yet have the ability for your spreadsheet to run in the background on a schedule and append data. So I had to look elsewhere for a little extra functionality. My mind went to val.town which lets you write little scripts that can 1) run on a schedule (cron), 2) store information (blobs), and 3) retrieve stored information via their API. After a quick read of their docs, I figured out how to write a little script that’ll run once a day, scrape the site, and save the resulting HTML page in their key/value storage. From there, I was back to Quadratic writing code to talk to val.town’s API and retrieve my HTML, parse it, and turn it into good, structured data. There were some things I had to do, like: Fine-tune how I select all the editorial links on the page from the source HTML (I didn’t want, for example, to include external links to the White House’s social pages which appear on every page). This required a little finessing, but I eventually got a collection of links that corresponded to what I was seeing on the page. Parse the links and pull out the top-level domains so I could group links by domain occurrence. Create charts and graphs to visualize the structured data I had created. Selfish plug: Quadratic made this all super easy, as I could program in JavaScript and use third-party tools like tldts to do the analysis, all while visualizing my output on a 2d grid in real-time which made for a super fast feedback loop! Once I got all that done, I just had to sit back and wait for the HTML snapshots to begin accumulating! It’s been about a month and a half since I started this and I have about fifty days worth of data. The results? Here’s the top 10 domains that the White House Wire links to (by occurrence), from May 8 to June 24, 2025: youtube.com (133) foxnews.com (72) thepostmillennial.com (67) foxbusiness.com (66) breitbart.com (64) x.com (63) reuters.com (51) truthsocial.com (48) nypost.com (47) dailywire.com (36) From the links, here’s a word cloud of the most commonly recurring words in the link headlines: “trump” (343) “president” (145) “us” (134) “big” (131) “bill” (127) “beautiful” (113) “trumps” (92) “one” (72) “million” (57) “house” (56) The data and these graphs are all in my spreadsheet, so I can open it up whenever I want to see the latest data and re-run my script to pull the latest from val.town. In response to the new data that comes in, the spreadsheet automatically parses it, turn it into links, and updates the graphs. Cool! If you want to check out the spreadsheet — sorry! My API key for val.town is in it (“secrets management” is on the roadmap). But I created a duplicate where I inlined the data from the API (rather than the code which dynamically pulls it) which you can check out here at your convenience. Email · Mastodon · Bluesky
