10 ms·

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt?

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understanding of what you are building does not exceed the reality of the mess you and your team are actually building if budgets allow. This seldom happens, even in solo hobby projects once you cost everything in. It's not about agile or waterfall or "functional" or abstracting your dependencies via Podman or Docker or VMware or whatever that nix crap is. Or using an agent to catch the bugs in the agent that's talking to an LLM you have next to no control over that's deleting your production database while you slept, then asking it to make illustrations for the postmortem blog post you ask it to write that you think elevates your status in the community but probably doesn't. I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

latchkey 7mo ago
> People answered this wrong in the Ruby era, they answered it wrong in the PHP era Aren't you conveniently ignoring the fact that there were people saw through that and didn't go down those routes?
- badlibrarian 7mo ago
  Change it to "Some people" if your pedanticism won't let you follow the flow. Or better yet point out the better paths they chose instead. Were they wrestling with Java and "Joda Time"? Talking to AWS via a Python library named after a dolphin? Running .NET code on Linux servers under Mono that never actually worked? Jamming apps into a browser via JQuery? Abstracting it up a level and making 1,400 database calls via ActiveRecord to render a ten item to-do list and writing blog posts about the N+1 problem? Rewriting grep in Rust to keep the ruskies out of our precious LLCs? Asking the wrong questions, using the wrong tools, then writing dumb blog posts about it is what we do. It's what makes us us.
  - PaulHoule 7mo ago
    There's this interesting issue that we've never had occupational licensing for software developers despite the sheer incompetence that we see all the time. On one hand there's an approach to computing where it is a branch of mathematics that is universal. There are some creatures that live under the ice on a moon circling a gas giant around another star and if they have computers they are going to understand the halting problem (even if they formulate it differently) and know bubble sort is O(N^2) and about algorithms that sort O(N log N). On the other hand we are divided by communities of practice that don't like one another. For instance there is the "OO sux" brigade which thinks I suck because I like Java. There still are shops where everything is done in a stored procedure (oddly like the fashionable architecture where you build an API server just because... you have to have an API) and other shops where people would think you were brain damaged to go anywhere near stored procs, triggers or any of that. It used to be Linux enthusiasts thought anybody involved in Windows was stupid and you'd meet Windows admins who were click-click-click-click-clicking over and over again to get IIS somewhat working who thought IIS was the only web server good enough for "the enterprise" Now apart for the instinctual hate for the tools there really are those chronic conceptual problems for which datetime is the poster child. I think every major language has been through multiple datetime libraries in and out of the standard lib in the last 20 years because dates and times just aren't the simple things that we wish they would be and the school of hard knocks keeps knocking us to accept a complicated reality.
    - latchkey 7mo ago
      > There's this interesting issue that we've never had occupational licensing for software developers despite the sheer incompetence that we see all the time. I'm laughing over the current Delve/SOC2 situation right now. Everyone pulls for 'licenses' as the first card, but we all know that is equally fraught with trauma. https://xkcd.com/927/ https://xkcd.com/927/
  - latchkey 7mo ago
    > pedanticism Pedanticism (or pedantry) is the excessive, tiresome concern for minor details, literal accuracy, or formal rules, often at the expense of understanding the broader context. I don't think this had anything to do with minor details at all. You're trying to convey a point while ignoring the half of the population who didn't go down that route.
kemiller2002 7mo ago
Maybe back in the beginning, but I don't think it's an engineering discipline now. I don't think that's bad though. I always thought we tagged on the word "engineer" so that we could make more money. I'm ok with not being one. The engineers I've known are very strict in their approach which is good since I don't want my deck to fall down. Most of us are too risky with our approach. We love to try new things and patterns, not just used established ones over time. This is fine with me, and when we apply the term "engineer" to work, I get a little uneasy, because I think it implies us doing something that most of us really don't want to do. That is, absolutely prove our approach works and will work for years to come. Just my opinion though.
- QuantumNomad_ 7mo ago
  I’ve had jobs where my title was “software engineer”, but I never refer to myself as such outside of work. When I tell others what I do, I say I am a software developer. It may seem a pointless distinction, but to me there is a distinction. Neither myself nor the vast majority of other “software engineers” in our field are living up to what it should mean to be an “engineer”. The people that make bridges and buildings, those are the engineers. Software engineers, for the very very most part, are not.
  - brightball 7mo ago
    I was won over by this distinction from another senior some years ago. I think he said… “Developers build things. Engineers build them and keep them running.” I like the linguistic point from a standpoint of emphasizing a long term responsibility.
    - chermi 7mo ago
      I was just reading "how the world became rich" and they made an interesting distinction economic "development" vs plain "growth". Amusingly, "development" to them means exactly what you're saying "engineer" should mean. It's sustainable, structural, not ephemeral. Development in the abstract hints at foundational work. Building something up to last. It seems like this meaning degradation is common in software. It still blows my mind how the "full-stack" naming stuck, for example. https://www.howtheworldbecamerich.com/ https://www.howtheworldbecamerich.com/ Edit-on a related note, are there any studies on the all-in long-term cost between companies that "develop" vs. "engineer". I doubt there would be clean data since the managers that ignored all of the warning of "tech debt" would probably have the say on both compiling and releasing such data. Does the cost of "tech-debt" decrease as the cost of "coding" decreased or is there a phase transition on the quality of the code? I bet there will be an inflection point if you plotted the adoption time of AI coding by companies. Late adapters that timed it after the models and harnesses and practices were good enough (probably still some time in the near future) would have less all-in cost per same codebase quality.
SoftTalker 7mo ago
> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. It isn't. Show me the licensing requirements to be a "software engineer." There are none. A 12 year old can call himself a software engineer and there are probably some who have managed to get remote work on major projects.
- anthk 7mo ago
  In Europe they are. Call yourself an Engineer without a degree and your company and you will be sued with a big fine, because here you must be legally accountable on disasters and ofc there are hard constraints .
  - embedding-shape 7mo ago
    > In Europe they are Where specifically? I've been working as a "Software engineer" for multiple decades, across three countries in Europe, and 2-3 countries outside of Europe, never been sued or received a "big fine" for this, even have had presentations for government teams and similar, not a single person have reacted to me (or others) calling ourselves "software engineers" this whole time.
    - dranudin 7mo ago
      In Germany. I have a degree in mechanical engineering and am thus allowed to call myself an engineer, even though I write software professionally. Colleagues who have studied computer science cannot, as it is not considered an engineering, but a science degree. This is why most people talk about "software developers" and not about "software engineers" (in German) to avoid this problem. That being said, most people would not actually care.
      - anthk 7mo ago
        Where it should be the reverse. Science demands reproducibily where engineering just tight thresholds to function upon defined conditions, but not 100% exact. And except for SEL4 and some small microcontrollers with Eforth, C and tons of languages have undefined behaviours.
stuffn 7mo ago
Largely a problem of VCs and shareholders. After my 12th year of "we'll get around to bug fixes" and "this is an emergency" I realize I am absolutely not doing anything related to engineering. My job means less than the moron PM who graduated bottom of their class in <field>. The lack of trust in me despite having almost a life in software is actually so insulting it's hard to quantify. Now I barely look at ticket requirements, feed it to an LLM, have it do the work, spend an hour reviewing it, then ship it 3 days later. Plenty of fuck off time, which is time well spent when I know nothing will change anyway. If I'm gonna lose my career to LLMs I may as well enjoy burning shareholder capital. I've optimized my life completely to maximize fuck off time. At the end of the day they created the environment. It would be criminal to not take advantage of their stupidity.
- konfusinomicon 7mo ago
  same experience here. trust deficits so rampant i question if ive ever been right once in my career. dont forget the lack of the word 'iterate' in the decision makers vocabulary. and as soon as the word sunset is uttered you know your in for a bumpy ride once again
PaulHoule 7mo ago
People built a lot of great stuff with Ruby, PHP, Notes and VB. I don't know what the problem really is. Personally I think that whole Karpathy thing is the slowest thing in the world. I mean you can spin the wheels on a dragster all you like and it is really loud and you can smell the fumes but at some point you realize you're not going anywhere. My own frustration with the general slowness of computing (iOS 26, file pickers, build systems, build systems, build systems, ...) has been peaking lately and frankly the lack of responsiveness is driving me up the wall. If I wasn't busy at work and loaded with a few years worth of side projects I'd be tearing the whole GUI stack down to the bottom and rebuilding it all to respect hard real time requirements.
pydry 7mo ago
>After five or six cycles it does become a bit fatiguing. Use the tool sanely. That's increasingly not possible. This is the first time for me in 20 years where I've had a programming tool rammed down my throat. There's a crisis of software developer autonomy and it's actually hurting software productivity. We're making worse software, slower because the C levels have bought this fairy tale that you can replace 5 development resource with 1 development resource + some tokens.
- whaleofatw2022 7mo ago
  That lucky? In 18 years AI is the third or 4th tool forced upon a shop/team, I will say of those it is the forst one that is genuinely able to make me more productive overall, even with the drawbacks.
no_shadowban_3 7mo ago
> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. Just another reason we should cut software jobs and replace them with A(G)I. If the human "engineers" were never doing anything precisely, why would the robot engineers need to?
01284a7e 7mo ago
All (not some) of the most successful devs I've known in the sense of building something that found market fit and making money off it were terrible engineers. They were fairly productive at building features. That's it. And they were productive - until they weren't. Their work ultimately led to outages, lost data, and sensitive data being leaked (to what extent, I don't even know). The ones who got acquired - never really had to stand up to any due diligence scrutiny on the technical side. Other sides of the businesses did for sure, but not that side. Many of you here work for "real" tech companies with the budget and proper skin in the game to actually have real engineers and sane practices. But many of you do not, and I am sure many have seen what I have seen and can attest to this. If someone like the person I mentioned above asks you to join them to help fix their problems, make sure the compensation is tremendous. Slop clean-up is a real profession, but beware.
- michaelbarton 7mo ago
  There used to be a saying along the lines of “while you’re designing your application to scale to 1m requests/min, someone out there is making $1m ARR with php and duct tape” It feels like this takes on a whole new meaning now we have agents - which I think is the same point you were making
AnimalMuppet 7mo ago
Software was an engineering discipline... at some places. And it still is, at some places. Other places were "hack it until we don't know of any major bugs, then ship it before someone finds one". And now they're "hey, AI agents - we can use that as a hack-o-matic!" But they were having trouble with sustainability before, and they're going to still, except much faster.
skybrian 7mo ago
People don't realize how much software engineering has improved. I remember when most teams didn't use version control, and if we did have it, it was crappy. Go through the Joel Test [1] and think about what it was like at companies where the answers to most of those questions was "no." [1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
- Towaway69 7mo ago
  At the same time, systems have become far more complex. Back when version control was crap, there weren't a thousand APIs to integrate and a million software package dependencies to manage. Sure everything seems to have gotten better and that's why we now need AIs to understand our code bases - that we created with our great version control tooling. Fundamentally we're still monkeys at keyboards just that now there are infinitely many digital monkeys.
  - PaulHoule 7mo ago
    Perrow’s book Normal Accidents postulates that, given advances which could improve safety, people just decide to emphasize throughput, speed, profits, etc. he turned out to be wrong about aviation (got much safer over time) and maritime shipping (there was a perception of a safety crisis in the late 1970s with oil tankers exploding, now you just hear about the odd exceptional event.)
    - Towaway69 7mo ago
      > Perrow argues that multiple and unexpected failures are built into society's complex and tightly coupled systems, and that accidents are unavoidable and cannot be designed around.[1] This is definitely something that is happening with software systems. The question is: is having an AI that is fundamentally undecipherable in its intention to extend these systems a good approach? Or is an approach of slowing down and fundamentally trying understand the systems we have created a better approach? Has software become safer? Well planes don't fall from the sky but the number of zero day exploits built into our devices has vastly improved. Is this an issue? Does it matter that software is shipped broken? Only to be fixed with the next update. I think its hard to have the same measure of safety for software. A bridge is safe because it doesn't fall down. Is email safe when there is spam and phishing attacks? Fundamentally Email is a safe technology only that it allows attacks via phishing. Is that an Email safety problem? Probably not just as as someone having a car accident on a bridge is generally not a result of the bridge. I think that we don't learn from our mistakes. As developers we tend to coat over the accidents of our software. When was the last time a developer was sued for shipping broken software? When was the last time an engineer was sued for building a broken bridge? Notice that there is an incentive as engineer to build better and safer bridges, for developers those incentives don't exist. [1]: https://en.wikipedia.org/wiki/Normal_Accidents https://en.wikipedia.org/wiki/Normal_Accidents
dec0dedab0de 7mo ago
I'm not even sure building software is an engineering discipline at this point. Maybe it never was. It's a craft.
- tayo42 7mo ago
  Software reminds me more of construction or home contracting work then engineering. We do the actual building of things
  - sidpatil 7mo ago
    Construction and home contracting follow building codes.
dstroot 7mo ago
> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. If I engineer a bridge I know the load the bridge is designed to carry. Then I add a factor of safety. When I build a website can anyone on the product side actually predict traffic? When building a bridge I can consult a book of materials and understand how much a material deforms under load, what is breaking point is, it’s expected lifespan, etc. Does this exist for servers, web frameworks, network load balancers, etc.? I actually believe that software “could” be an engineering discipline but we have a long way to go
- beachy 7mo ago
  Software and bridges are entirely different. If I need a bridge, and there's a perfectly beautiful bridge one town over that spans the same distance - that's useless to me. Because I need my own bridge. Bridges are partly a design problem but mainly a build problem. In software, if I find a library that does exactly what I need, then my task is done. I just use that library. Software is purely a design problem. With agentic coding, we're about to enter a new phase of plenty. If everyone is now a 10x developer then there's going to be more software written in the next few years than in the last few decades. That massive flurry of creativity will move the industry even further from the calm, rational, constrained world of engineering disciplines.
  - mckn1ght 7mo ago
    Software packages are more complicated than you make them out to be. Off the top of my head: - license restrictions, relicensing - patches, especially to fix CVEs, that break assumptions you made in your consumption of the package - supply chain attacks - sunsetting There’s no real “set it and forget it” with software reuse. For that matter, there’s no “set it and forget it” in civil engineering either, it also requires monitoring and maintenance.
    - VorpalWay 7mo ago
      I have talked to colleagues who wrote software running on microcontrollers a decade ago, that software still runs fine. So yes there is set and forget software. And it is all around us, mostly in microcontrollers. But microcontrollers far outnumber classical computers (trivially: each classical computer or phone contain many microcontrollers such as SSD controllers, power management, wifi, ethernet, cellular,... And then you can add appliances, cars etc to that). If something in software works and isn't internet connected it really is set and forget. And far too many things are being connected needlessly these days. I don't need or want an online washing machine or car.
_dwt 7mo ago
> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.". - Edsger Dijkstra, 1988 I think, unfortunately, he may have had us all dead to rights on this one.
- throwanem 7mo ago
  One would as sensibly dismiss the concept of an assembly line as "how to build a car if you cannot." Dijkstra was a mathematician. It is a necessary discipline. If it alone were sufficient, then the "program correctness" fans would have simply and inarguably outdone everyone else forty years ago at the peak of their efforts, instead of having resorted to eloquently whiny, but still whiny, thinkpieces (such as the 1988 example [1] quoted here above) about how and why they would like history to understand them as having failed. [1] https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF [2] [2] I will freely grant that the man both wrote and lettered with rare beauty, which shames me even in this photocopier-burned example when I compare it to the cheerful but largely unrefined loops and scrawls of my own daily hand.
  - bigfishrunning 7mo ago
    I think the real tragedy here is that we can spend *all* of our time trying to improve the quality of our output, but it simply doesn't matter, because as long as the button is where the boss wants it to be and is the right color, all is right with the world. Literally nothing else matters, and we (or at least I) have wasted a ton of time getting good at writing software.
    - throwanem 7mo ago
      As long as it continues to matter what the button actually does, I can't consider our effort to have been entirely wasted. We only have the misfortune to live in stupid and dangerous times, but good heavens, we're hardly the first in that, and hardly starved for examples from whom to learn.
kerblang 7mo ago
Engineering is two things: 1. Applied physics - Software is immediately disqualified. Symbols have no physics. 2. Ethics - Lives and livelihoods depend on you getting it right. Software people want to be disqualified because that stuff is so boring, but this is becoming a more serious issue with every passing day.
- eloisant 7mo ago
  That might vary by countries but in France with have an official "engineering degree" (diplome d'ingénieur) which is also a master's degree, and most software developers have this. So most software developers in France are absolutely software engineers.
- zephen 7mo ago
  > Software is immediately disqualified. Symbols have no physics. Many physical processes are controlled by software.
- galbar 7mo ago
  Software is applied mathematics, though
  - kerblang 7mo ago
    And still not applied physics
perrygeo 7mo ago
> What are you building? This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs? Hard to shake the feeling that this looks like one big pyramid scheme. I strongly suspect that vast majority of the "innovation" in recent years has gone straight to supporting the funding model and institution of the software profession, rather than actual software engineering. > I'm not even sure building software is an engineering discipline at this point. Maybe it never was. It was, and is. But not universally. If you formulate questions scientifically and use the answers to make decisions, that's engineering. I've seen it happen. It can happen with LLMs, under the proper guidance. If you formulate questions based on vibes, ignore the answers, and do what the CEO says anyway, that's not engineering. Sadly, I've seen this happen far too often. And with this mindset comes the Claudiot mindset - information is ultimately useless so fake autogenerated content is just as valuable as real work.
- ryandrake 7mo ago
  > The last 10 years in the software industry in particular seems full of meta-work. Building new frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. All to build... what exactly? Don't forget App Stores. Everyone's still trying to build app stores, even if they have nothing to sell in them. It's almost as if every major company's actual product is their stock price. Every other thing they do is a side quest or some strategic thing they think might convince analysts to make their stock price to move.
  - jimbokun 7mo ago
    > It's almost as if every major company's actual product is their stock price. They are pretty much legally obligated to act in this manner.
    - wholinator2 7mo ago
cucumber3732842 7mo ago
Software engineering is real engineering because we rigorously engineer software the way real engineers engineer real things. Software engineering is not real engineering because we do not rigorously engineer software the way "real" engineers engineer real things. <--- YOU ARE HERE Software engineering is real engineering because we "rigorously" engineer software the way "real" engineers engineer real things. Edit: quotes imply sarcasm.
psychoslave 7mo ago
Hey Visual Basic is still there, and last time I checked it was still the goto option to do OLE Automation. RoR is no longer at its peak, but is still have its marginal stable share of the web, while PHP gets the lion part[1] Ok, Lotus Notes is really relic from an other era now. But it’s not a PL, so not the same kind of beast. Well, also LLMs are different beast compared to PL. They actually really are the things that evocate the most the expression "taming the beast" when you need to deal with them. So it indeed as far away as possible of engineering as one can probably use a computer to build any automation. Maybe to stay in scientific realms ethology would be a better starting point than a background in informatics/CS to handle these stuffs. [1] https://w3techs.com/technologies/comparison/pl-php https://w3techs.com/technologies/comparison/pl-php
cyanydeez 7mo ago
As far as I can tell, the only reason agents exist is because large context increase the probability of context poisoning, purely by the inability of these models to actually make conceptual decisions about the context. I was interested in making a semi-automous skill improvement program for open code, and I wired up systemd to watch my skills directory; when a new skill appeared, it'd run a command prompt to improve it and cohere it to a skill specification. It was told to make a lock file before making a skill, then remove the lock files. Multiple times it'd ignore that, make the skill, then lock and unlock on the same line. I also wanted to lock the skill from future improvements, but that context overode the skills locking, so instead I used the concept of marking the skills as readonly. So in reality, agents only exist because of context poisoning and overlap; they're not some magicaly balm to improving the speed of work, or multiplying the effort, they simply prevent context poisoning from what's essentially subprocesses. Once you realize that, you really have to scale back the reality because not only are they just dumb, they're not integrating any real information about what they're doing.
hu3 7mo ago
> What are you building? Does the tool help or hurt? > People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. I'm assuming you're saying these tools hurt more than help? In that case I disagree so much that I'm struggling to reply. It's like trying to convince someone that the Earth is not flat, to my mental model. PHP, Ruby and VB have more successful code written in them than all current academic or disproportionately hyped languages will ever have combined. And there's STILL software being written in them. I did Visual Basic consulting for a greenfield project last week despite my current expertise being more with Go, Python, C# and C. And there's a RoR work lined up next. So the presence gap between these helpful tools and other minor, but over index tools, is still increasing. It's easy to think that the languages one see mor often in HN are the prevalent ones but they are just the tip of the iceberg.
devin 7mo ago
Absolutely agree. I'm watching a team which is producing insane amounts of code for their team size, but the level of thought that has gone into all of the details that would make their product a fit predator to run at scale and solve the underlying business problem has been neglected. Moving really fast in the wrong direction is no help to anyone.
bodash 7mo ago
Exactly! I’ve noticed a resounding amount of people are writing the same pieces recently, it’s almost like everyone’s sounding their alarm for the upcoming tsunami. Who’s listening? Here’s my piece: https://humantodo.dev https://humantodo.dev
keyle 7mo ago
Agreed. I've been building software for 25 years+. At some point I became so burnt out I couldn't look at an IDE or coloured text for that matter. I found the way back by just changing my motto and focus... Find good people, do good work. That's it, that's all I want. I don't care whether the 'property is hot' or what the market is doing anymore, I just build software in my lane, with good people around.
lmm 7mo ago
> It's not about agile or waterfall or "functional" or abstracting your dependencies via Podman or Docker or VMware or whatever that nix crap is. It is though. Picking the right approaches and tools makes more difference than anything else. Sure, you don't need the right tools if you can make the right choices - but it's much easier to pick a better methodology than to hire smarter people.
sublinear 7mo ago
Perhaps this is the wrong place to plant this thought. Maybe nobody will read it. These comments are now many hours old and HN has a way of walking away once they have had their turn shouting into the void. I once received a "bonsai" seed kit from a former boss during a holiday dinner. I think it was meant as a joke, but even now I'm not so sure. I planted those seeds anyway. I told some people about it and they immediately mocked me saying it was a waste of time and going to take 30 years. This interaction immediately said everything to me about the expectations and attitudes of others. Obviously, they grew like any other plants and actually quite nicely. Of course they're a commitment, but not a huge one. I just wanted some plants for my apartment and they fit the bill. In a few years I had good looking plants. A decade later, I still have them and they're now more recognizably "bonsai". My home now looks nicer, I have a story to tell, and I learned a little bit from a very low stakes hobby. My point is, I think it's nice when people have projects. I think it's nice to see what comes of it. I guess my only regret is ever saying "I planted bonsai" too soon just because that's what the box said. I didn't know how else to describe what I had done that weekend to those people who threw theirs in the trash.
- danhite 7mo ago
  > Maybe nobody will read it. These comments are now many hours old and HN has a way of walking away once they have had their turn shouting into the void. All that is gold does not glitter, Not all those who wander are lost; The old that is strong does not wither, Deep roots are not reached by the frost. ― J.R.R. Tolkien, The Fellowship of the Ring
- jafitc 7mo ago
  that's a great story!
- nathan_douglas 7mo ago
  I was thinking the other day about how frustrated my desire is to perform some kind of Great Work. A few years back I was intensely interested in making something like Nethack - a roguelike game with a deceptively simple surface and incredible complexity in the engine. I worked on several for a few years, different angles on the whole "managing complexity" thing. I suppose I learned a lot, and I made some interesting things, but I never really produced anything I felt I could work on for 20-30 years, that would be sort of my artistic statement as an engineer (if such a thing makes any sense). I wouldn't've laughed at you. I view bonsai as a representation of steadfastness, endurance, determination, effort, (and self-mastery?) in the face of tremendous hardship, challenge, and deprivation. That said, I've never been particularly good at any of those things. IDK if I would've taken you all that seriously either, though. Six months until you move and it's left behind on the curb. Or a year and a half until your cat knocks it off the windowsill. Or three years until some blight infects it and it dies off despite your best efforts. Eight years until, for whatever reason, it just succumbs to some kind of vegetative ennui. Nine years until your significant other overwaters it one too many times and the roots rot. That's not meant disrespectfully. I just tend to view uncertainty and complexity as opportunities for shit to go sideways. Especially in this case, where it's unlikely you'll wake up to find your tree has spontaneously cloned itself, or has eaten a 1-UP mushroom. Disasters happen all the time, and miracles don't. I suppose I'm just having a bit of a spiritual crisis right now. But thank you for your comment. It gives me a lot to think about, in a positive sense.
ray_v 7mo ago
Maybe it's more about a rush to share how awesome it is that you compressed your time-to-release down to days and not weeks or months - when in reality that's a good thing in the sense that you get to a failure state much FASTER, and failure states are good, because that means that you get to iterate and get past those failures FASTER. I don't think people were releasing at this pace, so the failure states are fast and furious so there is just that much more viability. I think the microslop windos failures lately are just them being the same "them" that they've always been .. just MUCH faster. (they just need to stop monkeying with windows and stop adding more features on top of an already shaky foundation.) Maybe we just need more of the stories like Anthropic working with Mozilla to squash 5x the amount of bugs in a similar time frame first, AND THEN "vibe a browser together from nothing but specification files and an army of bots in a weekend".
crystal_revenge 7mo ago
> What are you building? I think AI really pushes this higher up the abstraction layer: > What problem are you solving? I've spent a good amount of my careering using engineering and math to solve specific problems, I'm usually adjacent to software teams. What I've seen happen with agentic coding is that traditional software engineers keep focusing on using it to build software, while ignoring the problem they're trying to solve. Meanwhile I've seen junior data analysts start interfacing with applications and tools they never dreamed of before, and delivering results to stakeholders in record times. Things that were previously blocked by engineering no longer are. But many engineers today are not really problem solvers, they're software builders. The idea that solving the end users problem is the goal, not building them software, is incomprehensible. And so they continue to struggle to use AI effectively because they're trying to build software with it. Which it's not terrible at, but it's really the wrong tool for that job. Sometimes software is necessary to solve a problem, a few years ago, software was necessary for a fairly large problem surface area (though, to your point, even then a lot of software was not really built to solve those problems). Today that surface area is shrinking, and as economic constraints loom on the horizon, I believe it will increasingly be people who are solving problems (with or without AI) that will be the ones surviving.
- Panzer04 7mo ago
  The kind of jobs an analyst are doing are probably the most amenable of everything to LLM assistance. Small, bounded, etc. The bigger the problem set and context the less helpful an LLM gets.
cookiengineer 7mo ago
I am just using Go at this point and stopped caring about my own opinions. I live in the happy place in negligence. Go software has almost zero maintenance costs and it will continue to build my programs in 10 years with zero changes to my codebase being necessary. I probably will never touch C++ again, even though CGo is the most painful FFI/ABI implementation I've dealt with. Just today I tried to build a project that's using bergamoth and a shitload of broken C++ dependencies and decided to not give a damn after 5 hours of trying to fix crappy code that changed for whatever reasons between c++14 and c++15, well, or the dependencies are broken, or the dependency versions are broken, or the maintainer's code never compiled in the first place... I just don't care. My hopes were higher during the conan peak days, but now the ecosystem is just so broken even with jinja and whatever build framework the new kids are using. I guess I just really hate the C++ ecosystem, and the lack of self reflection in there about the self inflicted pain that shouldn't be necessary in 2026. In regards to agentic coding: I am toying around with codestral:22b right now and xiaomi's mimo models, and am building my own local dev environment which makes this kinda nice. It's local and I like it, sometimes need to use claude still but it's getting there. But I am delegating only the gruntwork, not decisions, so I use temperature usually below 0.3. My approach is to make this sandboxed per folder I run it in and that agents are only allowed to communicate via notes or tasks, so that they are forced to use better documentation. Specific roles don't have write access to certain things, e.g. coder can't touch tests, and tester can't touch code.

latchkey 7mo ago

> People answered this wrong in the Ruby era, they answered it wrong in the PHP era Aren't you conveniently ignoring the fact that there were people saw through that and didn't go down those routes?

badlibrarian 7mo ago
Change it to "Some people" if your pedanticism won't let you follow the flow. Or better yet point out the better paths they chose instead. Were they wrestling with Java and "Joda Time"? Talking to AWS via a Python library named after a dolphin? Running .NET code on Linux servers under Mono that never actually worked? Jamming apps into a browser via JQuery? Abstracting it up a level and making 1,400 database calls via ActiveRecord to render a ten item to-do list and writing blog posts about the N+1 problem? Rewriting grep in Rust to keep the ruskies out of our precious LLCs? Asking the wrong questions, using the wrong tools, then writing dumb blog posts about it is what we do. It's what makes us us.
- PaulHoule 7mo ago
  There's this interesting issue that we've never had occupational licensing for software developers despite the sheer incompetence that we see all the time. On one hand there's an approach to computing where it is a branch of mathematics that is universal. There are some creatures that live under the ice on a moon circling a gas giant around another star and if they have computers they are going to understand the halting problem (even if they formulate it differently) and know bubble sort is O(N^2) and about algorithms that sort O(N log N). On the other hand we are divided by communities of practice that don't like one another. For instance there is the "OO sux" brigade which thinks I suck because I like Java. There still are shops where everything is done in a stored procedure (oddly like the fashionable architecture where you build an API server just because... you have to have an API) and other shops where people would think you were brain damaged to go anywhere near stored procs, triggers or any of that. It used to be Linux enthusiasts thought anybody involved in Windows was stupid and you'd meet Windows admins who were click-click-click-click-clicking over and over again to get IIS somewhat working who thought IIS was the only web server good enough for "the enterprise" Now apart for the instinctual hate for the tools there really are those chronic conceptual problems for which datetime is the poster child. I think every major language has been through multiple datetime libraries in and out of the standard lib in the last 20 years because dates and times just aren't the simple things that we wish they would be and the school of hard knocks keeps knocking us to accept a complicated reality.
  - latchkey 7mo ago
    > There's this interesting issue that we've never had occupational licensing for software developers despite the sheer incompetence that we see all the time. I'm laughing over the current Delve/SOC2 situation right now. Everyone pulls for 'licenses' as the first card, but we all know that is equally fraught with trauma. https://xkcd.com/927/ https://xkcd.com/927/
- latchkey 7mo ago
  > pedanticism Pedanticism (or pedantry) is the excessive, tiresome concern for minor details, literal accuracy, or formal rules, often at the expense of understanding the broader context. I don't think this had anything to do with minor details at all. You're trying to convey a point while ignoring the half of the population who didn't go down that route.

kemiller2002 7mo ago

Maybe back in the beginning, but I don't think it's an engineering discipline now. I don't think that's bad though. I always thought we tagged on the word "engineer" so that we could make more money. I'm ok with not being one. The engineers I've known are very strict in their approach which is good since I don't want my deck to fall down. Most of us are too risky with our approach. We love to try new things and patterns, not just used established ones over time. This is fine with me, and when we apply the term "engineer" to work, I get a little uneasy, because I think it implies us doing something that most of us really don't want to do. That is, absolutely prove our approach works and will work for years to come. Just my opinion though.

QuantumNomad_ 7mo ago
I’ve had jobs where my title was “software engineer”, but I never refer to myself as such outside of work. When I tell others what I do, I say I am a software developer. It may seem a pointless distinction, but to me there is a distinction. Neither myself nor the vast majority of other “software engineers” in our field are living up to what it should mean to be an “engineer”. The people that make bridges and buildings, those are the engineers. Software engineers, for the very very most part, are not.
- brightball 7mo ago
  I was won over by this distinction from another senior some years ago. I think he said… “Developers build things. Engineers build them and keep them running.” I like the linguistic point from a standpoint of emphasizing a long term responsibility.
  - chermi 7mo ago
    I was just reading "how the world became rich" and they made an interesting distinction economic "development" vs plain "growth". Amusingly, "development" to them means exactly what you're saying "engineer" should mean. It's sustainable, structural, not ephemeral. Development in the abstract hints at foundational work. Building something up to last. It seems like this meaning degradation is common in software. It still blows my mind how the "full-stack" naming stuck, for example. https://www.howtheworldbecamerich.com/ https://www.howtheworldbecamerich.com/ Edit-on a related note, are there any studies on the all-in long-term cost between companies that "develop" vs. "engineer". I doubt there would be clean data since the managers that ignored all of the warning of "tech debt" would probably have the say on both compiling and releasing such data. Does the cost of "tech-debt" decrease as the cost of "coding" decreased or is there a phase transition on the quality of the code? I bet there will be an inflection point if you plotted the adoption time of AI coding by companies. Late adapters that timed it after the models and harnesses and practices were good enough (probably still some time in the near future) would have less all-in cost per same codebase quality.

SoftTalker 7mo ago

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. It isn't. Show me the licensing requirements to be a "software engineer." There are none. A 12 year old can call himself a software engineer and there are probably some who have managed to get remote work on major projects.

anthk 7mo ago
In Europe they are. Call yourself an Engineer without a degree and your company and you will be sued with a big fine, because here you must be legally accountable on disasters and ofc there are hard constraints .
- embedding-shape 7mo ago
  > In Europe they are Where specifically? I've been working as a "Software engineer" for multiple decades, across three countries in Europe, and 2-3 countries outside of Europe, never been sued or received a "big fine" for this, even have had presentations for government teams and similar, not a single person have reacted to me (or others) calling ourselves "software engineers" this whole time.
  - dranudin 7mo ago
    In Germany. I have a degree in mechanical engineering and am thus allowed to call myself an engineer, even though I write software professionally. Colleagues who have studied computer science cannot, as it is not considered an engineering, but a science degree. This is why most people talk about "software developers" and not about "software engineers" (in German) to avoid this problem. That being said, most people would not actually care.
    - anthk 7mo ago
      Where it should be the reverse. Science demands reproducibily where engineering just tight thresholds to function upon defined conditions, but not 100% exact. And except for SEL4 and some small microcontrollers with Eforth, C and tons of languages have undefined behaviours.

stuffn 7mo ago

Largely a problem of VCs and shareholders. After my 12th year of "we'll get around to bug fixes" and "this is an emergency" I realize I am absolutely not doing anything related to engineering. My job means less than the moron PM who graduated bottom of their class in <field>. The lack of trust in me despite having almost a life in software is actually so insulting it's hard to quantify. Now I barely look at ticket requirements, feed it to an LLM, have it do the work, spend an hour reviewing it, then ship it 3 days later. Plenty of fuck off time, which is time well spent when I know nothing will change anyway. If I'm gonna lose my career to LLMs I may as well enjoy burning shareholder capital. I've optimized my life completely to maximize fuck off time. At the end of the day they created the environment. It would be criminal to not take advantage of their stupidity.

konfusinomicon 7mo ago
same experience here. trust deficits so rampant i question if ive ever been right once in my career. dont forget the lack of the word 'iterate' in the decision makers vocabulary. and as soon as the word sunset is uttered you know your in for a bumpy ride once again

PaulHoule 7mo ago

People built a lot of great stuff with Ruby, PHP, Notes and VB. I don't know what the problem really is. Personally I think that whole Karpathy thing is the slowest thing in the world. I mean you can spin the wheels on a dragster all you like and it is really loud and you can smell the fumes but at some point you realize you're not going anywhere. My own frustration with the general slowness of computing (iOS 26, file pickers, build systems, build systems, build systems, ...) has been peaking lately and frankly the lack of responsiveness is driving me up the wall. If I wasn't busy at work and loaded with a few years worth of side projects I'd be tearing the whole GUI stack down to the bottom and rebuilding it all to respect hard real time requirements.

pydry 7mo ago

>After five or six cycles it does become a bit fatiguing. Use the tool sanely. That's increasingly not possible. This is the first time for me in 20 years where I've had a programming tool rammed down my throat. There's a crisis of software developer autonomy and it's actually hurting software productivity. We're making worse software, slower because the C levels have bought this fairy tale that you can replace 5 development resource with 1 development resource + some tokens.

whaleofatw2022 7mo ago
That lucky? In 18 years AI is the third or 4th tool forced upon a shop/team, I will say of those it is the forst one that is genuinely able to make me more productive overall, even with the drawbacks.

no_shadowban_3 7mo ago

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. Just another reason we should cut software jobs and replace them with A(G)I. If the human "engineers" were never doing anything precisely, why would the robot engineers need to?

01284a7e 7mo ago

All (not some) of the most successful devs I've known in the sense of building something that found market fit and making money off it were terrible engineers. They were fairly productive at building features. That's it. And they were productive - until they weren't. Their work ultimately led to outages, lost data, and sensitive data being leaked (to what extent, I don't even know). The ones who got acquired - never really had to stand up to any due diligence scrutiny on the technical side. Other sides of the businesses did for sure, but not that side. Many of you here work for "real" tech companies with the budget and proper skin in the game to actually have real engineers and sane practices. But many of you do not, and I am sure many have seen what I have seen and can attest to this. If someone like the person I mentioned above asks you to join them to help fix their problems, make sure the compensation is tremendous. Slop clean-up is a real profession, but beware.

michaelbarton 7mo ago
There used to be a saying along the lines of “while you’re designing your application to scale to 1m requests/min, someone out there is making $1m ARR with php and duct tape” It feels like this takes on a whole new meaning now we have agents - which I think is the same point you were making

AnimalMuppet 7mo ago

Software was an engineering discipline... at some places. And it still is, at some places. Other places were "hack it until we don't know of any major bugs, then ship it before someone finds one". And now they're "hey, AI agents - we can use that as a hack-o-matic!" But they were having trouble with sustainability before, and they're going to still, except much faster.

skybrian 7mo ago

People don't realize how much software engineering has improved. I remember when most teams didn't use version control, and if we did have it, it was crappy. Go through the Joel Test [1] and think about what it was like at companies where the answers to most of those questions was "no." [1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Towaway69 7mo ago
At the same time, systems have become far more complex. Back when version control was crap, there weren't a thousand APIs to integrate and a million software package dependencies to manage. Sure everything seems to have gotten better and that's why we now need AIs to understand our code bases - that we created with our great version control tooling. Fundamentally we're still monkeys at keyboards just that now there are infinitely many digital monkeys.
- PaulHoule 7mo ago
  Perrow’s book Normal Accidents postulates that, given advances which could improve safety, people just decide to emphasize throughput, speed, profits, etc. he turned out to be wrong about aviation (got much safer over time) and maritime shipping (there was a perception of a safety crisis in the late 1970s with oil tankers exploding, now you just hear about the odd exceptional event.)
  - Towaway69 7mo ago
    > Perrow argues that multiple and unexpected failures are built into society's complex and tightly coupled systems, and that accidents are unavoidable and cannot be designed around.[1] This is definitely something that is happening with software systems. The question is: is having an AI that is fundamentally undecipherable in its intention to extend these systems a good approach? Or is an approach of slowing down and fundamentally trying understand the systems we have created a better approach? Has software become safer? Well planes don't fall from the sky but the number of zero day exploits built into our devices has vastly improved. Is this an issue? Does it matter that software is shipped broken? Only to be fixed with the next update. I think its hard to have the same measure of safety for software. A bridge is safe because it doesn't fall down. Is email safe when there is spam and phishing attacks? Fundamentally Email is a safe technology only that it allows attacks via phishing. Is that an Email safety problem? Probably not just as as someone having a car accident on a bridge is generally not a result of the bridge. I think that we don't learn from our mistakes. As developers we tend to coat over the accidents of our software. When was the last time a developer was sued for shipping broken software? When was the last time an engineer was sued for building a broken bridge? Notice that there is an incentive as engineer to build better and safer bridges, for developers those incentives don't exist. [1]: https://en.wikipedia.org/wiki/Normal_Accidents https://en.wikipedia.org/wiki/Normal_Accidents

dec0dedab0de 7mo ago

I'm not even sure building software is an engineering discipline at this point. Maybe it never was. It's a craft.

tayo42 7mo ago
Software reminds me more of construction or home contracting work then engineering. We do the actual building of things
- sidpatil 7mo ago
  Construction and home contracting follow building codes.

dstroot 7mo ago

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. If I engineer a bridge I know the load the bridge is designed to carry. Then I add a factor of safety. When I build a website can anyone on the product side actually predict traffic? When building a bridge I can consult a book of materials and understand how much a material deforms under load, what is breaking point is, it’s expected lifespan, etc. Does this exist for servers, web frameworks, network load balancers, etc.? I actually believe that software “could” be an engineering discipline but we have a long way to go

beachy 7mo ago
Software and bridges are entirely different. If I need a bridge, and there's a perfectly beautiful bridge one town over that spans the same distance - that's useless to me. Because I need my own bridge. Bridges are partly a design problem but mainly a build problem. In software, if I find a library that does exactly what I need, then my task is done. I just use that library. Software is purely a design problem. With agentic coding, we're about to enter a new phase of plenty. If everyone is now a 10x developer then there's going to be more software written in the next few years than in the last few decades. That massive flurry of creativity will move the industry even further from the calm, rational, constrained world of engineering disciplines.
- mckn1ght 7mo ago
  Software packages are more complicated than you make them out to be. Off the top of my head: - license restrictions, relicensing - patches, especially to fix CVEs, that break assumptions you made in your consumption of the package - supply chain attacks - sunsetting There’s no real “set it and forget it” with software reuse. For that matter, there’s no “set it and forget it” in civil engineering either, it also requires monitoring and maintenance.
  - VorpalWay 7mo ago
    I have talked to colleagues who wrote software running on microcontrollers a decade ago, that software still runs fine. So yes there is set and forget software. And it is all around us, mostly in microcontrollers. But microcontrollers far outnumber classical computers (trivially: each classical computer or phone contain many microcontrollers such as SSD controllers, power management, wifi, ethernet, cellular,... And then you can add appliances, cars etc to that). If something in software works and isn't internet connected it really is set and forget. And far too many things are being connected needlessly these days. I don't need or want an online washing machine or car.

_dwt 7mo ago

> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.". - Edsger Dijkstra, 1988 I think, unfortunately, he may have had us all dead to rights on this one.

throwanem 7mo ago
One would as sensibly dismiss the concept of an assembly line as "how to build a car if you cannot." Dijkstra was a mathematician. It is a necessary discipline. If it alone were sufficient, then the "program correctness" fans would have simply and inarguably outdone everyone else forty years ago at the peak of their efforts, instead of having resorted to eloquently whiny, but still whiny, thinkpieces (such as the 1988 example [1] quoted here above) about how and why they would like history to understand them as having failed. [1] https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF [2] [2] I will freely grant that the man both wrote and lettered with rare beauty, which shames me even in this photocopier-burned example when I compare it to the cheerful but largely unrefined loops and scrawls of my own daily hand.
- bigfishrunning 7mo ago
  I think the real tragedy here is that we can spend *all* of our time trying to improve the quality of our output, but it simply doesn't matter, because as long as the button is where the boss wants it to be and is the right color, all is right with the world. Literally nothing else matters, and we (or at least I) have wasted a ton of time getting good at writing software.
  - throwanem 7mo ago
    As long as it continues to matter what the button actually does, I can't consider our effort to have been entirely wasted. We only have the misfortune to live in stupid and dangerous times, but good heavens, we're hardly the first in that, and hardly starved for examples from whom to learn.

kerblang 7mo ago

Engineering is two things: 1. Applied physics - Software is immediately disqualified. Symbols have no physics. 2. Ethics - Lives and livelihoods depend on you getting it right. Software people want to be disqualified because that stuff is so boring, but this is becoming a more serious issue with every passing day.

eloisant 7mo ago
That might vary by countries but in France with have an official "engineering degree" (diplome d'ingénieur) which is also a master's degree, and most software developers have this. So most software developers in France are absolutely software engineers.
zephen 7mo ago
> Software is immediately disqualified. Symbols have no physics. Many physical processes are controlled by software.
galbar 7mo ago
Software is applied mathematics, though
- kerblang 7mo ago
  And still not applied physics

perrygeo 7mo ago

> What are you building? This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs? Hard to shake the feeling that this looks like one big pyramid scheme. I strongly suspect that vast majority of the "innovation" in recent years has gone straight to supporting the funding model and institution of the software profession, rather than actual software engineering. > I'm not even sure building software is an engineering discipline at this point. Maybe it never was. It was, and is. But not universally. If you formulate questions scientifically and use the answers to make decisions, that's engineering. I've seen it happen. It can happen with LLMs, under the proper guidance. If you formulate questions based on vibes, ignore the answers, and do what the CEO says anyway, that's not engineering. Sadly, I've seen this happen far too often. And with this mindset comes the Claudiot mindset - information is ultimately useless so fake autogenerated content is just as valuable as real work.

ryandrake 7mo ago
> The last 10 years in the software industry in particular seems full of meta-work. Building new frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. All to build... what exactly? Don't forget App Stores. Everyone's still trying to build app stores, even if they have nothing to sell in them. It's almost as if every major company's actual product is their stock price. Every other thing they do is a side quest or some strategic thing they think might convince analysts to make their stock price to move.
- jimbokun 7mo ago
  > It's almost as if every major company's actual product is their stock price. They are pretty much legally obligated to act in this manner.
  - wholinator2 7mo ago

cucumber3732842 7mo ago

Software engineering is real engineering because we rigorously engineer software the way real engineers engineer real things. Software engineering is not real engineering because we do not rigorously engineer software the way "real" engineers engineer real things. <--- YOU ARE HERE Software engineering is real engineering because we "rigorously" engineer software the way "real" engineers engineer real things. Edit: quotes imply sarcasm.

psychoslave 7mo ago

Hey Visual Basic is still there, and last time I checked it was still the goto option to do OLE Automation. RoR is no longer at its peak, but is still have its marginal stable share of the web, while PHP gets the lion part[1] Ok, Lotus Notes is really relic from an other era now. But it’s not a PL, so not the same kind of beast. Well, also LLMs are different beast compared to PL. They actually really are the things that evocate the most the expression "taming the beast" when you need to deal with them. So it indeed as far away as possible of engineering as one can probably use a computer to build any automation. Maybe to stay in scientific realms ethology would be a better starting point than a background in informatics/CS to handle these stuffs. [1] https://w3techs.com/technologies/comparison/pl-php https://w3techs.com/technologies/comparison/pl-php

cyanydeez 7mo ago

As far as I can tell, the only reason agents exist is because large context increase the probability of context poisoning, purely by the inability of these models to actually make conceptual decisions about the context. I was interested in making a semi-automous skill improvement program for open code, and I wired up systemd to watch my skills directory; when a new skill appeared, it'd run a command prompt to improve it and cohere it to a skill specification. It was told to make a lock file before making a skill, then remove the lock files. Multiple times it'd ignore that, make the skill, then lock and unlock on the same line. I also wanted to lock the skill from future improvements, but that context overode the skills locking, so instead I used the concept of marking the skills as readonly. So in reality, agents only exist because of context poisoning and overlap; they're not some magicaly balm to improving the speed of work, or multiplying the effort, they simply prevent context poisoning from what's essentially subprocesses. Once you realize that, you really have to scale back the reality because not only are they just dumb, they're not integrating any real information about what they're doing.

hu3 7mo ago

> What are you building? Does the tool help or hurt? > People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. I'm assuming you're saying these tools hurt more than help? In that case I disagree so much that I'm struggling to reply. It's like trying to convince someone that the Earth is not flat, to my mental model. PHP, Ruby and VB have more successful code written in them than all current academic or disproportionately hyped languages will ever have combined. And there's STILL software being written in them. I did Visual Basic consulting for a greenfield project last week despite my current expertise being more with Go, Python, C# and C. And there's a RoR work lined up next. So the presence gap between these helpful tools and other minor, but over index tools, is still increasing. It's easy to think that the languages one see mor often in HN are the prevalent ones but they are just the tip of the iceberg.

devin 7mo ago

Absolutely agree. I'm watching a team which is producing insane amounts of code for their team size, but the level of thought that has gone into all of the details that would make their product a fit predator to run at scale and solve the underlying business problem has been neglected. Moving really fast in the wrong direction is no help to anyone.

bodash 7mo ago

Exactly! I’ve noticed a resounding amount of people are writing the same pieces recently, it’s almost like everyone’s sounding their alarm for the upcoming tsunami. Who’s listening? Here’s my piece: https://humantodo.dev https://humantodo.dev

keyle 7mo ago

Agreed. I've been building software for 25 years+. At some point I became so burnt out I couldn't look at an IDE or coloured text for that matter. I found the way back by just changing my motto and focus... Find good people, do good work. That's it, that's all I want. I don't care whether the 'property is hot' or what the market is doing anymore, I just build software in my lane, with good people around.

lmm 7mo ago

> It's not about agile or waterfall or "functional" or abstracting your dependencies via Podman or Docker or VMware or whatever that nix crap is. It is though. Picking the right approaches and tools makes more difference than anything else. Sure, you don't need the right tools if you can make the right choices - but it's much easier to pick a better methodology than to hire smarter people.

sublinear 7mo ago

Perhaps this is the wrong place to plant this thought. Maybe nobody will read it. These comments are now many hours old and HN has a way of walking away once they have had their turn shouting into the void. I once received a "bonsai" seed kit from a former boss during a holiday dinner. I think it was meant as a joke, but even now I'm not so sure. I planted those seeds anyway. I told some people about it and they immediately mocked me saying it was a waste of time and going to take 30 years. This interaction immediately said everything to me about the expectations and attitudes of others. Obviously, they grew like any other plants and actually quite nicely. Of course they're a commitment, but not a huge one. I just wanted some plants for my apartment and they fit the bill. In a few years I had good looking plants. A decade later, I still have them and they're now more recognizably "bonsai". My home now looks nicer, I have a story to tell, and I learned a little bit from a very low stakes hobby. My point is, I think it's nice when people have projects. I think it's nice to see what comes of it. I guess my only regret is ever saying "I planted bonsai" too soon just because that's what the box said. I didn't know how else to describe what I had done that weekend to those people who threw theirs in the trash.

danhite 7mo ago
> Maybe nobody will read it. These comments are now many hours old and HN has a way of walking away once they have had their turn shouting into the void. All that is gold does not glitter, Not all those who wander are lost; The old that is strong does not wither, Deep roots are not reached by the frost. ― J.R.R. Tolkien, The Fellowship of the Ring
jafitc 7mo ago
that's a great story!
nathan_douglas 7mo ago
I was thinking the other day about how frustrated my desire is to perform some kind of Great Work. A few years back I was intensely interested in making something like Nethack - a roguelike game with a deceptively simple surface and incredible complexity in the engine. I worked on several for a few years, different angles on the whole "managing complexity" thing. I suppose I learned a lot, and I made some interesting things, but I never really produced anything I felt I could work on for 20-30 years, that would be sort of my artistic statement as an engineer (if such a thing makes any sense). I wouldn't've laughed at you. I view bonsai as a representation of steadfastness, endurance, determination, effort, (and self-mastery?) in the face of tremendous hardship, challenge, and deprivation. That said, I've never been particularly good at any of those things. IDK if I would've taken you all that seriously either, though. Six months until you move and it's left behind on the curb. Or a year and a half until your cat knocks it off the windowsill. Or three years until some blight infects it and it dies off despite your best efforts. Eight years until, for whatever reason, it just succumbs to some kind of vegetative ennui. Nine years until your significant other overwaters it one too many times and the roots rot. That's not meant disrespectfully. I just tend to view uncertainty and complexity as opportunities for shit to go sideways. Especially in this case, where it's unlikely you'll wake up to find your tree has spontaneously cloned itself, or has eaten a 1-UP mushroom. Disasters happen all the time, and miracles don't. I suppose I'm just having a bit of a spiritual crisis right now. But thank you for your comment. It gives me a lot to think about, in a positive sense.

ray_v 7mo ago

Maybe it's more about a rush to share how awesome it is that you compressed your time-to-release down to days and not weeks or months - when in reality that's a good thing in the sense that you get to a failure state much FASTER, and failure states are good, because that means that you get to iterate and get past those failures FASTER. I don't think people were releasing at this pace, so the failure states are fast and furious so there is just that much more viability. I think the microslop windos failures lately are just them being the same "them" that they've always been .. just MUCH faster. (they just need to stop monkeying with windows and stop adding more features on top of an already shaky foundation.) Maybe we just need more of the stories like Anthropic working with Mozilla to squash 5x the amount of bugs in a similar time frame first, AND THEN "vibe a browser together from nothing but specification files and an army of bots in a weekend".

crystal_revenge 7mo ago

> What are you building? I think AI really pushes this higher up the abstraction layer: > What problem are you solving? I've spent a good amount of my careering using engineering and math to solve specific problems, I'm usually adjacent to software teams. What I've seen happen with agentic coding is that traditional software engineers keep focusing on using it to build software, while ignoring the problem they're trying to solve. Meanwhile I've seen junior data analysts start interfacing with applications and tools they never dreamed of before, and delivering results to stakeholders in record times. Things that were previously blocked by engineering no longer are. But many engineers today are not really problem solvers, they're software builders. The idea that solving the end users problem is the goal, not building them software, is incomprehensible. And so they continue to struggle to use AI effectively because they're trying to build software with it. Which it's not terrible at, but it's really the wrong tool for that job. Sometimes software is necessary to solve a problem, a few years ago, software was necessary for a fairly large problem surface area (though, to your point, even then a lot of software was not really built to solve those problems). Today that surface area is shrinking, and as economic constraints loom on the horizon, I believe it will increasingly be people who are solving problems (with or without AI) that will be the ones surviving.

Panzer04 7mo ago
The kind of jobs an analyst are doing are probably the most amenable of everything to LLM assistance. Small, bounded, etc. The bigger the problem set and context the less helpful an LLM gets.

cookiengineer 7mo ago

I am just using Go at this point and stopped caring about my own opinions. I live in the happy place in negligence. Go software has almost zero maintenance costs and it will continue to build my programs in 10 years with zero changes to my codebase being necessary. I probably will never touch C++ again, even though CGo is the most painful FFI/ABI implementation I've dealt with. Just today I tried to build a project that's using bergamoth and a shitload of broken C++ dependencies and decided to not give a damn after 5 hours of trying to fix crappy code that changed for whatever reasons between c++14 and c++15, well, or the dependencies are broken, or the dependency versions are broken, or the maintainer's code never compiled in the first place... I just don't care. My hopes were higher during the conan peak days, but now the ecosystem is just so broken even with jinja and whatever build framework the new kids are using. I guess I just really hate the C++ ecosystem, and the lack of self reflection in there about the self inflicted pain that shouldn't be necessary in 2026. In regards to agentic coding: I am toying around with codestral:22b right now and xiaomi's mimo models, and am building my own local dev environment which makes this kinda nice. It's local and I like it, sometimes need to use claude still but it's getting there. But I am delegating only the gruntwork, not decisions, so I use temperature usually below 0.3. My approach is to make this sandboxed per folder I run it in and that agents are only allowed to communicate via notes or tasks, so that they are forced to use better documentation. Specific roles don't have write access to certain things, e.g. coder can't touch tests, and tester can't touch code.