History books can tell you facts that happened, but they can never truly tell you how it feels.
I feel we're riding a knife's edge and there's a hurricane brewing in the gulf of absurdity.
====
Incidentally, I feel like this is why it is so hard to actually learn from history. You can read about the 1918 'Spanish' Flu, but you think "we're smarter now". etc.
We have a simple rule: You commit it, you own it. If you vibe coded it that's okay. If it's garbage that's on you. Blaming the LLM doesn't count. So of course you have to read the code. You have to read it and understand it. Works well for us.
This mirrors insights from Andrew Ng's recent AI startup talk [1].
I recall he mentions in this video that the new advice they are giving to founders is to throw away prototypes when they pivot instead of building onto a core foundation. This is because of the effects described in the article.
He also gives some provisional numbers (see the section "Rapid Prototyping and Engineering" and slides ~10:30) where he suggests prototype development sees a 10x boost compared to a 30-50% improvement for existing production codebases.
This feels vaguely analogous to the switch from "pets" to "livestock" when the industry switched from VMs to containers. Except, the new view is that your codebase is more like livestock and less like a pet. If true (and no doubt this will be a contentious topic to programmers who are excellent "pet" owners) then there may be some advantage in this new coding agent world to getting in on the ground floor and adopting practices that make LLMs productive.
- Posted that three federal judges "deserve to die" with their photos and addresses
- Result: Conviction overturned as protected political hyperbole
Connolly's "set fire to all the hotels" would likely be viewed as angry hyperbole in the United States, not meeting Brandenburg's strict standard.
The distinction: The US prosecutes actual incitement (directing a mob to attack a building RIGHT NOW). The UK prosecutes offensive speech that merely might inspire someone, somewhere, someday. Your Brandenburg citation actually proves this difference rather than refutes it.
You want thousands of examples? Check Twitter during any US political crisis - they're not prosecuted precisely because Brandenburg protects them.
Outside of differences between assertion-based unit tests and property-based tests (both of which are worth doing), I don't think framework makes much difference. But your approach to testing definitely does.
I think every language having its own testing framework is good, even for things like functional tests which can often be externalised. Tests are an essential part of every project and should be well integrated with the rest of the codebase and the team creating it. Often, the tests are the only good place to go and see what an app actually _does_ and so they form an essential part of the documentation.
In my experience it's very rare that you can effectively create and maintain something like Cucumber tests owned by anyone but the team implementing the code so there's little benefit to translating from a text DSL like that. But the language used is definitely useful, so what I like to see is code in the implementation language that matches the Given/When/Then structure of those tests, but instead of reusable text steps you just have reusable functions which take parameters. This means you can easily refactor, and use the full functionality of your IDE to suggest and go to definitions etc. No matter what, you should treat your test code the same way you do everything else - abstractions matter, so functional tests at the top level should rarely just be about clicking on things and asserting other things, they should be in the language of the domain.
Functional tests are worth much more than unit tests. No only do they test the only things of actual business value, they are also more robust in the face of implementation refactorings and so require less rework (unless you're being overly specific with CSS selectors etc). Unit tests are often highly coupled to specific implementations and can be a poor investment, especially early in a project. I believe a good balance is functional and integration tests that explore the various paths through your app and prove everything's hooked up, coupled with property based unit tests for gnarly or repetitive logic that isn't worth endlessly iterating via the UI. All other unit tests are optional and at the discretion of the implementer.
You should be able to mock out every major articulation point in your code, but it's generally preferable if you can mock _real_ dependencies. That is, instead of mocking out a 'repository' abstraction that looks stuff up and returns canned data, have a real test database against which you look up real data (created by steps in your functional tests). This reduces risk and cognitive overhead (you're not having to encode too many assumptions in your test suite) and doesn't have to be as slow as people like to make out - Embedded Postgres is quite fast, for example:
Same with network services - it's not slow to chat to localhost and you'll find more issues testing proper round-trips. I have not found "assert that you called X" style testing with mocks useful - you care about outcomes, not implementation details.
Beyond all that, as long as you can make assertions that generate clear error messages, you're fine.
I'm very old man shouting at clouds about this stuff. I don't want to review code the author doesn't understand and I don't want to merge code neither of us understand.
I don't want to review code the author doesn't understand
This really bothers me. I've had people ask me to do some task except they get AI to provide instructions on how to do the task and send me the instructions, rather than saying "Hey can you please do X". It's insulting.
Copying from another post. I’m very puzzled on why people don’t talk more about essential complexity of specifying systems any more:
In No Silver Bullet, Fred Brooks argues that the hard part of software engineering lies in essential complexity - understanding, specifying, and modeling the problem space - while accidental complexity like tool limitations is secondary. His point was that no tool or methodology would "magically" eliminate the difficulty of software development because the core challenge is conceptual, not syntactic.
Fast forward to today: there's a lot of talk about AI agents replacing engineers by writing entire codebases from natural language prompts. But that seems to assume the specification problem is somehow solved or simplified. In reality, turning vague ideas into detailed, robust systems still feels like the core job of engineers.
If someone provides detailed specs and iteratively works with an AI to build software, aren’t they just using AI to eliminate accidental complexity—like how we moved from assembly to high-level languages? That doesn’t replace engineers; it boosts our productivity. If anything, it should increase opportunities by lowering the cost of iteration and scaling our impact.
So how do we reconcile this? If an agent writes a product from a prompt, that only works because someone else has already fully specified the system—implicitly or explicitly. And if we’re just using AI to replicate existing products, then we’re not solving technical problems anymore; we’re just competing on distribution or cost. That’s not an engineering disruption—it’s a business one.
I’ve been running k3s on hetzner for over 2 years now with 100% uptime.
In fact, it was so low maintenance that I lost my SSH key for the master node and I had to reprovision the entire cluster. Took about 90 mins including the time spent updating my docs. If it was critical I could have got that down to 15 mins tops.
20€/mo for a k8s cluster using k3s, exclusively on ARM, 3 nodes 1 master, some storage, and a load balancer with automatic dns on cloudflare.
> Builder hired 300 internal engineers and kicked off building internal tools, all of which could have simply been purchased
Dear god, PLEASE hire an actual Enterprise IT professional early in your startup expansion phase. A single competent EIT person (or dinosaur like me) could have - if this story is true - possibly saved the whole startup by understanding what’s immediately needed versus what’s nice-to-have, what should be self-hosted versus what should be XaaS, stitching everything together to reduce silos, and ensuring every cent is not just accounted for but wisely invested in future success.
Even if the rest of your startup isn’t “worrying about the money”, your IT and Finance people should always be worried about the money.
I am co-founder of a 5 year old tech startup with 50 staff that introduced a 4dww / 32hr work week a little over 2 years ago.
Since are a lot of questions surrounding 4dww - Thought I might be able to offer some insights.
1. “four days but actually working longer” or “four days with reduced hours”.
-- We offer 32hrs work week, rather than the standard 40hrs in our home country. This is generally taken as 4 days, but some work 5 days with less ours (especially those with school aged children).
2. "What employers want to know is not what happens in poorly managed offices, but what happens in well managed offices where employee workload was already optimised."
-- I am going to be biased but we spent 3 year with standard work week, and I think we were highly productive as an organisation, our internal metrics, output and surveys agreed with this assessment. After 2 years, we haven't seen any noticeable / measurable decrease in output or performance compared to 5dww, or since we started.
3. "Do these companies close on a week day, like they just don’t open on a Monday."
-- We generally allow people to choose any day off they want, put have them put it in ~4 weeks before hand. Most people take either Monday or Friday, which means we always have some staff covering the days others have off. In smaller teams that speak with customers (sales/cs) they agree among the team who takes what days, and can trade, as long as we always have coverage.
4. "4 days week sounds great, if you hate your job and you already earn less than you deserve."
-- We pay top percentile as other startup/tech companies in our country's HQ. Anyone joining us shouldn't feel they are being paid any less than someone on 5dww -- and that is because we expect their output to match those of others working 5dww.
Overall we've found the move to be extremely successful at attracting and retaining talent with I believe helps us be significantly more productive than other startups I know doing 5dww.
We have a few things that I think help with our 4dww, include remote async with very flexible hours, hiring worldwide, transparent salaries and virtually no meetings in engineering.
One thing this flexibility allows us to do is ask our staff to be 'switched on' when they are working -- if for any reason they aren't being productive, we encourage them stop working, do something else, and come back later. We expect our staff aren't reading reddit, posting on hacker news, etc during work-time -- in return for the 32hrs we want to see it (almost) all productive.
I believe this, along with staff dropped the least important work gives us a similar/same output as 40hrs. With the benefit that we've been able to attract talent that otherwise may have gone elsewhere, with a turnover of virtually 0%.
Happy to answer any specifics about how we've implemented thing, or what I've seen as a co-founder leading a small (16 people) engineering team.
Eric Meyer's posts about his daughter's illness, and the family's lifelong process of grieving afterward, are heartbreaking. It's arresting, gripping writing. It's wonderful and awful. Hug your loved ones tight. https://meyerweb.com/eric/thoughts/category/personal/rebecca...
Huge work to get everybody on the same page (About my previous example, it's not well engaged by example https://github.com/nodejs/node/issues/55419), but when done and right done, it's a huge win for developers.
I've bar raised a ton of them. You do end up figuring out what actions by what operator caused what issues or didn't work well, but that's to diagnose what controls/processes/tools/metrics were missing. I always removed the actual people's name as part of the bar raising, well before publishing, usually before any manager sees it. Instead used Oncall 1, or Oncall for X team, Manager for X team. And that's mainly for the timeline.
As a sibling said you were likely in a bad or or one that was using COEs punatively.
The idea of Rails 8 is to move away from trend following and try to reject some of the ideas that have become popular in the industry (like being afraid to touch a Linux server or implementing your own auth). Really though provoking stuff.
Working from home has advantages, but my boss also cancelled home-office. One big customer of us went for extensive home-office. And since then that company seems to be paralyzed. Workers there are openly doing personal stuff during video meetings. And it became impossible to get any decisions. A lot of people just don't have the discipline to work unsupervised.
Aligning your personal goals with your company's mission can be a game-changer in achieving both professional success and personal fulfillment. When your values and objectives resonate with those of your employer, every project becomes more meaningful, and motivation naturally increases.
Your personal goals become much easier to achieve, and you have more fun achieving the company goals because they're also helping you.
Is this really a criticism? Because this has been the case forever with all security and SIEM tools. It’s one of the reasons why the SIEM is the most locked down pieces of software in the business.
Realistically, secrets alone shouldn’t allow an attacker access - they should need access to infrastructure or a certificates in machines as well. But unfortunately that’s not the case for many SaaS vendors.
Because the EU is not a national government. It issues no passports. It has no citizens. It levies no taxes. It has no army. It's an organisation that coordinates sovereign states. Often it doesn't even set the law directly but establishes a framework that allows it to specify some requirements that national legislative bodies then have to turn into actual legislation. Frameworks for how to talk about things is very apropos for what the EU is and for how it came about.
I am not defending this state of affairs. Simply pointing out that it's a category error to compare it to national governments. I think it would be good if we had more of an EU state. It seemed to be heading there 25ish years ago. But the nation states do have little appetite to cede authority to the central institutions, so that's probably not on the table. And it's also undeniable that as a coordination mechanism the EU has been spectacularly successful. The fact that people treat it as a national government is proof of that.
This inspired me to have Claude 3.5 Sonnet knock out a quick web page prototype for me, using PDF.js to load and render the PDFs to canvas elements and then display visual diffs between their pages.
Two prompts:
Build a tool where I can drag and drop on two PDF files and
it uses PDF.js to turn each of their pages into canvas
elements and then displays those pages side by side with a
third image that highlights any differences between them, if
any differences exist
rewrite that code to not use React at all
My favorite technique for reducing the cost of logging is the same technique that was employed in The Apollo Guidance Computer(though I'm not sure if they did it for cost purposes).
To quote from Annotations to Eldon Hall's Journey to the Moon[1]:
"The Coroner recorded every instruction executed, with its inputs and results, writing over the oldest record when it filled up. When a program crashed, you could punch out a full record of what it was doing in most of its last second and analyze the problem at your ease. I have often wished that PCs offered such an advanced feature."
So essentially buffer all logs into an in-memory circular buffer of capacity N. If a log record is emitted that has a certain severity/level; flush all records from the buffer to disk/clickHouse/grafana/whatever.
The python MemoryHandler[2] almost implements the said technique, except that it also flushes when buffer is full; which is not particularly what I would want.
I also wrote a blogpost[3] about how to log without losing money or context, ~3yrs ago.
Let's assume that AI is human level (it's not, but humour me). Let's assume that businesses can buy an off-the-shelf black box of AI that will run whatever business IT process they want to run. Customer data goes in, actions for humans to perform come out. It's basically an automated call centre full of humans.
Now something goes wrong. A customer isn't getting what they ordered. What do you do about it?
Do you just drop the customer? Well that's lost revenue, or an easy win for another company, you don't want to do that. Maybe you tell the AI to fix the customer in a particular way and hope it will do so. If it does, all it takes is having a human available to fix it (a customer support dept, even if tier 2), but if it doesn't fix it now you still need all the software you needed before to fix it.
I've built line-of-business software before, and I've over-automated things before. Being able to inspect the state of systems, and being able to manually change things in software, is incredibly valuable. This is why spreadsheets run businesses.
My bet is that companies will still mostly buy the software they were buying before, but that some of the interactions with that software that humans would have done before, AI tools will action instead. All the same CMSs, CRMs, ERPs, and other TLAs will exist, they'll just be augmented with AI. They'll probably do some more interesting things with that AI, but they'll still exist in fundamentally the same way. Companies are not going to entrust their business to a black box that sometimes says no.
I think it makes sense when writing css for isolated components - usually ignoring the cascade. Makes it possible to not name things which is a plus in componentworld.
The thing is, it’s the cascade that makes css as powerful and elegant as it is.
And not naming the things comes at the cost of listing all css properties as classes on each element.
I write CSS and must say that in 2024 CSS is an amazingly powerful and elegant language.
If one is willing / given the time to learn it.
Using conventions like ITCSS, a few libraries like https://utopia.fyi and placing colors, font sizes and spacing into variables + the use of a few utility classes provide most of the conveniences of a utility-first framework with no downsides.
I can also see how devs focusing on components prefer utility-first frameworks for the speed of development. Despite the low maintainability and the horrible markup.
This is how Dutch public healthcare motivates its general aversion to medical testing, as many a foreigner finds surprising and incongruent to the generally OK level of healthcare outcomes provided by the system. You can test and detect, but the error margins are often large (so many false positives and/or false negatives), would generate way too much workload to follow up and thereby cost time and money for better leads. Plus, as you say, knowing early doesn't always or even often mean you can actually change the outcomes.
Now, this is what they say... I have tried to find the actual literature they use to motivate their protocols, and apart from occasionally, have not been able to find that evidence. I'd love to have a resource that demonstrates these sorts of things.
> Goodbye MBA mentality and back to Grovian execution and engineering centric culture.
> Intel made huge error when they decided to delay DUV -> EUV transition.
Just as an FYI, that error was made when the CEO was an engineer, not an MBA.
And I find it amusing for folks here to cheer Grovian culture. Andy Grove's management style had all of what people criticize Amazon's culture, on steroids. Indeed, I believe Jeff Bezos took some of the 14 leadership principles from Grove (who was CEO at that time).
I feel we're riding a knife's edge and there's a hurricane brewing in the gulf of absurdity.
====
Incidentally, I feel like this is why it is so hard to actually learn from history. You can read about the 1918 'Spanish' Flu, but you think "we're smarter now". etc.