Live data from Hacker News

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

jacob.gold

81–90 of 183 posts

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

#81

Earlier quoted context omitted.

Yeah, I think engineering orgs mostly jumped the shark. Metrics like pr count and commits have always been terrible gauges for success compared to business performance. But they're easy to measure, and even easier to game now with AI. So we're seeing an outrageous gain on these metrics, and they've become almost completely divorced from business results. No one cares how fast you ship prs. They care that you offer a…

My organization has noticed that some people's output has gone way up since they started using AI, while some people's has not. I imagine output is measured by LOC and MRs, since we are bad at metrics. There's now an effort to figure out why the laggards aren't using their AI "well" enough. I've seen some of the increased output that was sprayed at my team without consent, it was work that superficially looked good b…

> The rework is being done quietly

This is a bad idea - you’re actively contributing to the problem by hiding the negative effects.

Don’t even think about starting that work until you’ve created bug tickets for as much of it as you can, and bright then to management’s attention. Management then needs to figure out priorities for doing that work and whether a change in approach is needed.

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

#82
post #66

Earlier quoted context omitted.

currently unfettered ai spending is reducing qol for more individuals than it is increasing. why should the avg joe be happy about reduced qol?

who is it reducing qol for? I get that SWE get far higher benefit than maybe everyone else, but who is it actively reducing QoL for?

As a software engineer I don't think my quality of life has been improved - I now get gigantic patches to review (and I know the people writing them haven't reviewed or tested their own patches so even worse) and my tester is now drowning in big garbage patches that are taking longer to test, so my work isn't progressing either.

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

#83
post #64

Wait two years until we have sufficient churn of senior talent in the teams. Then all of the services will have outages daily. Only the seniors who know their systems are keeping the lights on today by keeping bs commits out. Once they burnout and quit, nobody will have a freaking clue what the LLMs have done and why services are down.

I would take the other side of that bet. In five years, there won’t be more outages than today.

Deal. See you here 2031. If the site is still up.

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

#84

I saw the `require('gulp')` and the memories def came back. That's def how we used to do code ~10 years ago. I still don't like the multi-threaded PER PROJECT too much, I prefer having 2 projects and switching context window, I find the current tools (at least the ones I know) are a bit underwhelming for multi-threading. But I'm also trying to upgrade my knowledge. A good way I've found, since I do a lot of OSS and h…

> find the current tools (at least the ones I know) are a bit underwhelming for multi-threading

Have you tried t3 code? It creates a separate worktree per agent, which makes running multiple agents at once much easier.

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

#85

Earlier quoted context omitted.

I don't say this to be mean, but you need to plan for a world where it's always summer. Maybe the valuations will collapse with OSS models but programming is never going back to normal.

> plan for a world where it's always summer The difficulty in adopting this belief lies in the fact we have multiple points of reference in the past, of visionaries claiming that "this time is different" and we reached the end of history... and well, the rest is history.

Yes that’s very sanguine. On the other hand there have been many times when tech made a permanent difference.

Smartphones, internet, PCs, computers, semiconductors, relativity, antibiotics, telegraph, printing, electricity, steam power, …

It has stayed comms and compute summer since the end of the twentieth century. It has stayed infection summer since the beginning of the twentieth century. You get the idea.

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

#86
post #66

Earlier quoted context omitted.

currently unfettered ai spending is reducing qol for more individuals than it is increasing. why should the avg joe be happy about reduced qol?

who is it reducing qol for? I get that SWE get far higher benefit than maybe everyone else, but who is it actively reducing QoL for?

additional to the great examples already given, anyone in residential proximity to a compute centre is recieving noise + environment pollution. resultant destruction of sleep and air/water quality is massively detrimental to qol. the joes who net benefit from ai detriments seem to live far away from the consequences. I shall ask another way, how do the average joe's ai benefits outweigh his ai detriments?

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

#87
post #44

I'm really skeptical you can ship ~10 PRs a day per person unless these PRs are tiny pieces of one feature or all of them are tiny bugs that are each a 3 line fix that you could review instantly. Otherwise how can you confirm that the AI even did the right fix or feature correctly? That you even wanted that feature done that way?

I really don't think they can. I feel like if I rush a PR using AI, I can only just kinda hope the AI is good enough that my trust isn't misplaced. It becomes slightly less likely to be bad if you add a thorough AI review on top but it's just rolling the dice.

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

#88

There's another way to get this kind of parallelism without the mess of microservices. Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other.

> Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other

Isn’t the question how to keep likely dependent modules separated from each other in a monolith? You say “single purpose”, but how does that admonition work in the reality of a complex problem domain?

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

#89

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.

Then you must have heard the wrong thing. Oh well. You can't communicate with everyone.

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

#90
Agentic coding puts a lot of pressure on team communication. Individuals produce more output. So there now is a lot more to discuss and synchronize on. This favors smaller teams that typically are responsible for more things. That doesn't necessarily mean fewer people. But I do think it favors having more smaller companies over fewer larger ones that are each able to specialize more. It also means that companies that currently outsource all their development or buy SAAS products now should consider in housing some things again. A lot of people worry about work disappearing. I think the opposite is going to happen: more work popping up in a lot of new places. Because doing that work is now feasible and doable.

Staying on top of work done across many teams is going to be a huge challenge for larger companies and it's going to cause them to organize and hire very differently. Getting this wrong means teams diverge much quicker than they used to and everything gets misaligned much quicker. Some team might launch a product before some other team that was considering to do a similar thing is even aware that is happening. As most engineers might appreciate, the easiest way to tackle complexity is to just work on cohesiveness and coupling. Small teams with few dependencies working on a coherent thing will be much more effective than large orgs with a lot of inter team coupling and no coherent plan.

I'm in my fifties so, I've been around for a while. I currently work in a very small company (3 people) so I'm used to doing things by myself. I also used to work in traditional teams inside large multinationals. Very different game. You spend non trivial amounts of time communicating with people in big organizations. And you basically only get responsibility for a tiny amount of functionality. I had to learn a lot after I left the safety of a big organization. When everything is your problem, you need to skill up in a hurry to deal with all the challenges effectively.

In my current role, I do basically everything vaguely technical. And non technical as well. And it is more than ever since AI coding entered the mix last year. I stopped referring to myself as a backend person. Because I also do UI, devops, websites, IT infrastructure, etc. And a bit of sales, marketing, etc. I'd add management but we're such a small team that I suffer a little from impostor syndrome on that front. But I can do the job if I need to.

I had a whole hiring plan that I developed three years ago that we never executed on. It had all the traditional dev team roles spelled out. That plan is obsolete. These roles will probably never be filled. I need different people though. I need more people like me that can do everything I do when I'm not around and people with complementary skills that are strong where I'm weak. But I have much less need for specialists. I mainly need generalists with attention to detail that can deliver complete working products and systems. I might want a product focused person but not a dedicated product manager. If you can specify it in an issue tracker, you can learn to prompt an AI as well. But I still need a good product plan and roadmap. In the same way, I expect designers to shape UI work directly and not via a separate UI team. I expect them to own the front end experience and drive it. I still need people that are strong in these roles. But not exclusively. Good small teams have less people than all the traditional roles you find in larger traditional teams. That calls for people with overlapping skills that can put on different hats as needed that complement each other.

Post reply on HN