Top
Best
New

Posted by tosh 6 hours ago

Someone behind the software(karrisaarinen.com)
246 points | 98 commentspage 2
thinkindie 3 hours ago|
I’ve found myself raising the bar every day with my team in terms of my expectations of what their deliverables should be. I gave them enough time to adjust but I observed that the average engineer believe they can do the same with less effort while they should rather think about delivering more and of higher quality, and taking the extra time available to connect the dots.

I believe this is going to be a huge filter moving forward.

sebmellen 3 hours ago|
My feeling is that this will be near apocalyptic for the devs who found their joy in the finer grained aspects of implementation, like crafting individual “perfect” blocks of CSS and component code. Many developers enjoy the practice of writing software, as something distanced from actually delivering a product.

Retooling thought to be delivery-oriented is very difficult.

thinkindie 1 hour ago||
I used to be among those that appreciate a well structured codebase. I used to spend a lot of time thinking about that and making sure each file was as clean as the timeline allowed, with regular tech debt cleanup when you had to cut some corners or you accumulate some cruft.

And I’m still are, with the difference that I still enforce this at agent and code review level because I believe a solid foundation is important for long term success, especially now that it can be cheaper to achieve if you choose to

cryptolobster 2 hours ago||
I'd say the text really captures something a lot of us feel but can't put into words. We're used to judging software by how many features it has, but what actually gets us is something else: the feeling that someone put their head and heart into the product. The author is right. When each new feature gets added in isolation, the product loses its coherence and turns into a patchwork quilt.
conqrr 5 hours ago||
This is everything not just software. Although a lot of what we wear, eat and drink come from factory, if it didn't, you can always tell the someone behind it. Handcrafted things easily have more value and I find myself thinking more about it only after it affected what I did daily (software). Since Industrial revolution, countless things have gone to the factories. Makes me think how little we really empathize as humans.
Kinrany 3 hours ago|
I don't think the distinction the article makes is between handcrafted and mass-produced. "Software factories" is just the name we gave to these slop machines recently, but it's been the same with teams that churned out features without thinking much beyond the requirements. When it comes to physical items, factories can be set up with care and handcrafted items can be churned out without any.
convenwis 3 hours ago||
This is why I really hope that we don't end up in the world that a lot of AI pilled people believe is the future: one in which chatting with the AI drives everything and interface basically goes away. While I don't think that it is impossible that we at least go partially down this path it would make me incredibly sad.

Well thought out and built software is so satisfying to use that I would be very sad to see it go. Particularly given that the current crop of frontier labs don't really seem to care that much about the craft and feeling of software (at least relative to their other priorities.

sp1nningaway 1 hour ago||
Strong agree. This also applies to how every org I’ve been a part of that preaches data driven decision making is either using data to make unintuitive wrong decisions or chasing down stats that reinforce their priors.
blauditore 1 hour ago||
Yeah, the implementors also act as representatives of the human users of software to be built. That's something which can't be automated away pretty much by definition.
lightandlight 3 hours ago||
I agree, and this is why I dislike A/B testing for product development. It replaces the "someone" with vague broad appeal or rogue optimisation forces.
riazrizvi 3 hours ago||
Only an audience of software developers would find that first statement insightful. The rest of the world generally understands that expression is a product of the human performing the execution of that expression.

That mowed lawn. That email message. That meal they made for you. They are windows into some specific humans.

nagalluri 5 hours ago||
Give two different people the same problem, and you'll likely get two different solutions shaped by differing experiences and ways of thinking. I think software is an example of this manifested.
solatic 4 hours ago|
I (think I) agree with the author, but I want to point out that his core grievance has little to do with AI software factories.

> The product changes are primarily additive... I think the reasons for this is that it's lot easier to add new capabilities, than rethink existing capabilities.

This is perhaps the biggest difficulty in Product, and the core of the Innovator's Dilemma. Changes or removals, fundamentally, fuck with how somebody uses your product. It is very, very rare to ship a feature - something that inspired somebody in Product, got all the internal stakeholders to sign off, including getting leadership to fund it - and have nobody use it, so that it isn't controversial to remove it; even then, removing it competes with resources for adding something else, so it's still controversial to remove it. When somebody uses something that you fucked with, you risk them churning, that simple.

Coming up with good features to add is not hard. Everybody and their grandma has ideas. A simple spreadsheet can count which ones are most popular and are proposed most often. This should not, in and of itself, dictate what you build next, and bad Product leadership looks like following mass diktat.

Good Product leadership is not afraid of the consequences of fucking with the user. Good Product leadership has both the courage to reformulate the offering and gets the reformation right, because they intuitively understand the user, the domain, and where they sit in it, better than anyone else. They ship stuff that fucks with you because they understand the difference between the bad kind of being fucked with, and the good kind. And if you churn, then you churn. So be it. You can't actually make everyone happy all the time, so focus on making happy the people who get it, and accept losing the rest. That's also easier to say when you have $100k in ARR with $1k ACV, compared to $5m in ARR with $2.5m ACV.

Good Product leadership is rare because good leadership is rare. AI has nothing to do with it.

paimapi 4 hours ago|
Good Product leadership is rare because Product rarely uses their own product.

I can count on one hand the number of PMs in my career who understood the platforms they worked on outside of their extremely narrow domain - and even then that narrow specificity was often a distorted lens that came from the customer interviews they did that they remembered or found evocative. And this just gets worse the further up the chain you go.

Engineering knows that the best way to improve a product is to dogfood it. Nothing beats regular lived experience long enough for the human brain to start its pattern recognition. But nobody wants to eat their own dogfood, they want the kibble from another brand that has all the shiny marketing attached.

If I had my way, I'd stick PMs into shadowing sessions with Support on the regular for sentiment analysis. No relying on Support management to relay upwards trends - there's far too few Support managers worth their salt.

redanddead 32 seconds ago|||
The best PMs usually emerge from support

But they burn out quick because the know the pain is there

solatic 3 hours ago|||
> Product rarely uses their own product... nobody wants to eat their own dogfood

I somewhat agree with you, and think you're right at least part of the time. The main disagreements I have are (a) dogfooding is not a panacea; it can result in products that are built for the user who pays the least rather than for the wider market, and (b) too often, Product is simply not hired from the market. Product rarely works when the person coming into the role was a software engineer who got an MBA, unless the product is also used by software engineers. I can't imagine trying to lead Product for, say, Excel, without a background as an accountant or banker, who lived with the problem day-in-day-out and has strong opinions about what the solution looks like.

More comments...