Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Ognjen Regoje • ognjen.io
At a conference a while back, I noticed a couple of speakers get such a confidence boost after solving a small technical glitch. We should probably make that a part of every talk. Have the mic not connect automatically, or an almost-complete puzzle on the stage that the speaker can finish, or have someone forget their badge and the speaker return it to them. Maybe the next time I, or a consenting teammate, have to give a presentation I’ll try to engineer such a situation. All conference talks should start with a small technical glitch that the speaker can easily solve was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on April 03, 2025.
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.
Here are a few things I’ve seen founders do that made me confident in their ability and dedication. Elevator pitch in LinkedIn tagline A founder who is all in is constantly selling. That means their tagline will: a) be for their company, not for them b) be the sales pitch, not a vague aspirational vision Value proposition keeps getting more specific If every time you talk to a founder and their value proposition is more and more specific to me indicates that they’re learning more and more about their USP, about their target customer, about the market. The opposite of this is a company that pivots every six months. No short stints in the CV Building a startup is decidedly a marathon. I think it takes about 4 years to make real progress in a startup. Folks who jump positions every year are chasing a career and are unlikely to want to slog through for such a long time. Not that there’s anything wrong with that, it’s just not the right profile. Worked at companies of different sizes A founder who’s seen multiple stages of a startup is more likely to be successful. While they might not have been in the top leadership positions they would have seen the challenges the organization faces, especially during the transitions. Worked in different industries, or not There is a difference between the technical and the business founders. The startups I’ve seen where the business founder was part of the industry for a while worked well. But I’ve also seen them get so focused on how things are that they can’t see how things should be. For technical founders, on the other hand, I think it’s a clear advantage to have been in different industries and seen different approaches. Switched to full-time as soon as possible It might be obvious but the sooner the founder goes full time the more skin in the game, but also belief in the business, they have. They’re that much more committed to it. The opposite of this is founders who are simultaneously CEOs of multiple companies. I don’t think that can ever work – least of all for startups. Don’t succumb to the hype The founders who aren’t always talking about how they’re going to incorporate the latest hype in their product seemed to get more accomplished. Founded, or was an early employee, of a startup that raised a round or two I think this is probably the biggest indicator. Having done the early stages, seed and maybe series A, eliminates A LOT of uncertainty. At least the company won’t fail because the founders aren’t competent at running a business, since they’ve done it before. I’d even be biased toward someone who did a startup over someone who’s been employed at a name-brand unicorn simply because the skill set is not at all equivalent. Green flags for investable founders was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on January 03, 2024.
2023 was a busy year so I did not spend a lot of time blogging, unfortunately. It was only in December that I had meaningful time for writing. In the 2022 review I set a few targets for the blog in 2023: Targets for 2023 ❎ Publish at least 40 posts 14 ✅ Reach at least 150k readers With a couple of viral posts this is very easily achievable. I’m at 180k even though I only had a few posts. I will include a target for the number of posts as well. ❎ Get at least 10 posts professionally? publicized I was thinking of hiring someone to help me distribute the content, but a) I didn’t produce much of it and b) I didn’t hire anyone. ❎ Build an audience (recurring readers, Twitter, newsletter?) Did not do this at all. ❎ Publish something on at least two other sites Did not do this. And I think I will not focus on this going forward. Quantity I published 14 posts, totaling approximately 9700 words. The average blog post length is 695 words. Working on legacy code is the longest post at ~729 words, followed by Lie still in bed with 679. The sample size isn’t sufficient to comment on whether the average length is adequate. Popularity Lie still in bed was the most popular substantial article. That’s encouraging because it’s not about tech, it’s just generic advice. MIT No AI was fairly popular but got flagged on HackerNews which killed it. It was also very quick to write. Interestingly Reddit’s disrespectful design and Big tech should help tackle misinformation on smaller platforms made a comeback. I don’t have detailed tracking anymore, it’s all based on server logs, so I can’t dig deeper into where the traffic is coming from. Editing the source markdown of a generated static site in the browser had some traffic as well which is interesting. It’s probably the most interesting post I wrote in a long while. Feedly reports 18 followers. Up three. What I’ve learnt I think I got better at writing more clearly. I’m more comfortable, at least at the moment, with publishing posts and not worrying too much about whether they’re perfect. I think that’s at least partly because I wrote so many posts in December. I made one pass with the rough draft. Then another pass that finalized the content. Then a final one where I didn’t change the content but just proofread and ensured clarity. Then I published the post. I took to heart the 2022 objective to frame posts positively more positively and have done that for several of them. Targets for 2024 Publish at least 40 posts Reach at least 200k readers Have at least 6 posts on the front page of something Make at least $50 from writing. I’m not sure if this is a good objective but maybe it might motivate me to think of monetization alternatives. A review of the blog in 2023 was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on January 01, 2024.
As much as working remotely is a competitive hiring advantage again, not wanting to work remotely is now an advantage for getting hired. A lot of companies are mandating returns to the office. Many more are scrapping fully remote positions, with some even rescinding fully-remote offers. So, for better or worse, not wanting to work remotely is now a competitive advantage. If that’s not one of your requirements you’re likely to pick up more offers. Not wanting to work remotely is now a competitive advantage was originally published by Ognjen Regoje at Ognjen Regoje • ognjen.io on October 15, 2023.
More in programming
This post was previously published through my newsletter on October 19, 2026. From time to time, I will republish newsletter issues on my blog here if I think people (and search engines) might benefit from it. If you want to read everything I’ve written once it is posted, I recommend signing up for the newsletter. For the last 5-6 years or so, I’ve been talking about, teaching and helping teams implement contract testing on a regular basis. To make that more concrete: at the moment, I’m having ongoing conversations with four different potential clients about helping them in some way with their contract testing implementation, and so far, I’ve run my contract testing workshop four times this year. It probably doesn’t come as a surprise to you when I say that I really like the concept of contract testing as a means of addressing integration testing challenges in distributed software systems. However, no matter if I’m speaking, teaching or implementing contract testing, certain challenges almost always come up at some point, and I want to highlight some of those today. Understanding the concept of contract testing First of all, it often takes people a while to understand the concept of contract testing, especially when they’re used to what I call the ‘traditional’ approach to integration testing: deploying the systems and services in scope to a shared testing environment and then testing them ‘as a whole’. Of course, the more distributed your system and your development process is, and the higher the deployment frequency, the more complex and the slower this integration testing approach is going to be. The premise behind contract testing is to break that integration testing puzzle down into small chunks of individual consumer-provider pairs, and then test the integration between those two in an asynchronous manner. By asynchronous, I mean that there is no need to deploy consumer and provider into a shared environment; both parties perform their part of the process in their own, local development environment. This means you can detect potential integration issues before you deploy, instead of stumbling onto them after you do so. This makes contract testing (or contract-based integration testing, to use its proper name) a significantly different approach to integration testing compared to the more ‘traditional’ approach. In my experience, it usually takes people time to wrap their head around how the process actually works, which steps you should take and in which order, and what you (do not yet) know after each step. It often takes going through several contract testing cycles before people start to ‘get it’. That’s not their fault, that is to be expected, since the contract-based approach to integration testing is, again, quite different from what they’ve been doing for so long. To better cater to this, I redesigned my contract testing workshop a year and a half or so ago. It is now a full-day workshop (half a day is simply too short), and I take much smaller steps and repeat them more often. From what I see, this has led to a better understanding of the concepts with my audience, and that’s the whole point. Contract testing === Pact I’ve talked to quite a few teams that had heard of contract testing somewhere, decided that that was the way out of their integration testing problems, and then immediately started writing contract tests with Pact. Understandable, because Pact is a very useful, very powerful and very popular tool, plus, it’s open source, which makes it easy for teams to get started. Often, they skipped a step in the process. Pact is very much a consumer-driven contract testing tool by nature, and while consumer-driven contract testing is the richest and most powerful of the different approaches to contract testing, it is not necessarily the best fit for every team and every context. It’s a classic example of using the wrong tool for the problem at hand, because they didn’t take enough time looking at the problem and the available solutions. That’s not the problem of Pact, even though it is often framed that way (‘Pact didn’t solve my problems, therefore Pact is not a good tool’). That’s a ‘we didn’t fully understand the problem and the context’ problem. Contract testing removes the need for communication Another challenge that I often see when I talk about or help teams with contract testing is the fact that teams don’t talk to each other. This then leads to integration issues, because team A expects something from team B that team B doesn’t supply. Contract testing is not the solution to these problems. It can’t be - tools alone do not solve problems, let alone communication problems. What contract testing does do is make potential integration issues visible early on in the development process, often earlier than (again) more ‘traditional’ approaches to integration testing. That’s where the value of contract testing can be found. It is not a means to replace communication between teams. In fact, and this is especially true for consumer-driven contract testing, contract testing cannot succeed without good communication between consumer and provider teams. Contract testing replaces all other types of integration testing This one comes up less often than it used to, but sometimes, I still hear people saying that when they will have contract-based integration tests in place, they don’t need other types of integration tests anymore - including E2E tests. That’s simply not true. While contract testing is a great way to find out earlier about the impact of a change in a specific consumer or provider further downstream, in many cases, I wouldn’t rely on these tests alone before moving to production. Because of its asynchronous nature, contract-based integration testing only verifies whether a consumer and a provider speak the same language - can a consumer understand the message returned by a provider in a specific situation? It does not verify that the request or the response message reaches the other party in the first place, for example. In other words, it doesn’t test connectivity between a consumer and a provider. And because integration testing is broken down into individual consumer-provider pairs, you don’t see the entire system working ‘as a whole’. This means you might want to keep a few end-to-end tests in place, even when you’ve got good contract testing coverage across the board. The above is not a complete list of challenges with contract testing, but the ones I mentioned here are those that come up most often.
Have you seen this? If you haven't, you should. I think everyone needs to. Wealth inequality on a scale this extreme is almost impossible to explain. You have to experience it to understand. Go ahead. Try it out. Where is the top of this graph? Good question. Keep
Slop is without a doubt everywhere. Be it in restaurant’s menus, music playlists, or online game storefronts, it is now impossible to escape it. Yet, I’ve never met anyone who was actually looking forward to consuming that. No matter how hard it’s shoved down our throats, the human longing to connect with other people through art still remains. Raymond Kotewicz They will not let you filter A simple solution would be to have slop filters. Automatically label AI-generated trash, and let users hide it if they don’t want to see it. So far, I don’t think any of the major internet platforms has implemented this. The common excuse for why they don’t let you easily filter out slop is that it would be technically too difficult. Let me be clear with everyone here: this is complete bullshit. We’re talking about companies that can hire some of the most talented engineers in the world. I don’t think anyone seriously believes they can’t come up with a way to guess if a file has been generated by AI or not. 90% of the slop out there stands out so much everyone can see how it was made after looking at it for 5 seconds. A more plausible reason for the lack of slop filter is that they are simply testing out the waters. They are checking if users will tolerate it. The question tech executives want answered is: will people buy this garbage? And if the answer to that question is yes, here’s what they will do: they will start generating it themselves. They don’t need the useless meat proxies who think typing ten words and pressing enter makes them creative. They definitely don’t want to verse anyone royalties when they could just be making a one time purchase of tokens. If you think this is not real, just ask Tim Sweeney. I bet he will be more than happy to confirm. Roman Navarro Curation by humans for humans So now that it’s clear that tech companies will not save us from drowning in slop, it’s time to turn back to actual humans instead. The good news is they are a lot of people who are here to help you. There are thousands of people on the internet who will search through mountains of content to find the perfect piece of art they want to share with the world. We don’t explicitly call them curators. They are streamers, bloggers, journalists, DJs, overly enthusiast fans, or simply your friends. Some of those people are seriously amazing. There are DJs out there who will spend thousands of hours digging through crates to craft you the perfect ninety minutes of music. Why do you still need those machine-generated playlists? The alternative to blindly trusting the output of a recommendation algorithm isn’t always to become an expert in every field of art. Sometimes you just have to put the trust you had in a machine back into another person. Back to the real world? The real long term solution would be to stop relying only on the internet for distribution. This is already a thing in the music industry. Every city has a record shop that will sell you a carefully selected set of vinyls. For many musicians, physical sales (and concerts) are a much better source of income than streaming. The same goes for the movie. While text-to-video AI is a thing, the real money isn’t made by generating 30 second TikTok dramas. The real money comes from people paying tickets to see a full-length movie in a theater. Sadly I’m not too optimistic about my own field: video games. Somehow it seems the direction we’ve taken is the opposite. We’re all in on online distributions platforms. We have fully accepted them as our new digital overlords. Next month GTA V is coming out without a disk in the box. Sony already announced that the next Playstation will not support physical media. Physical distribution is not even mentioned in the pitch of the average indie publisher. In Breda, the small Dutch city where I live, we used to have two dedicated video games shop. Higher interests rates, expensive rents, and various policy failures have done their jobs: they are both closed. I don’t think this is a good sign for the survivability of the gaming industry.
Understanding how assigning anthropomorphic traits to agents can improve their effectiveness and interaction.
