koliber

Face to face tests of coding ability could work.

The problem is on both sides.

Companies are sometimes too selective and too indecisive.

Many candidates can't code well.

I screen candidates all the time. I regularly meet Sr. Java Engineers who are not aware of the classes that exist in the standard collections framework and can't pick the right one for the job. People who claim to be "performance experts" who can't explain how a HashMap performs an addition in amortized constant time. I get it -- this is not required knowledge for all roles. But don't call yourself an expert and use some judgement as to the kinds of roles you apply for.

As with cold fusion, I think the answer is "it will happen", but no one can predict how soon.

Using vibe coding to build a small specialized tool for a small company that can be used instead of single feature of a commercial SaaS is doable and brings value.

Using vibe coding to build something to replace an enterprise SaaS offering for a medium to large company is not something to be taken lightly. The tool and the code is not everything. The operating environment, security guarantees, SLAs, support, and a bag of features you don't need today but might tomorrow is what the SaaS offerings bring to the table.

Imagine that I run a really good software house. I can literally build anything you want, feature wise, better than most. I do it quickly. You come to me and say you want to replace Slack for your team of 200, because Slack got too expensive. I say I can do it. Because I am feeling generous and you're my good friend, I will do it for free. However, I will just give you the code, a CI/CD script, and a README.md file. I will disappear and will not maintain or support your software, nor will I give you any guarantees on how well it will work, other than a "trust me."

I wouldn't take the offer.

This happens with human-generated executive summaries. They can omit seemingly-innocuous things, focus on certain areas, and frame numbers in ways that color the summary. It's always important to know who wrote the summary if you want to know how much heed to pay it.

This is called bias, and every human has their own. Sometimes, the executive assistant wields a lot more power in an organization than it looks at first glance.

What the author seems to be saying is that the system prompt can be used to instill bias in LLMs.

This kind of correlates with a wisdom I've heard before:

You don't suffer from a lack of time, but rather a lack of energy. And actually, you don't suffer from a lack of energy, but a lack of activation energy.

We colloquially refer to activation energy as motivation. But maybe that's not the whole story. Some of it is willpower and personality, but maybe some of it is a buildup of adenosine.

This squares with my personal experience. It's harder to start things after day's worth of intense mental effort.

Am I getting Steve's point? It's a bit like what happened with the agricultural revolution.

A long time ago, food took effort to find, and calories were expensive. Then we had a breakthrough in cost/per/calories. We got fat, because we can not moderate our food intake. It is killing us.

A long time ago, coding took effort, and programmer productivity was expensive. Then we had a breakthrough in cost/per/feature. Now we are exhausted, because we can not moderate our energy and attention expenditure. It is killing us.

The article is gone, but going off the title here...

If the easy stuff takes up 90% of the time, and the hard stuff 10%, then AI can be helpful. Personally, I can do "the easy stuff" with AI about 3-5x faster. So now I have a lot more free time for the hard stuff.

I don't let the AI near the hard stuff as it often gets confused and I don't save much time. I might still use it as a thought partner, but don't give it access to make changes.

Example: this morning I combined two codebases into one. I wrote both of them and had a good understanding of how everything worked. I had an opinion about some things I wanted to change while combining the two projects. I also had a strong opinion about how I wanted the two projects to interact with each other. I think it would have taken me about 2 workdays to get this done. Instead, with AI tooling, I got it done in 3 or so hours. I fired up another LLM to do the code review, and it found some stuff both I and the other LLM missed. This was valuable as a person developing things solo.

It freed up time for me to post on HN. :)

There is a whole range of variants in between those two "artistic vs utilitarian" points. Additionally, there is a ton of variance around "artistic" vs "utilitarian".

Artisans in Japan might go to incredible lengths to create utilitarian teapots. Artisans who graduated last week from a 4-week pottery workshop will produce a different kind quality, albeit artisan. $5.00 teapots from an East Asian mass production factory will be very different than high quality mass-produced upmarket teapots at a higher price. I have things in my house that fall into each of those categories (not all teapots, but different kinds of wares).

Sometimes commercial manufacturing produces worse tolerances than hand-crafting. Sometimes, commercial manufacturing is the only way to get humanly unachievable tolerances.

You can't simplify it into "always" and "never" absolutes. Artisan is not always nicer than commercial. Commercial is not always cheaper than artisan. _____ is not always _____ than ____.

If we bring it back to AI, I've seen it produce crap, and I've also seen it produce code that honestly impressed me (my opinion is based on 24 years of coding and engineering management experience). I am reluctant to make a call where it falls on that axis that we've sketched out in this message thread.

Sometimes you want an artistic vase that captures some essential element of beauty, culture, or emotion.

Sometimes you want a utilitarian teapot to reliably pour a cup of tea.

The materials and rough process for each can be very similar. One takes a master craftsman and a lot of time to make and costs a lot of money. The other can be made on a production line and the cost is tiny.

Both have are desirable, for different people, for different purposes.

With software, it's similar. A true master knows when to get it done quick and dirty and when to take the time to ponder and think.

Strange. Never had it happen regularly in the US.

Yes.

I've seen an interesting behavior in India. If I ask someone on the street for directions, they will always give me an answer, even if they don't know. If they don't know, they'll make something up.

This was strange. I asked a lot of Indian people about it and they said that it has to do with "saving face". Saying "I don't know" is a disgraceful thing. So if someone does not know the answer, they make something up instead.

Have you seen this?

This behavior appears in software projects as well. It's difficult to work like this.

I am exploring ways to do it that fit my style.

First of all, the limiting factor is my attention. Even when I really tried to do this in parallel I could not meaningfully run more than three sessions.

I realized that some of the attention is devoted to thinking how multiple agents could step on each others toes as and end up creating merge conflicts when it came time to merge.

I have multiple projects and if I feel I have capacity to do parallel coding, I do it in unrelated code bases.

Sometimes I do super async work - as in one interaction per hour or so. I do it while walking, waiting in line, or between meetings. I found web based Codex to be decent for this. I guess it’s in parallel with my Claude Code sessions.

You're right. However, all insurance needs to get more in premiums than it pays out in claims in order to be viable. The details will differ about whether there is some kind of bias for certain people to pay more and claim less. With socialized healthcare, the coverage is just much broader and there is less room for "gaming" the system.

Healthy young people are less likely to buy insurance than sick older people. But if only sick older people buy insurance the payouts per insured are going to be higher. That in turn causes high premiums. Insurance works if everyone buys in, pays while they are young and relatively healthy, and gets paid healthcare when they are older and sicker.

If you “game” it, it breaks the whole system.

Now some of you might be thinking “why should a young and healthy guy like myself subsidize the old sick people?” The answer is that you will also get old.

I love the name. I’ve been doing this for a while. My name for it is super boring “todo archive” but I am renaming it next year.

Keeping an archive of things I’ve done is great for my mental health. Occasionally, I even look search through it and the associated notes and fish out something useful.

Some of the positive sunlight exposure benefits are trivial to see.

- running around outside, because physical activity if healthy

- spending an afternoon in the company of good friends or family

- gardening, which can produce veggies that are pesticide free

Not everything is a biochemical direct benefit of the sun’s rays. Some of the positive effects are a few steps removed.

No one needs to be kicked to do anything. Welfare payments are needed for various reasons. Some people are unable to work for various reasons and need welfare to live. Some people find themselves in temporary situations where the money helps them during hard job transitions or difficult periods in life. It’s important to give people incentives to help them achieve what will make their lives truly better. Sometimes, free money removes those incentives and temporary situations become permanent. I hope you don’t perceive all incentives to encourage constructive behavior as “kicking people.”

I wonder what is the difference between the two groups as far as the rate of finding employment. Might be that the act of looking for a job is stressful.

If the goal is to get people back to work, it might not make sense to optimize just for better mental health.

It's clearer if you deconstruct the conversation about Jira and then think about the washing hair and shampoo comment. It's a stretch, but when you see it is should make sense.

I ask my team to clarify requirements better. They say that they already have Jira. It's as if they were implying that the presence of a tool (Jira) should be enough to provide clear stories. But it's not about the tool. It's about them not using the tool properly but pointing at the tool (or process) as an excuse.

I ask my son to wash his hair. He says there is shampoo in the shower. It's as if the presence of the shampoo implies that his hair should be clean. It's not about the lack of tooling, but about the fact that he did not wash his hair with the tool that he had available.

People often blame tooling or methodology, but most often its that they don't know how to use the tooling or methodology well. They will say things like "if we only used X our problems would go away." Most likely, they won't.

I posted a lazy comment earlier because I did not have time to type it out. Apologies.

That's like me trying to get my son to wash his hair and him responding by saying "We have shampoo in the shower."

I am right and my son is right, but his hair is still not washed.

I became a more effective manager and a better father when I learned how to talk to him better.

Love the title. Reminds me of one of my favorite quotes: "The single biggest problem in communication is the illusion that it has taken place."

This is what user stories were supposed to accomplish in a more lightweight way.

The whole scrum DoR (definition of ready) status means that something is clear and ready for development.

Stories are written and are sent to the engineering team for clarification. This is where the comments are supposed to come in. There is a clear step for clarification of stories, before the story is ready for development. It gets marked as DoR when that clarification is done.

It does not matter if you use RFCs, user stories, or hallway conversations as your process of clarifying work. If it does not work, it does not work.

Any way you can get your teams to communicate more clearly is great.

right. My goof. That adds two more zeroes across all the math. More crazy, but I think in the realm of "maybe, if we squint hard."

right. My goof. That adds two more zeroes across all the math. More crazy, but I think in the realm of "maybe, if we squint hard." But my eyes are hurting from squinting that hard, so I agree that it's just crazy.

NOTE: People pointed out that it's $800 billion to cover interest, not $8 billion, as I wrote below. My mistake. That adds 2 more zeroes to all figures, which makes it a lot more crazy. Original comment below...

$8 billion / US adult adult population of of 270 million comes out to about $3000 per adult per year. That's only to cover cost of interest, let alone other costs and profits.

That sounds crazy, but let's think about it...

- How much does an average American spend on a car and car-related expenses? If AI becomes as big as "cars", then this number is not as nuts.

- These firms will target the global market, not US only, so number of adults is 20x, and the average required spend per adult per year becomes $150.

- Let's say only about 1/3 of the world's adult population is poised to take advantage of paid tools enabled by AI. The total spend per targetable adult per year becomes closer to $500.

- The $8 billion in interest is on the total investment by all AI firms. All companies will not succeed. Let's say that the one that will succeed will spend 1/4 of that. So that's $2 billion dollar per year, and roughly $125 per adult per year.

- Triple that number to factor in other costs and profits and that company needs to get $500 in sales per targetable adult per year.

People spend more than that on each of these: smoking, booze, cars, TV. If AI can penetrate as deep as the above things did, it's not as crazy of an investment as it looks. It's one hell of a bet though.

Imagine that they do skyrocket but the RoboCEO is in charge trillion gets distributed to shareholders.

In the broad picture of engineering, I would consider this to be technically difficult. Many pieces of the puzzle need to interact correctly to remove latency, from physical location, network gear, decision about where software runs, removing unnecessary layers of everything, to algos and data structures, and doing razor-tight tradeoff analysis favoring low-latency at every step along the way. It’s also expensive. So it’s hard to agree that this is not hard. On the flip side, if you find this easy and want a job, msg me.

# Books

## *Trading and Exchanges: Market Microstructure for Practitioners by Larry Harris*

- comprehensive overview written in an accessible way

## *The Microstructure of Financial Markets by Frank de Jong and Barbara Rindi*

- 1st 1/4 of the book is generally useful. Then the math starts. This math is not needed to get a basic overview.

These are two books I wish someone gave to me when I started my first capital markets software engineering job. I recommend them to all the people I place in financial system engineering roles.

This is my passion. Message me if you want to talk more about this — see HN profile for contact info.

One of the most important things about great performers in any discipline is to be adaptive. This also applies to engineering managers. I think the article is correct that it identifies that fads shifted. Great people were able to both adapt to new expectations while all the while adapting their approach to individual situations and people. If you are a one-trick pony sometimes your trick is in line with fads and expectations and you will do well. Sometimes it’s not in line and you will struggle. If you are adaptive you will do well in a changing landscape.