- llms let us build exactly what we want fairly quickly nowadays, or at least a prototype and
- being able to build these features (or separate products) quickly is exactly the trap
> It’s the same test I keep applying when picking the right problems to solve — does it make the boat go faster?
Who knows this though? It's rarely engineers. Product often has a good sense within their lane. Leadership usually (at good companies) is mostly aligned, with some nuance depending on who's speaking.
It's a good sentiment but rarely a single person's decision.
As I said, I see these pop up and I'm usually annoyed because what new take could someone bring at this point, but I read them every single time :p
Today, was thinking about 1) what do I actually want to build AND maintain? and 2) what do I want to build and maintain that if I didn't do it, someone else probably wouldn't and I'd be really annoyed that it didn't exist in the world?
I dunno, just two current questions I thought you might find interesting, not sure if it adds anything new to the discourse, may be a challenge throughout different parts of human history :-D
As an engineering leader you’ve got to advocate for it against product/design all the time.
Now whenever someone brings that up, I ask “What question are they wanting the answer to?”. It usually leads to either a new feature or just clarifying where that question can be answered. Looks like you’ve caught onto that same school of thought.
Sometimes people just want to feed data into their own warehouse so they can query data across different pieces of software, or they are too stubborn to get to the bottom of what question they’re trying to answer.
For example, suppose someone wants special logging whenever a certain field is edited... And then you find out their real goal is to be able to copy-paste old values back in when someone calls up support and says "oops something went wrong." Now the reporting tool is an intermittent part of our customer support.
In contrast, imagine if there was a real "settings events" table that recorded changes in the app and users could go see them. Or a new concept of "revisions", instead of single mutable field.
The team did not like that I pointed out we could have added the number to the home page in a few minutes...
"But can't you just make something exactly like we imagine? We're already paying you and buying stuff is paperwork".
If you are building a product the user already knows, that might not be difficult.
We work in the sleep space, where everyone expects a hypnogram and a sleep score. Even though these things don't actually tell you anything real. They are of little value to most people, but that is the expectation.
One time it was user profile avatars that took a site down. I work in line of business software, nobody needs avatars.
The most important decision is what limitations and constraints you are prepared to accept. There are always limitations and constraints but they are rarely identified up-front.
The most difficult, hard-to-revert decisions are those related to hard constraints imposed by the systems and/or data you have to rely on. Maybe it's not physically possible to obtain the data you need to solve the problem you need to solve for the price you need for it to be viable. Maybe you need to be able to process large files which may take many hours to complete. Or your input data grows father than you can process on a single CPU core. Or the security requirements of a particular piece of data means that you can't efficiently connect it to some external piece of data as you need.