Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineers at our startup don't build features anymore

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Engineers at our startup don't build features anymore

#11

Post by muzani »

I like to point back at an ancient pattern in engineering: prototypes.

Prototypes are built to learn. They're not optimized nor efficient. They don't scale. They discover what needs to be built and are then thrown away. They should not be sold into production. Learning also includes getting user feedback, or finding out whether all the systems play together well.

Once the prototype is valid, pass it to an engineer to build it in properly and efficiently.

Another variation might be turning the engineers into ops. I did that early on at a startup. We built the whole delivery management system in 3 days - who ordered what, the state of it being delivered (packed/in delivery), informing buyers of product tracking number, asking them whether it was received in good condition, flagging things that have exceeded delivery time, etc. This was before AI and I built it so damn fast because it's a pain to handle this process on spreadsheet. The downside was that orders in those 3 days were delayed by 3 days.

But the big downside to engineers doing these is that you have to pay them engineer salaries. If it leads to a world where marketers can be given engineer salaries and engineers can be given marketing jobs, maybe we're in a better place?

Re: Engineers at our startup don't build features anymore

#12

Post by saluki »

emorning3 wrote: post #9
saluki wrote: post #7

This is not the new normal. Engineering should be doing the engineering. Product should be doing product. DevOps should be providing infra. If end users want to use a report generator or setup a notification rule that's one thing but duct taping features together never is sustainable.

My mental model of the 'new normal' is end users using AI to get their work done. So if I re-worded the OP's description and replaced 'internal tools' with 'internal AIs' then this would at least seem like a more reasonable process to me... > At our startup, engineers don't build features anymore. > They build APIs that internal AIs can connect to. > Most "features" like running an SQL query, sending a push notificat…

Definitely ...

If anything engineers are doing more with AI and aren't limited to just APIs.

They are building more of the UI/UX, Design, Front/Back + API instead of less and meeting/building product's vision.

Supported by Devops.

Every layer of the process will be enhanced by AI so everyone is doing more that our previous process.

I wouldn't limit any layer, enable everyone and every team to do more and be more productive.

Re: Engineers at our startup don't build features anymore

#13

Post by s4293918 »

romanhn wrote: post #2

I have never heard of this approach. It does sound interesting in theory, but I have a hard time seeing this work beyond the simplest of CRUD apps. My initial concerns would be: - Maintainability: the "duct-tape logic", as you put it, sounds like spaghetti code from hell. Making sense of a feature comprised of tons of chained third party calls will be a nightmare. - Expressiveness: complex functionality may require c…

N8n is pretty powerful in that you can pipe Kafka streams into there for webhook trigger functions, separate postgres DBs can be set up for non-eng and also all the production API endpoints can be called from there in a tracable way.

Re: Engineers at our startup don't build features anymore

#14

Post by s4293918 »

saluki wrote: post #7

This is not the new normal. Engineering should be doing the engineering. Product should be doing product. DevOps should be providing infra. If end users want to use a report generator or setup a notification rule that's one thing but duct taping features together never is sustainable.

Why is the siloing so important do you think? I think with all the use of LLMs now, entire functions or multiple functions can be done by 1 person. Those people can get a lot of task and skill variety in their work.

Re: Engineers at our startup don't build features anymore

#15

Post by s4293918 »

VivaTechnics wrote: post #10

Has anyone else tried this kind of setup? Yes. We don’t even have the budget to hire non-technical people for tech products. Everybody gotta code. We also avoid feature bloat. We focus only on core features. If someone has an idea and can build it, they’re welcome to try. But most ideas won’t make it to production.

What do you think about every single employee at the company being an engineer and picking up a domain or two (finance, accounting, digital marketing, support, sales)? The founder of Telegram talks about how he just has a company with 30 engineers and no other staff.

Re: Engineers at our startup don't build features anymore

#17

Post by s4293918 »

muzani wrote: post #11

I like to point back at an ancient pattern in engineering: prototypes. Prototypes are built to learn. They're not optimized nor efficient. They don't scale. They discover what needs to be built and are then thrown away. They should not be sold into production. Learning also includes getting user feedback, or finding out whether all the systems play together well. Once the prototype is valid, pass it to an engineer to…

What do you think about every single employee at the company being an engineer and picking up a domain or two (finance, accounting, digital marketing, support, sales)? The founder of Telegram talks about how he just has a company with 30 engineers and no other staff.

Re: Engineers at our startup don't build features anymore

#18

Post by muzani »

s4293918 wrote: post #17
muzani wrote: post #11

I like to point back at an ancient pattern in engineering: prototypes. Prototypes are built to learn. They're not optimized nor efficient. They don't scale. They discover what needs to be built and are then thrown away. They should not be sold into production. Learning also includes getting user feedback, or finding out whether all the systems play together well. Once the prototype is valid, pass it to an engineer to…

What do you think about every single employee at the company being an engineer and picking up a domain or two (finance, accounting, digital marketing, support, sales)? The founder of Telegram talks about how he just has a company with 30 engineers and no other staff.

I like it and it suits my skills. It's more a question of whether this is practical. Are they enough people who like this configuration? Because I'm sure bored of looking at the same piece of code day after day and trying to figure out what people want.

Re: Engineers at our startup don't build features anymore

#19

Post by saluki »

s4293918 wrote: post #14
saluki wrote: post #7

This is not the new normal. Engineering should be doing the engineering. Product should be doing product. DevOps should be providing infra. If end users want to use a report generator or setup a notification rule that's one thing but duct taping features together never is sustainable.

Why is the siloing so important do you think? I think with all the use of LLMs now, entire functions or multiple functions can be done by 1 person. Those people can get a lot of task and skill variety in their work.

Every team member has a job to do in the software process. Each speciality can leverage AI to perform faster and better moving the whole process forward. I think everyone can expand outward with what they are able to do enhanced by AI but they need to stay around their core expertise where they are bringing the most value. Things still need to be maintainable and secure.

Re: Engineers at our startup don't build features anymore

#20

Post by cylinderthought »

this approach is cool for speed and small teams but duct-taping features with low/no code tools quickly gets messy. you lose the deep control engineers provide and debugging complex flows turns into nightmare mode. also testing? good luck with automated tests when your logic is scattered across 5 different services and zapier chains. scaling this needs discipline or you’ll end up with a brittle spaghetti monster nobody wants to touch.

it’s a neat hack but definitely not the new normal for anything beyond MVPs or tiny startups.

Post reply on HN