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.
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
The mystery In the previous article, I briefly mentioned a slight difference between the ESP-Prog and the reproduced circuit, when it comes to EN: Focusing on EN, it looks like the voltage level goes back to 3.3V much faster on the ESP-Prog than on the breadboard circuit. The grid is horizontally spaced at 2ms, so … Continue reading Overanalyzing a minor quirk of Espressif’s reset circuit → The post Overanalyzing a minor quirk of Espressif’s reset circuit appeared first on Quentin Santos.
I signed up for Hinge. Holy shit with the boosts. How does someone who works on this wake up every morning and feel okay about themselves? Similarly with the tip screens, Uber algorithm, all the zero sum bullshit using all the tricks of psychology to extract a little bit more from every interaction in society. Nudge. Nudge. NUDGE. Want to partake in normal society like buying a coffee, going on a date, getting a ride, paying a friend. Oh, there’s a middle man now. An evil ominous middleman using state of the art AI algorithms to extract just a little bit more from you. But eventually the market will fix this, right? People will feel sick of being manipulated and move elsewhere? Ahhh, but they see that coming long before you do. They have dashboards. Quick Jeeves, tune the AI to make people feel less manipulated. Give them a little bit more for now, we have to think about maximizing lifetime customer value here. Oh the AI already did this on its own? Jeeves you’ve been replaced! People perpetually on the edge. You want to opt out of this all you say? Good luck running a competitive business! Every metric is now a target. You better maximize engagement or you will lose engagement this is a red queen’s race we can’t afford to lose! Burn all the social capital, burn all your values, FEED IT ALL TO MOLOCH! Someday, people will have to realize we live in a society. What will it take? A complete self cannibalization to the point you can’t eat your own mouth? It sure as hell isn’t going to be people opting out, that’s a collective action problem you can’t solve. Democracy, haha, you think the algorithms will let you vote to kill them? Your vote is as decoupled from action as the amount Uber pays the driver is decoupled from the fare that you pay. There’s no reform here, there’s only revolution. Will it simply be a huge financial collapse? Or do we need World War 3? And even World War 3 is on a spectrum. Will mass starvation fix this? Or will the attitude of thinking it’s okay to manipulate others at scale persist even past that? He’s got his, and I’ve got mine… If you open a government S&P 500 account for everyone with $1,000 at birth that’ll pay their social security cause it like…goes up…wait who’s creating this value again? It’s not okay. Advertising is not okay. Price discrimination is not okay. Using big data, machine learning, and psychology to manipulate others at scale is not okay. But you aren’t going to learn this lesson until you have fed a huge majority of your customers to Moloch. Modern capitialism is wireheading. Release the hypnodrones. How many cans of Pepsi did you want them to consume an hour again?
I've never seen so many developers curious about leaving the Mac and giving Linux a go. Something has really changed in the last few years. Maybe Linux just got better? Maybe powerful mini PCs made it easier? Maybe Apple just fumbled their relationship with developers one too many times? Maybe it's all of it. But whatever the reason, the vibe shift is noticeable. This is why the future is so hard to predict! People have been joking about "The Year of Linux on the Desktop" since the late 90s. Just like self-driving cars were supposed to be a thing back in 2017. And now, in the year of our Lord 2025, it seems like we're getting both! I also wouldn't underestimate the cultural influence of a few key people. PewDiePie sharing his journey into Arch and Hyprland with his 110 million followers is important. ThePrimeagen moving to Arch and Hyprland is important. Typecraft teaching beginners how to build an Arch and Hyprland setup from scratch is important (and who I just spoke to about Omarchy). Gabe Newell's Steam Deck being built on Arch and pushing Proton to over 20,000 compatible Linux games is important. You'll notice a trend here, which is that Arch Linux, a notoriously "difficult" distribution, is at the center of much of this new engagement. Despite the fact that it's been around since 2003! There's nothing new about Arch, but there's something new about the circles of people it's engaging. I've put Arch at the center of Omarchy too. Originally just because that was what Hyprland recommended. Then, after living with the wonders of 90,000+ packages on the community-driven AUR package repository, for its own sake. It's really good! But while Arch (and Hyprland) are having a moment amongst a new crowd, it's also "just" Linux at its core. And Linux really is the star of the show. The perfect, free, and open alternative that was just sitting around waiting for developers to finally have had enough of the commercial offerings from Apple and Microsoft. Now obviously there's a taste of "new vegan sees vegans everywhere" here. You start talking about Linux, and you'll hear from folks already in the community or those considering the move too. It's easy to confuse what you'd like to be true with what is actually true. And it's definitely true that Linux is still a niche operating system on the desktop. Even among developers. Apple and Microsoft sit on the lion's share of the market share. But the mind share? They've been losing that fast. The window is open for a major shift to happen. First gradually, then suddenly. It feels like morning in Linux land!
Snippets are a useful addition to Svelte 5. I use them in my Svelte 5 projects like Edna. Snippet basics A snippet is a function that renders html based on its arguments. Here’s how to define and use a snippet: {#snippet hello(name)} <div>Hello {name}!</div> {/snippet} {@render hello("Andrew")} {@render hello("Amy")} You can re-use snippets by exporting them: <script module> export { hello }; </script> {@snippet hello(name)}<div>Hello {name}!</div>{/snippet} Snippets use cases Snippets for less nesting Deeply nested html is hard to read. You can use snippets to extract some parts to make the structure clearer. For example, you can transform: <div> <div class="flex justify-end mt-2"> <button onclick={onclose} class="mr-4 px-4 py-1 border border-black hover:bg-gray-100" >Cancel</button > <button onclick={() => emitRename()} disabled={!canRename} class="px-4 py-1 border border-black hover:bg-gray-50 disabled:text-gray-400 disabled:border-gray-400 disabled:bg-white default:bg-slate-700" >Rename</button > </div> into: {#snippet buttonCancel()} <button onclick={onclose} class="mr-4 px-4 py-1 border border-black hover:bg-gray-100" >Cancel</button > {/snippet} {#snippet buttonRename()}...{/snippet} To make this easier to read: <div> <div class="flex justify-end mt-2"> {@render buttonCancel()} {@render buttonRename()} </div> </div> snippets replace default <slot/> In Svelte 4, if you wanted place some HTML inside the component, you used <slot />. Let’s say you have Overlay.svelte component used like this: <Overlay> <MyDialog></MyDialog> </Overlay> In Svelte 4, you would use <slot /> to render children: <div class="overlay-wrapper"> <slot /> </div> <slot /> would be replaced with <MyDialog></MyDialog>. In Svelte 5 <MyDialog></MyDialog> is passed to Overlay.svelte as children property so you would change Overlay.svelte to: <script> let { children } = $props(); </script> <div class="overlay-wrapper"> {@render children()} </div> children property is created by Svelte compiler so you should avoid naming your own props children. snippets replace named slots A component can have a default slot for rendering children and additional named slots. In Svelte 5 instead of named slots you pass snippets as props. An example of Dialog.svelte: <script> let { title, children } = $props(); </script> <div class="dialog"> <div class="title"> {@render title()} </div> {@render children()} </div> And use: {#snippet title()} <div class="fancy-title">My fancy title</div> {/snippet} <Dialog title={title}> <div>Body of the dialog</div> </Dialog> passing snippets as implicit props You can pass title snippet prop implicitly: <Dialog> {#snippet title()} <div class="fancy-title">My fancy title</div> {/snippet} <div>Body of the dialog</div> </Dialog> Because {snippet title()} is a child or <Dialog>, we don’t have to pass it as explicit title={title} prop. The compiler does it for us. snippets to reduce repetition Here’s part of how I render https://tools.arslexis.io/ {#snippet row(name, url, desc)} <tr> <td class="text-left align-top" ><a class="font-semibold whitespace-nowrap" href={url}>{name}</a> </td> <td class="pl-4 align-top">{@html desc}</td> </tr> {/snippet} {@render row("unzip", "/unzip/", "unzip a file in the browser")} {@render row("wc", "/wc/", "like <tt>wc</tt>, but in the browser")} It saves me copy & paste of the same HTML and makes the structure more readable. snippets for recursive rendering Sometimes you need to render a recursive structure, like nested menus or file tree. In Svelte 4 you could use <svelte:self> but the downside of that is that you create multiple instances of the component. That means that the state is also split among multiple instances. That makes it harder to implement functionality that requires a global view of the structure, like keyboard navigation. With snippets you can render things recursively in a single instance of the component. I used it to implement nested context menus. snippets to customize rendering Let’s say you’re building a Menu component. Each menu item is a <div> with some non-trivial children. To allow the client of Menu customize how items are rendered, you could provide props for things like colors, padding etc. or you could allow ultimate flexibility by accepting an optional menuitem prop that is a snippet that renders the item. You can think of it as a headless UI i.e. you provide the necessary structure and difficult logic like keyboard navigation etc. and allow the client lots of control over how things are rendered. snippets for library of icons Before snippets every SVG Icon I used was a Svelte component. Many icons means many files. Now I have a single Icons.svelte file, like: <script module> export { IconMenu, IconSettings }; </script> {#snippet IconMenu(arg1, arg2, ...)} <svg>... icon svg</svg> {/snippet}} {#snippet IconSettings()} <svg>... icon svg</svg> {/snippet}}
