Code Assistants: Blurring Category Lines
The RAG Challenge: A GitHub Copilot Experiment
🔗 Software Is Bananas
Kent Beck has shared some good insights in his substack. If I have to start with something, this is probably it. This post takes a short and stingy look around real “aglileness” of software development. Short but quick deployments and closer feedback loops instead of long and drawn out processes. Because at the end of the day, there is one bug lingering only in production enviorment which is waiting to be revealed.
Software is bananas. Buy a banana and you’d better eat it. You’re not going to be happy with the experience in a month.
Interesting to see me using the “rotting food” metaphor in another context. I think I’m trying to sensitize people to the cost of delay. Somehow some folks just don’t feel it.
🔗 Choose Boring Technology
Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps.
You can replenish the tokens if you can to hire more people who brings new innovation tokens with them.
If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble.
Write own database should be worth 9 innovation tokens in this scenario.
Any of those choices might be sensible if you’re a javascript consultancy, or a database company. But you’re probably not. You’re probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail. Or at best, delay success.
Above paragraph is the most important paragraph every company should have printed instead of those innovative inspiring posters.
The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
The problem with “best tool for the job” thinking is that it takes a myopic view (aka short term) of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible.
Be it elections or tech, chosing least worst is most essential thing we forget or refuse to do…