One of the things that killed it is it suffered the same issue as Visual Basic in that time.
Anyone could create an application. 99% of the time that anyone had 0 UX experience and created travesties that were horrible to use. So people associated the poorly designed database with the product.
Another major issue was that the first implementation most people saw of it was the email side, and it could be a truly clunky and unpleasant email client. This soured opinions before people delved into the document management and programmability features that email handling were just one use of.
From a technical point of view one of the bonuses I saw was that it used PKI throughout for encryption and such, which very little other software did. Though this was also clunky at times especially for non-technical users (has anyone ever made the use of PKI a smooth process for those who don't care to know the details?). Proper ACL management too rather than more simplistic permissions, but again this could be very clunky.
Though I'm not sure why we are talking entirely in the past tense, while Domino & Notes are not widely used anymore, they are still out there and developed (under the name HLC Notes) with the last release (adding LLM based “AI” features, of course…) was Jun last year and a bugfix update a few months later. My experience with Domino/Notes was in the 00s and early 10s when I was the accidental admin (the only guy who really understood it left) of a mail and document server based on it, hopefully the clunkiness complaints at least have been addressed since then.
There were UX horror stories on the web as well. I guess it is the physical connection of having to start up your Notes application in work and being forced to use poorly designed apps.
I think another difference is that the Cambrian explosion of web apps vying for user attention meant that many web users had experience using both poorly-designed web apps as well as well-designed web apps and could gravitate towards the latter.
Whereas many Notes applications were internal so there was no "survival of the fittest" and the UI toolkit was passable at best. As a result, many Notes users never experienced a well-designed Notes app.
I was like this a few months back. You want to code and solve problems, but the AI can do all that for you. I got over it by moving the problem solving further down the chain. Treat the AI the team you are directing to solve the issue.
If I wanted to become a project manager I would have become one. AI has just exposed that many "engineers" are "temporarily embarrassed project managers", which is fine in the sense that it makes it clearer who actually enjoys making things and who just wants the end result regardless of how it's made.
> If I wanted to become a project manager I would have become one.
It's not so much a project manager. I have something I want to build, I create the plan and work slowly through it with Claude. Stopping at every piece and reviewing as I go.
I can confirm the code is good, but also when it takes a different approach I question why it took that approach. Occasionally I learn something.
> who just wants the end result regardless of how it's made.
Sometimes you want the app but don't care how it gets created, because its helping you focus on what you really want to do. For example I created a mindmap App in XCode on-par with XMind. Not every feature, but everything I use.
>AI has just exposed that many "engineers" are "temporarily embarrassed project managers", which is fine in the sense that it makes it clearer who actually enjoys making things and who just wants the end result regardless of how it's made.
AI has also exposed that many "engineers" are just "people who like fiddling with code" and that's fine in the sense that it makes it clear who are the actual engineers who are engineering solutions to real human problems and who just want to tinker with code.
Like imagine slandering a civil engineer "you just want a bridge that is safe and lasts for a century, you don't care about enjoying the journey of construction".
Haha! Your analogy doesn't work on multiple levels. Firstly, if you're outsourcing your work to AI you're not the engineer anymore. A civil engineer is different from a manager of a civil engineering project. Just like I wouldn't call myself an artist if I got AI to generate me some art, I wouldn't call myself a software engineer if I got AI to write all the code for me.
Secondly, it's not just about "enjoying the journey of construction", it's also about caring about the quality of the end results. Getting vibe coded software that is as stable as a "bridge that is safe and lasts for a century" is not a matter of careful engineering decisions, it's mostly a matter of luck, because you don't have the necessary oversight in the quality of the output unless you're doing extensive reviews of the generated code, at which point you greatly diminish the time you're supposedly saving.
False. If you "outsource your code" to a compiler and just write higher level language, you're not an engineer. You literally don't own any of your own code, just an abstraction of it written in human language. See how that works? An engineer can delegate -- period.
- "I wouldn't call myself a software engineer if I got AI to write all the code for me"
If all you do is write code you're not an engineer. I think you fundamentally don't know what engineering is. In a very real sense engineering is what you do when you're not coding. The civil engineer doesn't construct the bridge personally.
- "Secondly, it's not just about "enjoying the journey of construction", it's also about caring about the quality of the end results".
Codemonkeys DON'T CARE about the quality of the end result. They only care about their little corner of the zen garden. Writing real software for real users is by far the worst part of a codemonkeys job.
- "Getting vibe coded software that is as stable as a "bridge that is safe and lasts for a century" is not a matter of careful engineering decisions, it's mostly a matter of luck"
Nonsense. The engineer who spends 90% of his time architecting systems and testing them at a high level is making safer and more stable software than the codemonkey who spends 90% of his time tinkering with the details. Forest for the trees.
- "unless you're doing extensive reviews of the generated code, at which point you greatly diminish the time you're supposedly saving."
Who said anything about "saving time"? We're engineering high quality systems. Some of us spend our time at a higher level, thinking holistically about the system, testing multiple concepts and rapidly iterating. Others demand bespoke handwritten code and in the time allowed can barely finish a single concept with a questionable amount of polish. Whatever their first idea is will ship, and they'll have no real ability to justify the architecture other than vibes.
Yes and no. Engineering does involve delegation but what defines an engineer is is what work they do, not what work they pass onto others.
If it helps you understand this, consider the role of an engineer as someone that makes engineering decisions. If you give a specification to a colleague and ask them to write code for you, then you're delegating those engineering decisions. When you write high level code, yes you allow a compiler or interpreter to determine how to turn your instructions into machine code, but you have made engineering decisions in order to design the end result. If you give instructions via product specifications, then you have acted as a project manager or business analyst, not as an engineer.
To use another analogy, imagine you are a chef and you go to eat at a restaurant you don't work in. When you order from the menu, you are not a chef at that moment, even if your background suggests you are capable of being one. Similarly, ordering code from an AI agent does not give you the right to call yourself an engineer when doing so, as you did very little of the real engineering work to produce the end result.
> If all you do is write code you're not an engineer.
Engineering requires thought and application of thought, and if you're outsourcing both then you don't qualify as an engineer.
> The engineer who spends 90% of his time architecting systems and testing them at a high level is making safer and more stable software than the codemonkey who spends 90% of his time tinkering with the details.
The devil is in the details. A technical architect that doesn't understand the tradeoffs in the designs they're specifying isn't worth the money they earn.
> Who said anything about "saving time"?
Almost everyone that is selling the benefits of AI. Clearly you haven't been paying attention to industry trends.
> Like imagine slandering a civil engineer "you just want a bridge that is safe and lasts for a century, you don't care about enjoying the journey of construction".
Would you currently trust a bridge designed by a civil engineer using AI for all of their calculations ?
> Would you currently trust a bridge designed by a civil engineer using AI for all of their calculations ?
Not a great comparison. I'd agree with you if it was straight up vibe coding.
But co-creating (which is what I do) I create plan, then step through it with Claude. Claude creates a small part of what I want, I review, tweak or ask Claude why it took that approach if its different.
I know the subject matter of what it is creating, so in this sense it is safe, as long as I am reviewing everything.
It gets dangerous if you just let it create something without any interaction or understanding of what is being created.
>Would you currently trust a bridge designed by a civil engineer using AI for all of their calculations ?
Of course. I've seen how sloppy and lazy humans are, and I already use the bridge, and if the safety truly came down to the output of single person, then the risk is already significant.
I must say, I got a chuckle at "using AI to do their calculations". Oh no, my agent is going to write a python script to do basic maths, and check their work against a series of automated tests, the sky is falling!
All run of the mill software is gone or on borrowed time. Why pay a subscription for a product that I can get something Claude to build it for me.
Before I was building tools, now I am building full applications in less time than I did before for tools.
What will be around for a while is where you need an expert in the loop to drive the AI. For example enterprise applications. You simply can't hand that off to an AI at this point.
> Why pay a subscription for a product that I can get something Claude to build it for me.
We've already seen this with OSS. Even with free software, support, self-hosting, and quirky behavior have proven to be enough to keep most people and business away.
Thing is, AI will also be able to provide substantial support for software it writes. And it will make self-hosting a lot less painful, too. Quirky behavior will still happen, but eh, Excel imports numbers as dates. You can't buy your way out of quirky behavior for all the money in the world.
I am building them because I am using them to do my work faster.
I'm not selling anything, but I can see the quality of what is created and it is on-par with much of the stuff on the App store.
No one would even notice that it is a co-creation unless I mentioned the time to create it.
Just to be clear. Vibe coding implies that you are not reviewing the code that is created, or even knowing what is being created. That is not what is happening.
I used a bunch of tools from https://setapp.com/ and no longer subscribe. I used to pay for Linear for all my personal projects, built one with CC that perfectly fits my needs… I also built a myriad of small tools that help me automate bunch of busy work I used to do manually, both for professional and personal projects
If the core of the post is yours I think it is fine, but there are so many pieces which the LLM always uses in these things that they stand out more than emdashes.
Some examples.
> I've felt the grief too—but mine resolved differently than I expected, and I think that says something about what kind of developer I've been all along.
> I kept having this nagging sense that we were mourning different things.
> Here's what I notice about my grief: none of it is about missing the act of writing code. It's about the world around the code changing.
> If you're mourning the context—the changing web, the shifting career landscape, the uncertainty—that's real too, but it's more actionable.
It uses these kinds of patterns over and over that it becomes obvious Just go on LinkedIn.
Anyone could create an application. 99% of the time that anyone had 0 UX experience and created travesties that were horrible to use. So people associated the poorly designed database with the product.
reply