Jekyll2026-09-05T13:03:10+00:00https://oboe.github.io/feed.xmloboeShort notes on software, systems and whatever else is holding my attention.oboeThe lindy effect2026-05-24T00:00:00+00:002026-05-24T00:00:00+00:00https://oboe.github.io/2026/05/24/the%20lindy%20effectsomething I think is an interesting heuristic to have is. the the idea that that the future life expectancy of non perishable things is proportional to their current age. aka probabilistically if you’re observing something you’re probably observing it somewhere in the middle of of its life expectancy.

theres a few ways to apply this but to me at least it applies to books and software. so that a book thats stood the test of time must be worth reading. and the counter point being that new things are very often not worth consuming.

]]>oboeBoredom and quitting2026-05-03T00:00:00+00:002026-05-03T00:00:00+00:00https://oboe.github.io/2026/05/03/boredom%20and%20quittingrandsinrepose.com/archives/bored-people-quit

This article nicely talks about an effect ive also noticed in workplaces is that the lack of constant work is often one of the main causes for people to quit.

Theres an even interesting possible subconscious artefact of this is that maybe people do recognise this and maybe this is why they can needlessly add complexity to projects that don’t need it, just to fill their time and minds.

You also see this being used as a toxic workplace thing in some workplaces, where people who are disliked are told to simply not do any work at all and sit in a room.

]]>oboeJit Websites2026-02-08T00:00:00+00:002026-02-08T00:00:00+00:00https://oboe.github.io/2026/02/08/jit-websitesWith the advent the cost of code gen dropping to zero with llms, felt an interesting idea is the idea of a webserver which will auto gen a website on url hit. A kind of bootstrap method to create the illusion of a infinitely spanning library.

Theres a few benefits of this.

  1. SEO: you can drastically expand the amount of URLs you cover
  2. Reach: you can serve a huge long tail of customers you wouldn’t have realised exist.

Now the thing to consider is what kinds of websites might be interesting.

  1. Auto generating blog posts
  2. Auto generating stories
  3. Auto generating data?
  4. Auto generating reviews?
]]>oboeOn what the future of ai looks like2026-02-08T00:00:00+00:002026-02-08T00:00:00+00:00https://oboe.github.io/2026/02/08/on%20what%20the%20future%20of%20ai%20looks%20likebrooker.co.za/blog/2026/02/07/you-are-here

  1. The cost of turning business logic into code has dropped to zero
  2. The cost of integrating services and plumbing has dropped to zero
  3. The cost of building efficient reliable secure end to end systems has dropped to zero

So whats next?

Where does that leave those who have careers built on technology? Either:

  1. the end of programming, it is no longer a craft
  2. the birth of opportunity: new fields, new opportunities, new industries

The main point is that yes writing code has dropped to zero. But theres a long list of things that go into building software systems that aren’t code. Weird feedback loops, human stubbornness, adversaries and good ideas. The bottleneck will simply move from code to something else.

]]>oboeTribe Capital Bolt2025-10-12T00:00:00+00:002025-10-12T00:00:00+00:00https://oboe.github.io/2025/10/12/tribe-capital-bolttribecap.co/bolt-perfecting-the-checkout-experience

Bolt initially has two products

  1. A streamlined online checkout, amazon like experience
  2. chargeback protection

Wedge: the checkout experience

Then using that to move into identifying fraud, high value customers, coupon clippers, customers who can be reactivated, etc.

Interesting trend of owning an interface and them building out adjacent products from the data that wedge collects.

]]>oboeTribe Capital Hive Networks2025-10-12T00:00:00+00:002025-10-12T00:00:00+00:00https://oboe.github.io/2025/10/12/tribe-capital-hive-networkstribecap.co/the-hive-is-the-new-network

A simple callout that networks become more valuable as their connections have:

  1. more frequency
  2. more bandwidth

Such as the Mail > Email > Telegram > Whatsapp > Twitter

  • Of increasing frequency

Or the Facebook > Instagram > Snapchat > TikTok

  • Of increasing bandwidth from text to images to video

This framing makes the VR/AR conversion seem almost inevitable.

]]>oboeTribe Capital Kapital2025-10-12T00:00:00+00:002025-10-12T00:00:00+00:00https://oboe.github.io/2025/10/12/tribe-capital-kapitaltribecap.co/kapital-thriving-in-a-desert

An analysis on Kapital, the company.

They first started with a dashboarding software as a wedge, then moved into a large platform, offering loans, credit cards, expense management and other financial services.

Main product offerings being, loans, credit and debit cards and invoice management.

Problem: Tackling this issue because SME businesses are underserved by loans.

Insight: They can use the metrics from the dashboarding software to help underwrite its customers successfully. Enabling them to get a low default rate.

Mentions about the idea of cohort expansion. The idea that old cohorts don’t deteriorate but actually increase spend over time.

Previously fintech companies focused on scale metrics, GTV (gross transaction volume) or TPV (total payment volume). Article highlights to focus more on operating efficiently.

Apparently dashboard product has a 100% retention to date. Kinda absurd.

]]>oboeWhat to spend your life on2025-07-26T00:00:00+00:002025-07-26T00:00:00+00:00https://oboe.github.io/2025/07/26/What%20to%20spend%20your%20life%20onA common theme i’ve noticed with myself and talking to my peers is that its very easy to get into a rut or a plateau in your life, a comfortable life doing the same things each week. Not that thats bad or anything but many people have an underlying want to break out of this, but are unclear on how or what they even want to break out to.

What do you actually care about?

One way we can tackle this is by listing what your values are and working back from those.

Innately what do you care about and want?

  • Is it money?
  • Is it fame?
  • Is it power?
  • Is it adventure?
  • Is it knowledge?
  • Is it be useful to the world with your skill set?
  • Is it human connection?
  • Is it creative expression?
  • Is it autonomy?

And why do you want those things? Which of these do you care over others?

Is what you’re doing getting to where you want?

So now that you have your values we can revisit the actions and decisions you’re making today. Does your job fulfil your values? What do you do on the weekends to compensate?

A framework to help think about your actions further is with the regret minimisation framework.

When you’re 80 years old looking back at your life. What choices are you making today would you regret?

Common pitfalls

Money

Why is it really at the top of your list? Why do you need it?

Is it so you can more easily go on adventures later? Why not just go on adventures without depending on the money step?

Borrowed dreams

Another area which is dangerous is that your ideas are heavily influenced from the ideas you hear and which are around you.

The ideas you hear about something, you’ll forget, and next time you think about that thing, you’ll accidentally regurgitate that idea you heard as your own. Thats how it works.

So truly think about the ideas you hold. Are they actually yours?

Status games

We unconsciously compete over our peers for things we don’t even want: the biggest house, the most prestigious job title, the most followers. Do you actually want these things or are you just competing?

So what are you going to do about it?

You have your values, you know what you should prioritise, are you going to keep doing what you’re currently doing?

You only have a thousand or so weeks left.

]]>oboeOn reviewing code2025-07-26T00:00:00+00:002025-07-26T00:00:00+00:00https://oboe.github.io/2025/07/26/On%20reviewing%20codeWorking at a place that is dominantly online and not in office I’ve come to realise that a large proportion of the value we produce is not in the code you write but in the code you review as well.

If this is true, it makes a lot of sense to invest in the skill of reviewing code as much as I have already invested into the art of coding.

This post aims to tackle as a guide and cook book for performing better code reviews.

What is the purpose of a code review?

A good way of thinking about a code review is as a process of adding value to existing code.

So how can you add value to existing code?

  1. Make it more simpler
  2. Make is more correct
  3. Make it more performant

Another perspective is that the purpose of a code review is to fight against the natural nature of a codebases, they deteriorate in quality over time. Like a ratchet each time you loosen the bar, it stays there, and never goes back. The core principle being:

In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.

What to figure out in a code review?

The functionality

  • Does the code do what the developer intended
  • Is what the developer intending necessary
  • Are there any edge cases
  • Are there any concurrency problems
  • Are there any bugs
  • Can it cause deadlocks or race conditions

The complexity

  • Can it be simpler
  • Is it too generic
  • Is it solving additional problems

The tests

  • Are there tests?
  • Are there all the tests for edge cases
  • Are the tests simple

The naming

  • Do the names make sense?

The comments

  • Are the comments necessary
  • Are there comments explaining why some code exists, not how it works

The observability

  • Can I detect that this code fail
  • Is there any visibility loss?

The style

  • Is it well indented?
  • Is it consistent with the codebase?
  • Do I want to maintain this?

The broader context

  • Is the code improving the code health of the system or is it making the whole system more complex
  • Don’t accept code that degrades the code health of the system, THEY ADD UP.

The good things

  • What are the good things, you like

In summary

  • The code is well-designed.
  • The functionality is good for the users of the code.
  • Any parallel programming is done safely.
  • The code isn’t more complex than it needs to be.
  • The developer isn’t implementing things they might need in the future but don’t know they need now.
  • Code has appropriate unit tests.
  • Tests are well-designed.
  • The developer used clear names for everything.
  • Comments are clear and useful, and mostly explain why instead of what.

How do you actually do a code review

  1. Does the intent make sense?
  2. Look at the most important part of the change.
  3. Look at the rest of the code.

Does it make sense?

  • Does the description make sense
  • Is it needed

Look at the core logical impl

  • Try to find major design problems first, so you don’t need to review the rest of the impl.
  • Major changes take a while so you want to give feedback quickly

Look at the rest

  • Review all the files, now with the context of whats happening

On speed

The velocity of the team is dependant on iteration speed, so quick reviews are the life blood of the team. You should do a code review shortly after it comes in!

On pitfalls

  1. Don’t have multiple round trips, reduce this time as much as possible
  2. Don’t make it a ransom note, don’t hold the review hostage
  3. Don’t have two conflicting reviewers fighting with each other
  4. Don’t have a guessing game. Don’t just criticise the solution and not give a solution. Make it specific. Not a vague hammer to hit them.
  5. Start with the bombshell, not the nits. The nits come after the major design reworks.
  6. Never flip slop between your thoughts.

On comments

General idea is to do something like this

  1. What is wrong with the code?
  2. Why is it wrong?
  3. How to fix it? Be actionable!

And to place color on

  • Is it blocking?
  • So they don’t waste time on bikesheds!

Something to consider is labelling comment severity

  1. Nit: This is minor
  2. Optional: I think this may be a good idea
  3. FYI: Could be interesting

Additional principles

  • Never say the word you in a code review: never attack the author, say WE!
  • Use the passive voice. Only ask questions, What about renaming this variable?
  • You aren’t commanding them, you’re suggesting ideas to make this code better.
  • Tie your feedback to principles.

And finally on the other side, what should you consider as the author

A pretty fun graphic from cisco code reviews shows that at most 400 lines of code, the amount of issues you can notice significantly diminish. So try to split it up!

What makes a code review small?

  • It does one thing
  • It tests that one thing
  • What are the implications of this one thing

So how can you split up a change?

  • Stack changes, pull out precursors and incrementally contribute
  • Split by files, update each file change independently
  • Split horizontally: design your code in such a way that you can easily cut multiple code reviews without them interfering
  • Split by intent/ logical change
  • Split out refactors

Appendix

github.com/google/eng-practices/blob/master/review/index.md

chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns

philbooth.me/blog/the-art-of-good-code-review

bitfieldconsulting.com/posts/code-review

lindbakk.com/blog/code-reviews-easy-in-theory-difficult-in-practice

smartbear.com/learn/code-review/best-practices-for-peer-code-review

mtlynch.io/human-code-reviews-1

mtlynch.io/code-review-love

]]>oboeSwe interview master garden2025-06-07T00:00:00+00:002025-06-07T00:00:00+00:00https://oboe.github.io/2025/06/07/SWE%20interview%20master%20gardenAfter getting a few offers, here’s what I did and would do again if I needed to get a SWE job again.

The legs of the SWE interview chair are:

  1. Coding
  2. System design
  3. Behavioural

You’re going to get interviews in these areas and each company will have slight different flavours to these. My recommendation is to first do the basic prep and then focus in on companies when those interviews have been booked in. This means grepping through glassdoor for every past interview question and doing them.

On general application strategy apply to a crap ton as the more interviews you do the better you’ll get, my guess is that you’re pretty much guaranteed to fail your first one.

Coding

USE PYTHON. Some interviews cough cough stripe are impossible to do in verbose languages. Python is by far the best language to concisely explain standard interview concepts, outside of heap, but what are the chances someone asks you a heap question. lmao.

The prep is simple, just do leetcode. Here’s a nicely structured list of 150 questions. They will get easy as you do them.

System Design

First learn the basic concepts then learn the structure of how you should answer them and just choose a question and spend 30 minutes just writing down in a doc all your answers for each of the sections. As you do enough questions you’ll learn that all of the questions are pretty much the same, put a load balancer infront of a host with a db. Wow how simple. Then dump your structured answer into chat gpt and have it ask 10-20 questions on you. The llm feedback loop was extremely useful and would highly recommend.

Concepts:

How to answer a system design question:

Questions (DONT CHEAT AND READ THE LINKS, JUST READ THE CONSTRAINTS AND DO THE QUESTION ALONE FIRST):

Behavioural

Behavioural’s are just vibe checks. Theres really only a few things you need to tell who are you and why you’re the goat fit. Be interested and passionate!

Who are you:

Why you’re the goat fit:

Final questions:

Finance

Wow a surprise section, some smaller companies such as those in finance will ask more specific questions to hire for spikes. Usually this means knowing a specific language or knowing some sort of CS better, most likely operating systems. Usually they can’t actually ask you some real in-depth stuff so just reading the language docs or resources is pretty sufficient.

  • What are the cache locality of data structures
  • How are maps implemented under the hood
  • Do some threading
  • Do some naive implementations of cpp shared ptr, unique ptr, tuples
  • Stack and heap memory knowledge

Closing

With this process the main thing to note is that your goal is to hold an auction for your time with as many companies as possible. You want to get as many offers at possible at the same time. To do this when you get one offer, let every other company know and that you want to accelerate the process with them because you love their company.

Negotiating for dummies:

]]>oboe