What exactly are you trying to highlight here? Most code has bugs. This one is someone forgetting to stick to actual behavior described in 1997, it's a mistake, mistakes happen. Which one of "secure", "simple", "battle tested" and "no crazy architecture" do you think this disproves?
By "no crazy architecture" I meant it avoids the modern trend of building monstrous data platforms on top of data meshes, event buses, and layers of cloud abstractions. The kind I sometimes see, hence the smiley :-)
The Linux kernel needs to adopt better testing methodologies because they're almost entirely reliant on meatcloud CI than provably-correct code with invariant contracts.
> When publishing software, you make a promise to your users.
Just to add on to that. Beyond a promise, it's a contract, and someone has to be responsible and accountable for it.
Like when you're walking or driving and see a traffic light... you don't stop to wonder if there's a race condition or if another signal is out of sync. You trust it and act.
Unfortunately, it feels like in software today, promises are made... but rarely kept. And worse, most people just seem to accept that. If traffic lights were broken, we'd just need to upgrade to the next version right?
By definition the vast majority of software publishers are not that virtuous or credible.
Hence why large businesses pay a lot of money to get guarantees in writing from reputable firms, even though the nominally same software may be available for free.
Pretty much. Everything is about prompt now. Its either "You aren't prompting right", or "Need to prompt harder/more accurately/etc". The only skill that matters now seems to be using a paid vendor product (pick your favorite proprietary AI chatbot) - which isn't really a long term skill at all nor really all that technical.
Whether its true or not it is besides the point - its getting kind of boring and it seems to be drowning everything else. It feels at least from the outside like a profession that used to require intelligence/skill, and something creative problem solving just went downhill fast. The anti-SWE crowd (e.g VC's, AI devs, CEO's, etc) seems to be winning the argument at the moment as to what the future will bring in these forums. Every podcast I hear its always software engineering that is mentioned as the industry to be disrupted away.
Who would of thought the job of the future only 5 years ago would be the first to go? Hope I'm wrong, but it seems the AI crowd's main target atm.
If people feel that they need to learn different language patterns in order to communicate effectively in their native language with an LLM then I'm not sure if I agree. I think that if your native language truly was a programming language then there wouldn't be any need for prompt engineering.
Regardless, I think that programmers are quite well-suited to the methods described in the article, but only in the same way that programmers are generally better at Googling things than the average person; they can imagine what the system needs to see in order to produce the result they want even if that isn't necessarily a natural description of their problem.
As an engineer, if you’ve had a skilled Project Manager you’ve receive detailed, thoughtful “prompts” on how to complete a project that leads to a shared understanding. But with unskilled Project Managers you might receive a vague “prompt” that leads to ambiguity and misalignment. And Project Managers can go through training or read books on how to effectively “prompt” (aka communicate) more effectively.
When I say that your native language is now a programming language, I mean that you are now the Project Manager, and the code is generated automatically. But because the code is auto-generated, the focus shifts towards the “prompt” as the first and potentially only step in generating code.
Tigerbeetle really seems to be pushing the limits of software engineering culture. Too bad Zig is so niche. It's hard to carry those ideas, lots of them comptime, over to Java, Python, or Go.
QUIC was not designed for server-to-server. In that use case, you’ll [1]likely experience poor performance due to higher CPU usage (since QUIC is a user-space protocol without TCP optimizations at the kernel/NIC level) and lower throughput.
[1]This is based on public benchmarks, try searching for `TCP vs QUIC`
> 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers
If you think a great (10x) engineer has bad social skills, isn’t a good mentor, and isn’t a strong teammate… you’ve never actually worked with one. What truly makes someone a great engineer is being technically impeccable and having next-level soft skills.
I once worked with a 10x engineer who I could hand new backend APIs to and have a brand new ui component that supported the behavior in less than a day, consistently. I have worked with 10x engineers who spend hours on calls walking junior engineers through problems they're having. That's part of being a 10x engineer – what this article is talking about is random 1x engineers with a chip on their shoulder and unshakeable arrogance.
Not sure if this was your intention, but you’ve pulled these words out of context, making it seem like the author is making this claim, when in fact the author writes that to describe what others claim.
> Most of us have encountered a few software engineers who seem practically magician-like, a class apart from the rest of us in their ability to reason about complex mental models, leap to nonobvious yet elegant solutions, or emit waves of high-quality code at unreal velocity.
> I have run into many of these incredible beings over the course of my career. I think their existence is what explains the curious durability of the notion of a “10x engineer,” someone who is 10 times as productive or skilled as their peers. The idea—which has become a meme—is based on flimsy, shoddy research, and the claims people have made to defend it have often been risible (for example, 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers) or blatantly double down on stereotypes (“we look for young dudes in hoodies who remind us of Mark Zuckerberg”). But damn if it doesn’t resonate with experience. It just feels true.
> I don’t have a problem with the idea that there are engineers who are 10 times as productive as other engineers. The problems I do have are twofold….
Exactly. While 10x (or whatever) is possible on pure technical ability, I would argue that the majority of engineers who provide outsized value do so through enabling others to do their best work and unblocking the wave that raises all the boats, rather than coding by themselves in a dark room.
That is a nice theory. But if someone is doing 10x more work, they get 10x more emails, and 10x more mentoring. They are not rude, just very very tired!
10x devs do not do mentoring and "social skills", because it does not scale. They write readme, maybe record a video, and move on to next task. If you have a question, send email and you get response latter! Sitting all day on meetings kills productivity very fast!
Buttering someone up, just because they are lazy to study documentation, and somehow they have power over you, is not a team work!!!
Me too. I completely forgot the standard library and basic syntax of my daily language. wow. I went back to VSCode and use Cursor for the AI model to ask questions.
Are you hiring junior or lower-budget developers? That might explain your experience. I've worked with great engineers in Spain, but of course, like anywhere, quality varies.
>NFS with Kerberos
secure, simple, battle tested. no crazy architecture
works so well a bug showed up in the kernel :-)