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

There's no such thing as a small software team anymore

jacob.gold

Post reply on HN
Print view View original

141–150 of 183 posts

Re: There's no such thing as a small software team anymore

#141

Post by samrus »

whatever1 wrote: post #116
tokioyoyo wrote: post #104

Earlier quoted context omitted.

This argument comes up during every big layoff season. A good chunk of people pronounced Twitter dead when it got bought out. But software nowadays is pretty stable, despite its perceived jankiness.

Twitter is dead. After the layoffs it required multiple bailouts and pivots to its business. Not even sure what X is about today. Layoffs pushed over the cliff the company. Both due to engineering (content is now trash), and product (lost most of the ad revenue)

By what metric is twitter dead? I dont like twotter but i still see content from it linked everywhere

Re: There's no such thing as a small software team anymore

#142

Post by kikimora »

samrus wrote: post #141
whatever1 wrote: post #116

Earlier quoted context omitted.

Twitter is dead. After the layoffs it required multiple bailouts and pivots to its business. Not even sure what X is about today. Layoffs pushed over the cliff the company. Both due to engineering (content is now trash), and product (lost most of the ad revenue)

By what metric is twitter dead? I dont like twotter but i still see content from it linked everywhere

Twitter content is trash

Re: There's no such thing as a small software team anymore

#143

Post by zelphirkalt »

pianopatrick wrote: post #15
kstenerud wrote: post #13

Hundreds of bots modifying thousands of microservices may sound good on the surface, but all those thousands of microservices make up an architecture and a product. Agents aren't very good at carrying the entire model in their context, so when they reason about a small piece of code, they often come up with something that hurts other parts of the code (especially as the KLOCs pile up). The complexity hasn't been repl…

Seems to me the real question is "what scheme can we use to organize our code base such that an agent working on one part really can make changes and not break the other parts on accident". My current theory I might test out is to treat generative AI as generative AI. This means instead of editing things like a microservice in place you version freeze them to bug fixes only and create new versions for new features. T…

How does this freezing version and new version and so on differ from having the code in a version controlled repo?

Re: There's no such thing as a small software team anymore

#144

Post by skydhash »

black_knight wrote: post #132
eloisius wrote: post #110

Earlier quoted context omitted.

If the job is now being a promoter, how can you not see that it’s a low skill, low pay job anyway? There are a billion capable promoters in LCOL countries that can prompt as good as someone in the Bay. Might not be worth stressing so hard to be a promptmaxxer. Could just become a bus driver or some other skilled profession if you want to keep earning a living.

I don’t think this is actually true, though. In fact, I believe the opposite. My experience with LLM assisted coding is that I need a technical hand on the steering wheel to get something workable out it. Otherwise, what comes out is a brittle, non-functional mess that only in the most tenuous way resembles what I had in mind. The job was never to type the code out. The job was always to take a problem in the real wo…

> The job was never to type the code out. The job was always to take a problem in the real world, and shape it into a model which can be implemented in software.

"Typing" the code was never the whole job, and it can be the easiest part. But "the code" is very much the artifact that is used to generate values. It being correct and easy to maintain lower the associated costs and MAY raise its value. It being brittle and hard to maintain raise the associated costs and WILL lower its value.

So being good at system design is how you target the first case.

Re: There's no such thing as a small software team anymore

#145

Post by skydhash »

hombre_fatal wrote: post #136
mirsadm wrote: post #131

Earlier quoted context omitted.

And they're really good at adding more code to reduce complexity. In particular Claude is absolutely bonkers at the moment. I am having trouble taking this seriously especially because you mentioned Claude. Have you looked at anything it's done?

I use Claude model=fable effort=high to write most of my initial plans, especially the hard things like re-architecture. I recommend putting time into figuring out the "soft infrastructure" of your projects, usually things you've never been arsed to do in your life (like me until this year). Start with a docs/*.md folder that you link to from AGENTS.md where you can document things that would be important for you, an…

> Or maybe there's some load bearing "make impossible states unrepresentable" platitude in my AGENTS.md I'm overlooking that's responsible for why I have such a great experience with AI and nobody else on HN apparently is.

We can notice that you're describing the work, but not any result that have derived it from it. I can explain to someone how to learn vim and tmux, but the best argument is to explain the benefits of doing so. I can't just say, take two weeks of your time and wait for the results.

I've been on HN seeing all kinds of comments like yours that promote spending more for tools (time and money) but never expand on WHY I should even do that or what's the proven benefits of doing so.

Re: There's no such thing as a small software team anymore

#146

Post by xboxnolifes »

lucianbr wrote: post #103
layoric wrote: post #57

> If you have a large monolithic service where every change has to be coordinated carefully.. Microservices are WAY harder to coordinate for deployments. You end up with feature service dependencies, and you are back to the same coordination, but now harder to discover down stream dependencies..

I think microservices are supposed to be easier to deploy independently, that's the whole point. And if they are not, it means you're just doing it wrong. But in truth, all the projects with microservices I have seen in real life had deployment coordination problems, and looked to me like distributed monoliths. So maybe it's a 'no true scotsman' thing. Maybe they are always, or at least most of the time, harder. Make…

People do microservices (read: an API spread across multiple processes), but then make all of the mistakes that logically couple the service deployments together. They use shared databases instead of one per service, make breaking changes to API schema instead of non-breaking or versioning, use a shared library of schema definitions instead of having each service define their own data objects for API calls, and have startup logic that depends on another service being up.

Re: There's no such thing as a small software team anymore

#147

Post by kstenerud »

ulrikrasmussen wrote: post #74
win311fwg wrote: post #49

Earlier quoted context omitted.

> Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things. Someone has to deal with them, but if you are dealing with all of them then you don't really have microservices, just a multi-process monolith.

Then it sounds like you can only have a true microservice architecture if your application doesn't really need transactional guarantees, consistency or fault tolerance.

Microservices are just another "cache" level in the end. They can make sense in the right situations, but you need to make your architecture deliberate in order to reap its advantages. Idempotent services are an easy win, and also places where you have data locality (similar to cache locality, just a few levels lower).

At the end of the day, it comes down to:

- how far does the data have to travel, and at what cost?

- how much latency can your process tolerate?

- how much unreliability can your process tolerate?

- where and how do you isolate resources that are concurrency sensitive?

- what's the infrastructure going to cost?

Re: There's no such thing as a small software team anymore

#148

Post by wseqyrku »

cyh555 wrote: post #35
wseqyrku wrote: post #6

Earlier quoted context omitted.

> but why would I want to run more agents? Notice how difficult it is to turn off photo bursts in iPhone? Because that free cloud space needs to be filled fast. So ask your question again and you will find the answer very rapidly. They even gave it a cool name, "tokenmaxxing" what even the fuck.

it's against the social rules to call them out

Imo it should be against the social rules to fuck people over.

Re: There's no such thing as a small software team anymore

#149

Post by gulugawa »

chrismorgan wrote: post #93
shimman wrote: post #43

Earlier quoted context omitted.

That's pretty impressive. I always like bespoke web utilities tailored for specific dev purposes. What approach are you taking? I'm about to start a mithril.js project, was always under the impression it was the most efficient approach. Are you doing something similar or different or are you referring to WASM?

Completely seriously, and I don’t think this is particularly controversial: outperforming React is not impressive. React was never particularly good at performance—VDOM is fundamentally overhead, and there are a variety of faster and lighter techniques employed by various competitors, and even among VDOM libraries it’s not as fast as it could be. React sold itself as fast initially, but what it was faster than (rebui…

I actually agree with you. I was making the point that not using LLM assistance to code produces decent results.

Also, I'm planning to release my changes as a framework that can be used for a variety of interactive websites.

Re: There's no such thing as a small software team anymore

#150

Post by necatiozmen »

hombre_fatal wrote: post #136
mirsadm wrote: post #131

Earlier quoted context omitted.

And they're really good at adding more code to reduce complexity. In particular Claude is absolutely bonkers at the moment. I am having trouble taking this seriously especially because you mentioned Claude. Have you looked at anything it's done?

I use Claude model=fable effort=high to write most of my initial plans, especially the hard things like re-architecture. I recommend putting time into figuring out the "soft infrastructure" of your projects, usually things you've never been arsed to do in your life (like me until this year). Start with a docs/*.md folder that you link to from AGENTS.md where you can document things that would be important for you, an…

This is the part people often miss: durable context matters more than the prompt. We are maintaining https://github.com/VoltAgent/awesome-design-md, an open-source collection of `DESIGN.md` files for coding agents.

It applies the same idea specifically to visual design, making things like typography, spacing, colors, layouts, and component patterns explicit and reusable. You can use the existing examples as a starting point or contribute your own.

Post reply on HN