Quality of code has never had anything to do with which products are successful. I bet both youtube and facebook's codebase is a tangled mess.
Quality of code has never had anything to do with which products are successful. I bet both youtube and facebook's codebase is a tangled mess.
No, you get hired for your perceived ability to (…)
The world is full of Juliuses, which is a big reason everything sucks.
I have met quite a few people who are more focussed on the business than the technology, but those people tend to end up in jobs where the main problems aren't actually technical. Which, let's be honest, is the case in very many tech jobs.
It is always like this. Your ability to socialize will bring you further than any other skillset. The Kennedys for example manufactured their status by socializing. Industry is no different.
If you think this was about IP addresses, well ...
I present, our contact form.
And generational wealth and serious political power.
> Industry is no different.
Based on these comments, maybe some self-reflection is in order, as it seems from the 80% comment that what you mean is that 80% of people are able to adequately communicate.
To be clear: I've never seen people who follow this strategy contribute anything of value, and it's the biggest red flag on a resume. You learn and grow more by seeing things through.
In this case at least it's definitely more than that. Ever since LLMs became a thing, there has been a constant search to find it's "killer app". Given the steep rise in popularity, regardless of the problems, that is now OpenClaw. As they say, the proof's in the pudding; this guy has created something highly desirable by the many.
Talking to bots on Telegram isn't new.
Running agentic loops isn't new.
Giving AI credentials and having it interface with APIs isn't new.
Triggering AI jobs from external event queues isn't new.
Parking state between AI jobs in temp files isn't new.
Putting all together in one product and marketing it to the right audience? New.
At the end, only time will tell how much there really is to this.
It often does, if killer app means popular app.
And I'm not talking about just any kind of assistant, because those are already existing for decades now with various degrees of competence and all kind of flavours.
I have a feeling OpenClaw et al. will only still exist if somehow all of the gaping security holes are ever able to be closed and through some sort of magic, less than 5% of the users get hacked within the next year, but I'm not sure it's even possible to close those holes, since the entire point and usefulness of such tools is to give them root access and set them completely free.
Hugely underestimated comment. That's pretty much the entire point here. Many people didn't know something with these capabilities was already possible. Or some - like me - knew of the potential, but couldn't be bothered/didn't have the time to put the bits together in a satisfactory flow (I'm currently exploring and building on nanobot[0], which is directly inspired by OpenClaw; didn't touch OC because it's in JS and I'm a Python person). Everything came together really well, which is why it's a "killer app". And now the dam has burst there will be customized takes on the concept all over the place (I'm also aware of a Rust "port", Moltis[1]), taking the idea to next levels.
[0] https://github.com/HKUDS/nanobot [1] https://github.com/moltis-org/moltis
Your boss liked Julius. People liked Julius
You're not going to convince people they have to pay more attention to the technical guy that can't string a though together and answers in a grumpy mood
Be more like Julius and you might get more of his laurels
Good luck with that
I've lived in China (as a foreigner) and they have a word for Juliuses. They call them the 'cha bu duo xiansheng' = the 'Mr. Almost ok'.
It may sound preposterous but I'm going to make the argument that sometimes not knowing how things work is a feature, not a bug.
I would assume most people with a little work-experience has encountered the kind of legacy systems which is crucial to the business, yet for whatever reason doing any sort of work on them involves a tremendous amount of friction.
A technical person who knows how this system works in and out will often claim that certain seemingly simple things cannot be done, because of how the system works.
It might be highly impractical, but if we're honest about things, it's all software. It can be changed if we decide to and the company is willing to put in the effort to make it happen. It's clearly possible, but the skilled worked will often present it as an impossibility.
The Julius, not hampered by such knowledge or constraints, will be see a seemingly simple problem, and maybe even imagine what other things would be possible or even "simple" if that problem was solved.
If the Julius manages to get management approval for these ideas, you may actually end up getting management approval for changing/upgrading the base system causing the friction, something the more fact-based engineers would not.
Chances are it's going to be messier than projected, not being delivered on time... But in the long term it might be a net good for everyone involved ;)
You will probably be interested in the concept of Shoshin, or Beginner’s Mind.
https://en.wikipedia.org/wiki/Shoshin
https://en.wikipedia.org/wiki/Zen_Mind,_Beginner%27s_Mind
But that does not describe a Julius. Julius is not someone with an open mind unconstrained by technical debt, but someone who fakes an aura of knowledge while actually understanding very little.
There is a chasm of difference between an eager beginner who questions the way things work and how to make them simpler and someone who promises things which are impossible. Julius is the latter.
Story! Long ago, very long ago, I was working at a tiny Web company. Not very technical, though the designers were solid and the ops competent.
We once ended up hosting a site that came under a bit of national attention during an event that this site had news about. The link started circulating broadly, the URL mentioned on TV, and the site immediately buckled under the load.
The national visibility of the outage as well as the opportunity cost for the customer were pretty bad. Picture a bunch of devs, ops, sales and customer wrangling people, anxiously packed around the keyboard of the one terminal we managed to get logged into the server.
That, and Julius, the recently hired replacement CTO.
Julius, I still suspect, was selected by the previous CTO, who was not delighted about his circumstances, as something of a revenge. Early on, Julius scavenged the design docs I was trying to put together at the time to get the teams out of constant firefighting mode, and then started misquoting them, mispronouncing the technical terms. He did so confidently and engagingly. The salespeople liked him, at first.
The shine was starting to come off by the time that site went down. In a company that's too small for teams to pick up the slack from a Julius forever, that'll happen eventually.
So here we were, with one terminal precariously logged into the barely responding server, and a lot of national eyes on us. This was the early days of the Web. Something like Cloudflare would not exist for years.
So it fell on me. My idea was that we needed to replace the page at the widely circulated URL with a static version, and do so very, very fast. I figured that our Web servers were usually configured to serve index.html first if present, with dynamic rendering only occurring if not. So I ended up just using wget on localhost to save whatever was being dynamically generated as index.html, and let the server just serve that for the time being.
This was not perfect and the bits that required dynamic behavior were stuck frozen, but that was an acceptable trade-off. And the site instantly came back up, to the relief of everyone present.
A few weeks later, the sales folks, plus Julius, went to pitch our services to a new customer prospect. I bumped into one of them at the coffee machine right afterwards. His face said it all. It had not gone well.
Our eyes met.
And he said, with all the tiredness in the world: "He tried to sell them the 'wget optimizer'..."
1. Shut down or shutting down (e.g. team reduced by > 50% since I've been there)
2. Julius removed, endlessly seeking work, keeps getting fired, and can't find a place to call home
The meteoric rise of the Julius is an exception - sooner or later their lucky streak ends and they face the cliff of adversity, towering above them with no way to climb it - no skills to help him actually do it.
I did enjoy your link though.
IMO, all you can really do around one is try to focus on yourself. Or get away as fast as you can, depending on the situation.
No, Julius is not a spectrum. There is a line between being one or not being one. It’s not just a slider between “socially outgoing” and “technically competent”, it describes a particular type of individual.
> Oh and everything doesn't suck.
I think it was pretty clear I didn’t mean literally. Obviously the Sun doesn’t suck, nor does water, nor do an infinity of things which humans could not have as hand it.
in a startup give me unruly pirates over obedient sailors (sj).
(gen)AI is not even a person. And you have to pay for it, in some way
The programmer which delivers useful products is probably hired by Microsoft? Or worse, Boeing. Or Toyota. Some NTSB people or Michael Barr are happy to tell you details about the number of dead people they created.
Restart braking to brake because our code failed.
Or. One single sensor delivers wrong data. Let us put the trim down. DOWN! DOWN!
After that they blame the user. It wasn’t a pilot error, because the didn’t trained the pilots to immediately turn off MCAS. And it wasn’t a driver error, because they didn’t trained driver to lift the feet and start braking again. But I’m only programming a text viewer.
Which is used in a power plant to read the emergency manual, after an earthquake. You are responsible.There, a team lead is doing ~$4000 net per month. So not poverty, but not great either.
If you want to go further into bringing other stuff in I would say, on average, the European folks are only slightly worse off money wise (owning a house there does seem harder overall) but with more security, time off, etc.
In the US there is a much broader range of experiences in the sector, partly because of personal circumstances (student and auto loans being the biggest) and alot because of where you live, as pay tends not to scale with COL. So someone could live like a king in rural Iowa or a pauper in Los Angeles doing the same job.
But if you did build a core innovation in aerospace that went viral I'm sure Airbus would be interested in hiring you.
The salary would be 3K per month. And lunch coupons to buy a ham baguette.
There are only so many companies that think of themselves as safety-first. In practice, basically all companies work on things that should be safety-first.
Does your software store user data? Congrats, you are now on the hook for GDPR and a bunch of similar data handling regulations.
Does your software include a messaging component? You are now responsible for moderating abusive actors in your chat.
Does your software allow users to upload images? Now you are a potential distribution vector for CSAM.
And so on... safety isn't just for things which can cause immediate death and dismemberment
Agreed, though I think that if GDPR fines were actually being levied at the recommended 4% of global revenue, we'd start treating them more similarly to a 737 crash.
> The inconvenience and economic cost of your Discord messages leaking is not the same category of harm as your pacemaker controller failing
Sort of depends who they leak to. Your teen classmates who bully you to suicide? Your abusive ex who is trying to track you down to kill you? The 3-letter agency who is trying to rendition your family to an internment camp?
There are a lot of seemingly benign failure modes that become extremely lethal given the right circumstances. And because we acknowledge the potential lethality of something like a pacemaker failure, we have massive infrastructure dedicated to their mitigation (EMT teams, emergency external pacemakers, surgical teams who can rapidly place new leads, etc). For things society judges less important, mitigations are often few and far between
It allows you to not having to define the point in time and neither the frame of the timespan's points in time.
Some languages allow to use that type of tense and it's somewhat a language gap I suppose. I have no idea what other languages or proto languages allow that tense though, but I've seen some Slavic and maybe Finnish(?) natives use that tense in English, too.
Maybe someone more elaborate in these matters has better examples?
The problem here is that the simple past "He went" uses an auxiliary verb for negations "He didn't go". In this case, "go" is not participated.
Maybe “hadn’t trained” is even better. Makes sense when ordering times. But I don’t trust LLMs an inch. It makes up options for git[1] and both GCC and CLANG are often immediately telling me that the LLM is lying.
Cookieengineer and illichosky are right.
[1] Considering that man pages exist, it shows how useless their harmful crawlers are.
When OpenAI tells someone that suicide isn't that bad, some bs supplement could be the best thing to treat their cancer, or does anything else that has a negative outcome, the consequences are basically zero. That is even though any single failure like that probably kills alot more people per year than Boeing.
It seems there is knowledge of this and the lack of responsibility placed on these companies so they act accordingly.
"Quality doesn't matter" people are why I'm not worried about employment. While there is value in getting features out fast, definitely, there always comes a point on your scaling journey where you have to evolve the stack structure for the purpose of getting those features out fast sustainably. That's where the quality of the engineering makes a difference.
(Anecdotally, the YouTube codebase may be locally messy, but its overall architecture is beautiful. You cannot have a system that uploads, processes, encodes, stores, and indexes massive amounts of videos every hour of every day that in the overwhelming majority of cases will be watched less than 10 times, and still make a profit, without some brilliant engineering coming in somewhere.)
Quality matters, delivery speed matters, shipping also matters, where it matters and when it matters is much harder to get right. But it's also self correcting - if you don't, the project or business die - you can only get it wrong for so much or for so long.
To only discuss on one axis is presumably why GNU Hurd have never shipped or how claude-c-compiler doesn't compile hello world.
This has been reliably going on for at least 6+ months, I thought shorts was a big priority for them, but the UX is and remains horrible.
Hard disagree. I foresee the opposite being true. I think the ability to understand and write secure, well optimized, performant code will become more and more niche and highly desired in order to fix the mess the vibe coders are going to leave behind.
It's like the old story about hiring a carpenter who just hammers in a nail to fix a squeaky floor. The difficult part was finding where the nail needs to go, not necessarily the hammering.
There's lots of people that won't care about the code: executives, managers, customers etc. If the engineers don't care either, then who cares?
If we compare with big food companies, that's like their food formula. No one thinks it's useless - it's the source code for the product they sell. Yet nowadays we get so many engineers distancing themselves away from the code, like the software formula doesn't matter.
There are diminishing returns, but overall good code goes hand in hand with good products, it's just a different side of it.
If this were true, we wouldn't be studying Leet code and inverting binary trees to get a job.
I guess the lesson here is that unless you have a direct line with upper management to skip the line, you'll be stuck grinding algorithms for the rest of your life.
Big companies may have separate hiring SWE departments where the initial interviewers don't even know what team or role you may land in, so they have to resort to something...
We should all try and be more like John Carmack.
It wasn't just for the sake of quality and best practices, it defined and had an impact on the product experience.
Like Doom probably wouldn't have been as successful if it was any other way.
And only people on the older end of the spectrum have seen Carmack working in his element back in the day.
The things I want people to take from a guy like John Carmack, or Jon Blow, or Lukas Pope, or Ron Gilbert, or Tim Schafer, or Warren Spector, or Sam Lake, or David Cage god forbid...is pure curiosity and pushing the boundaries to make that real.
In every case there is a mix of a deep and unusual urge to make an idea happen with an affinity towards the technicality of it.
I bring Sam Lake into this because nobody has blended FMV with gameplay the way Remedy have and pushed the boundary on it.
This is made more complicated by the fact that where the balance lies depends on the people working on the code - some developers can cope with working in a much more of a mess than others. There is no objective 'right way' when you're starting out.
If you have weeks of runway left spending it refactoring code or writing tests is definitely a waste of time, but if you raise your next round or land some new paying customers you'll immediately feel that you made the wrong choices and sacrificed quality where you shouldn't have. This is just a fact of life that everyone has to live with.
"Rick Rubin says he barely plays any instruments and has no technical ability. He just knows what he likes and dislikes and is decisive about it."
https://www.cbsnews.com/news/rick-rubin-anderson-cooper-60-m...
https://en.wikipedia.org/wiki/Rick_Rubin_production_discogra...
In more minor markets like Europe/Australia it seems to be a lot less leetcode and a lot more (1) experience (2) degree (3) actual interview performance
The code’s value is measured in its usefulness to control and extend the Facebook system. Without the system, the code is worthless. On the flip side, the system’s value is also tied to its ability to change… which is easier to do if the code is well organized, verified, and testable.
I'm not sure how this follows logically from the comment you are replying to, which states:
> We have someone who vibe coded software with major security vulnerabilities.
The goal is delivering a useful product to someone, which just requires secure enough, optimized enough, efficient enough code.
Some see the security, optimization, or efficiency of the code itself as the goal. They'll be replaced.
What people don't seem to realize is that like you pointed out there's a demand for the previous "developer relations" type of job though, and that job kind of evolved through LLM agents into something like an influencer(?) type position.
If I would take a look at influencers and what they're able to build, it's not that hardcore optimized and secured and tested program codebase, they don't have the time to acquire and hone those skills. They are the types who build little programs and little solutions for everyday use cases that other people "get inspired with".
You could argue that this is something like a teacher role, and something like the remaining social component of the human to human interface that isn't automated yet. Well, at least not until the first generation of humans grew up with robotic nannies. Then it's a different, lower threshold of acceptance.
Facebook PHP Source Code from August 2007: https://gist.github.com/nikcub/3833406#file-index-php
It may look like that, but many of the products with bad code didn't even make it into your vibe statistics because they weren't around for long enough.
The “Facebook/YouTube codebases are a mess so code quality doesn’t matter” line is also misleading. Those companies absolutely hire—and pay very well—engineers who obsess over security, performance, and algorithmic efficiency, because at that scale engineering quality directly translates to uptime, cost, and trust.
Yes, the visible product layers move fast and can look messy. But underneath are extremely disciplined infrastructure, security, and reliability teams. You don’t run global systems on vibe-coded foundations. People who genuinely believe correctness and efficiency don’t matter wouldn’t last long in the parts of those organizations that actually keep the lights on.
I think Airbus is riding the coat tails of solid engineering done in the 80s and continuing to iterate that platform vs Boeing trying to iterate on a hardware platform from the 60s. Airbus benefited significantly from 20s years of engineering and technological progress. Since the original design of the A320, changes have been incremental. Slightly different engines, addition of GPS/GNS, CPDLC, CRT to LCD screens. Meanwhile Boeing has attempted to take a steam gauge design from the 60s and retrofit decades of technology improvements and, critically, they attempted to add engines significantly altering the aerodynamics of the aircraft.
Competitive coding is oversold in this generation. You can log in to most of these sites and you will see thousands of solutions submitted to each problem. There is little incentive to reward situations where you solved some problem which a thousand other people have solved.
To that end its also a intellectual equivalent of video game addiction. There is some kind of illusion that you are indulging in a extremely valuable and productivity enterprise, but if you observe carefully nothing much productive actually gets done.
Only a while back excessive chess obsession had similar problems. People spending whole days doing things which make them feel special and intelligent, but to any observer at a distance its fairly obvious they are wasting time and getting nothing done.
Huh, if you make finished products you better start your own company.
Visionaries are important, but they’re a small part of what makes a successful organization. The majority hinges on disciplined engineers who understand the plan, work within the architecture, and ship what’s needed
As Victor Wooten once said: "If you’re in the rhythm section, your job is to make other people sound better." That’s what most engineering positions actually are and there’s real skill and value in doing that well.
This is such a bad take and flat out wrong. Your ability to deliver and maintain features is directly impacted by the quality of the code. You can ship a new slop project every day if you like, but in order for it to scale or manage real traffic and usage you need to have a good foundation. This is such a bad approach to Software engineering.
The most successful engineers are the ones who can accurately assess the trade-offs regarding those things. The things you list still may be critical for many applications and worth obsessing over.
The question becomes can we still achieve the same trade-offs without writing code by hand in those cases.
That’s an open question.
Which is not the case. It's just a useless product, without any real use case, which also introduces large security bugs in your system.
For a programmer, that's based on them "being a 10x programmer who excels at hackerrank".
For manager types it might be "Creativity, drive, vision, whatever".
>Code is a means to an end
For a business in general.
When hiring developers, code IS the end.
I don't object to most of what you're saying, but I take issue with this part.
This happens to be an area where lapse or neglect can be taken as a moral failure. And here you are mocking people who are concerned about it.
If someone uses AI to architect a bridge and the bridge collapses, you couldn't say that the structural integrity of the bridge wasn't the important part.
I don't think it's a good thing that the craft of software engineering is so easily devalued this way. We can quite demonstrably show that AI is not even close to replacing people in this respect.
Am I speaking out of envy or jealousy? Maybe. But I find it disappointing that we have yet more perverse incentives to hyper-accelerate delivery and externalise the consequences on to the users. It's a very unserious place to be.
Also, has anybody looked through the Openclaw source? Maybe it’s not so bad
Ah, right. Write "Brew", which gets used by thousands of devs at Google every day, and then get rejected in an interview.
> "Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off."
Or, in this case, just because they need a poster boy for their product, which isn't as good as they say it is.
Tell that to the guy that made brew and tried to interview at Google
This is just wrong. Plenty of examples of crap code causing major economic losses.
10x programmers aren't the ones grinding hacker-rank.
Neither are the programmers like me who actually focus on building good systems under any significant threat.
And Facebook's codebase is pretty decent for the most part, you'd probably be shocked. Benefits of moving fast and breaking things include making developer experience a priority. That's why they made Hacklang to get off PHP and why they made React and helped make Prettier
Product is a means to an end.
Being good at something is a means to an end.
That end? Barter for food and shelter, medicine.
The means to do so; code or delivery of a product; are eventually all depreciated, and thrown away. You eventually age into uselessness and die.
Suddenly having an epiphany it's not about code but product! way too late in the game, HN... you're just trying to look like you got it figured out and bring deep fucking value to humanity right as "idea to product without intermediary code layer" is about to ship[1]. You already missed your window.
You still don't get the change that's needed and happening due to automation; few of us want to put you on their shoulders and sing songs about you all.
Hop off the Hedonistic Treadmill and get some help.
[1] am working on idea to binary at day job, which will flood the market with options and drown yours out