It also does an amazing job of taking snapshots of posts. I use it all the time to grab posts from HackerNews so I can mark them up.
And it automagically syncs everywhere across devices and lets me store way too many files on the web like the ADD packrat I am, without breaking a sweat.
In short, this software just works, and it works well.
So when somebody behind Zotero talks about how to develop software, I listen.
And it's a fun post with some history. You should save this post to Zotero, and then read it.
The reason great artists spend so much time developing their skills is that the result no one knew they wanted comes from skill and the new possibilities emerging from that.
So as a software developer now might be the best time to throw system design on it's head and develop without a direction but make sure everything is as good as one can forge it.
Surprising functionality and stuff not found elsewhere then more or less simply emerges from that.
Granted - that has a certain freedom and no pressure to make money as a prerequisite but so do the 5 years noted here.
> But that slow formation led to software that was durable rather than ephemeral, with a strong foundation that could be built upon.
People say that agentic development is great because you can churn out so much so fast. But that doesn't mean that any of it will be truly good and reliable.
The things that are truly insightful and solid end up being used exponentially more, which makes the linear cost of extra development time (asymptotically) insignificant in the cost/benefit equation.
It may be so but the article does not claim that the strong foundation is the code, rather it seems to be product design, and design of other products, at that (the two predecessors, webapp and desktop app). No reason why you couldn't study existing products now and tell your agent to build something based on that.
> If AI had existed in the early aughts, we could not have accelerated Zotero’s conception, because we did not know exactly what we wanted, and so could not have written coherent prompts for an LLM. Instead, it took a great deal of time and collaboration to develop a clear vision for what Zotero should be.
AI doesn't preclude this. In fact, it can help accelerate parts of it.
He's describing the typical big project lifecycle:
- Examine the landscape
- User research (how they use existing software, what their frustrations are, etc)
- Brainstorming
- Early ideas and prototypes
- Refinement, user feedback
- Solidify the vision and high level process design
- Choose technologies
- Design & architecture
- Plan out phases
- Build phases, then test them with users
LLMs are great at research, and great at prototypes. Once you have your design, they're good at coding as well. They're also good at distilling user feedback.
As somebody responsible for the acquisition of users and growth of a company in terms of customer and revenue, this is a VERY salient point:
> “… we could not have accelerated Zotero’s conception, because we did not know exactly what we wanted, and so could not have written coherent prompts for an LLM.”
A surprising proportion of software products, maybe even businesses today, are solutions in search of a problem.
Sometimes that’s okay, but only sometimes. And being a solution in search of a problem requires you to get everything /else/ pretty much perfect if you want to succeed.
The fact Zotero paid attention to what people wanted, and gave it to them, and were market oriented, is demonstrably a big part of their success.
It is MUCH easier to make something people want, than to make them want something you made.
Agreed, but it is also much easier to get something made in the first place. LLMs enable rapid prototyping and rapid shifting to solve real problems. My applications are morphing from mediocre to highly useful problem solving machines much more rapidly now.
That’s a really good point! But I am always surprised by how often people will avoid putting their prototypes out there and let the market shape their product.
Rapid prototyping is an amazing opportunity afforded to us by AI. But some people use that potential to spend even longer on a more developed prototype that they are too attached to to get feedback on!
good things take time because they grow from something like seed. as that seed grows, it figures out its local and global context. a curious and patient caretaker of this seed will spend a lot of time looking at it, understanding it, trying to figure out the right way to give the small plant a steady foundation. with care and attention, it could grow into a tree and attract all sorts of other insects, animals, and all sorts of life.
speed kills quality. it’s literally impossible to make anything good fast.
we know this, and it still applies to software. while we may be able to make things faster, they will never become good (or great) without an incredible amount of care, patience, and joy from its maker.
there are no shortcuts to quality. it will always take a lot of time to make anything good.
I am not sure it IS impossible to make anything good fast. Look at how many incredible songs have been made in a single afternoon, or fantastic ideas for a simple product came to somebody in an instant.
Your comment made me think two things:
• Sometimes constraints make things better, and ‘speed’ can occasionally make you prioritise the things that actually matter so you deliver stuff that counts
• Sometimes, thinking longer about something doesn’t get you closer to the correct answer. You can rearrange and refactor and rewrite and redesign, but you won’t always get something objectively better than what you originally came up with. It’s still your thoughts, your brain and your ways of working that shape the output (and they haven’t changed).
Investing more time to make something better should be a conscious decision. Perhaps it’s one people decide against for the wrong reasons.
But sometimes things need something other than time and effort spent to make them better.
A very very strong point. I have personally detailed entire projects because adding a feature seemed easy with AI. It is very difficult to vibe code and not add a bunch of useless crap features.
Really? I find LLMs quite bad at deleting code. If you ask them to add a feature, then later take it out again, the codebase still grows. It always grows. Every time I've tried it, llms have failed to simplify code via refactoring. Even fable is incredibly bad at this for some reason.
LLMs are excellent at making prototypes though. And prototypes can be an excellent way to stop yourself from implementing the wrong features in the first place.
I guess we'll only be able to verify this 10-15 years after coding agents arrived. Personally, I think there will always be a market for apps created with care and great attention to detail.
This post is about Zotero. https://www.zotero.org/
If you are not an academic, you might not know Zotero.
It is such a pleasure to use. Every app should be like this.
I read everything in it, including books I'm going through right now from https://teachyourselfcs.com/
It also does an amazing job of taking snapshots of posts. I use it all the time to grab posts from HackerNews so I can mark them up.
And it automagically syncs everywhere across devices and lets me store way too many files on the web like the ADD packrat I am, without breaking a sweat.
In short, this software just works, and it works well. So when somebody behind Zotero talks about how to develop software, I listen.
And it's a fun post with some history. You should save this post to Zotero, and then read it.
So as a software developer now might be the best time to throw system design on it's head and develop without a direction but make sure everything is as good as one can forge it.
Surprising functionality and stuff not found elsewhere then more or less simply emerges from that.
Granted - that has a certain freedom and no pressure to make money as a prerequisite but so do the 5 years noted here.
People say that agentic development is great because you can churn out so much so fast. But that doesn't mean that any of it will be truly good and reliable.
The things that are truly insightful and solid end up being used exponentially more, which makes the linear cost of extra development time (asymptotically) insignificant in the cost/benefit equation.
AI doesn't preclude this. In fact, it can help accelerate parts of it.
He's describing the typical big project lifecycle:
- Examine the landscape
- User research (how they use existing software, what their frustrations are, etc)
- Brainstorming
- Early ideas and prototypes
- Refinement, user feedback
- Solidify the vision and high level process design
- Choose technologies
- Design & architecture
- Plan out phases
- Build phases, then test them with users
LLMs are great at research, and great at prototypes. Once you have your design, they're good at coding as well. They're also good at distilling user feedback.
It can also slow it down as people get distracted experimenting with features they can build quickly.
> “… we could not have accelerated Zotero’s conception, because we did not know exactly what we wanted, and so could not have written coherent prompts for an LLM.”
A surprising proportion of software products, maybe even businesses today, are solutions in search of a problem.
Sometimes that’s okay, but only sometimes. And being a solution in search of a problem requires you to get everything /else/ pretty much perfect if you want to succeed.
The fact Zotero paid attention to what people wanted, and gave it to them, and were market oriented, is demonstrably a big part of their success.
It is MUCH easier to make something people want, than to make them want something you made.
Rapid prototyping is an amazing opportunity afforded to us by AI. But some people use that potential to spend even longer on a more developed prototype that they are too attached to to get feedback on!
speed kills quality. it’s literally impossible to make anything good fast.
we know this, and it still applies to software. while we may be able to make things faster, they will never become good (or great) without an incredible amount of care, patience, and joy from its maker.
there are no shortcuts to quality. it will always take a lot of time to make anything good.
Your comment made me think two things:
• Sometimes constraints make things better, and ‘speed’ can occasionally make you prioritise the things that actually matter so you deliver stuff that counts
• Sometimes, thinking longer about something doesn’t get you closer to the correct answer. You can rearrange and refactor and rewrite and redesign, but you won’t always get something objectively better than what you originally came up with. It’s still your thoughts, your brain and your ways of working that shape the output (and they haven’t changed).
Investing more time to make something better should be a conscious decision. Perhaps it’s one people decide against for the wrong reasons.
But sometimes things need something other than time and effort spent to make them better.
https://assets.buttondown.email/images/93382906-4996-445c-81...
is just of some passionate academics working on a project with no real economic or social media incentives driving it.
LLMs are excellent at making prototypes though. And prototypes can be an excellent way to stop yourself from implementing the wrong features in the first place.