←back to thread

Has the cost of building software dropped 90%?

(martinalderson.com)
413 points martinald | 3 comments | 08 Dec 25 19:00 UTC | HN request time: 0.408s | source
Show context
BigHatLogan ◴[08 Dec 25 19:58 UTC] No.46196834[source]▶
Good write-up. I don't disagree with any of his points, but does anybody here have practical suggestions on how to move forward and think about one's career? I've been a frontend (with a little full stack) for a few years now, and much of the modern landscape concerns me, specifically with how I should be positioning myself.

I hear vague suggestions like "get better at the business domain" and other things like that. I'm not discounting any of that, but what does this actually mean or look like in your day-to-day life? I'm working at a mid-sized company right now. I use Cursor and some other tools, but I can't help but wonder if I'm still falling behind or doing something wrong.

Does anybody have any thoughts or suggestions on this? The landscape and horizon just seems so foggy to me right now.

replies(13): >>46196851 #>>46196962 #>>46196968 #>>46196974 #>>46197019 #>>46197168 #>>46197251 #>>46197415 #>>46197469 #>>46198271 #>>46198452 #>>46202024 #>>46204332 #
1. martinald ◴[08 Dec 25 20:08 UTC] No.46196962[source]▶
Author here, thanks for your kind words!

I think it's about looking at what you're building and proactively suggesting/prototyping what else could be useful for the business. This does get tricky in large corps where things are often quite siloed, but can you think "one step ahead" of the product requirements and build that as well?

I think regardless if you build it, it's a good exercise to run on any project - what would you think to build next, and what does the business actually want. If you are getting closer on those requests in your head then I think it's a positive sign you are understanding the domain.

replies(2): >>46197022 #>>46200856 #
2. BigHatLogan ◴[08 Dec 25 20:12 UTC] No.46197022[source]▶
I think you're right about trying to stay one step ahead of product requirements. Maybe my issue here is that I'm looking for another "path" where one might not exist, at least not a concretely defined one. From childhood to now, things were set in front of me and I just sort of did them, but now it feels like we're entering a real fog of war.

It would be helpful, as you suggest, to start shifting away from "I code based on concrete specs" to "I discover solutions for the business."

Thanks for the reply (and for the original essay). It has given me a lot to chew on.

3. satisfice ◴[09 Dec 25 03:13 UTC] No.46200856[source]▶
ARE you the author? Or did you prompt AI to get this?