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

The magic of small engineering teams

newsletter.posthog.com

Post reply on HN
Print view View original

141–150 of 161 posts

Re: The magic of small engineering teams

#141

Post by goosejuice »

seadan83 wrote: post #135
OJFord wrote: post #127

Earlier quoted context omitted.

Well alright everyone grabs a couple of slices, I'd say typical is 8 slices per pizza right, so that works out to 8 people, which yes is what it means doesn't it? (Not literally 8 but in that 6-10ish region?) My point was if you interpret it to mean a full meal for hungry people a two pizza team is like 2 maybe 4 people, because 'a pizza' is an order, unless these are enormous fast food 'party size' type pizzas.

2 slices is considered to be a meal. Calorie wise, it likely is. Typical large pizza has 8 slices. The vagueness is intentional. From the Amazon concept, it is intended to replace a meal and not be a random snack. (Former amazon employee here)

Yeah there's still way to many variables.

Regional/cultural differences, appetite and body size, pizza styles, etc.

For small teams that makes for a meaningful difference between the min and max. For large teams not so much.

My wife and I have no issues finishing a 16in tavern style pizza. So that's a 4 person team. We're not even large people or big eaters. We just like pizza.

Re: The magic of small engineering teams

#142

Post by _xivi »

seadan83 wrote: post #132
_xivi wrote: post #118

Earlier quoted context omitted.

What does revenue got to do with producing/shipping products? maybe you quoted the wrong sentence? You can have millions of dollars in revenue without producing anything, on the other hand, you can also provide a lot of services and products for free

> What does revenue got to do with producing/shipping products? I'm quite sure a number of product people would answer "everything" Feature factories are a thing for a reason.

> Feature factories are a thing for a reason.

If anything that goes against the parent comment, how Apple has more revenue per engineer while not being a feature factory by any stretch

In any case, taking both of the comments combined kinda prove my point, that higher revenue can be attributed to many things completely outside how many products/features was shipped:

- Pricing strategy

- You can have a monopoly with a single shitty product

- You can be middle man/broker with no product to begin with

- You can be running a Ponzi scheme or committing fraud

So it doesn't make sense to use revenue (or revenue per team member) as a way to compare teams between different companies and furthermore possibly across completely separate markets and industry

Re: The magic of small engineering teams

#143

Post by OJFord »

seadan83 wrote: post #135
OJFord wrote: post #127

Earlier quoted context omitted.

Well alright everyone grabs a couple of slices, I'd say typical is 8 slices per pizza right, so that works out to 8 people, which yes is what it means doesn't it? (Not literally 8 but in that 6-10ish region?) My point was if you interpret it to mean a full meal for hungry people a two pizza team is like 2 maybe 4 people, because 'a pizza' is an order, unless these are enormous fast food 'party size' type pizzas.

2 slices is considered to be a meal. Calorie wise, it likely is. Typical large pizza has 8 slices. The vagueness is intentional. From the Amazon concept, it is intended to replace a meal and not be a random snack. (Former amazon employee here)

Sure I'm not really getting into whether or not it's supposed to serve as your lunch and whether it's a healthy limit even if you'd like more^, etc. - I just mean it's meant with the assumption that people are having that much, not that it's your orders at a team outing to an Italian restaurant or something. (In which we agree.)

^personally I work from home and rarely eat lunch, so I have no skin in this!

Re: The magic of small engineering teams

#144

Post by bitwize »

noisy_boy wrote: post #94
zeroonetwothree wrote: post #59

Earlier quoted context omitted.

I think “this isn’t my job” is generally a bad mentality (sure there are some times it’s ok, but those are like 1% of the actual times it’s used)

Most managers love to repeat "saying it's not my job is terrible attitude" while assigning unreasonable targets and stuffing items in the Sprint to the extent that even sneezing hard will make you overrun your deadline. So I am expected to deal with non prioritized work with a smile so that I have to steal from time set aside for my family in order to make the sprint target? How is that not bad mentality?

Yes, you are expected to deliver the message to García without question or complaint. Managers love initiative and self-reliance, but only in service to faithfully obeying their commands.

Re: The magic of small engineering teams

#145

Post by jappgar »

gofreddygo wrote: post #126
loupol wrote: post #48

Earlier quoted context omitted.

Reminds me of that bits about money blogpost title : "The optimal amount of fraud is non-zero"

Yes and the optimal amount of test coverage is never 100%

And the optimal uptime of b2b saas is not 100% or even 99.999% and yet...

Re: The magic of small engineering teams

#146

Post by jappgar »

loupol wrote: post #48
vbezhenar wrote: post #31

Earlier quoted context omitted.

If barriers harm more than abuse then abuse should be accepted.

Reminds me of that bits about money blogpost title : "The optimal amount of fraud is non-zero"

This is true about a lot of things.

The optimal number of (minor) crashes when training for a mountain bike race is non-zero. If you never crash, you cannot be sure you were going fast enough around that turn.

Re: The magic of small engineering teams

#147

Post by teaearlgraycold »

klooney wrote: post #106
teaearlgraycold wrote: post #26

Earlier quoted context omitted.

Same. I quit Google to go work at a 4 person company. I love that we’re just able to get stuff done. Hard to get GPUs? Walk down to Central Computers in SOMA and buy L40S cards and build a workstation for everyone to share. I’m not very financially motivated. I’m already making more than 90+% of the US. I just can not fathom the level of greed I saw hiding behind people’s eyes at Google as they try to build empires.…

> I just can not fathom the level of greed I saw hiding behind people’s eyes at Google as they try to build empires. I feel like the insane ponzi scheme of our housing market does this to everyone eventually

I'd rather die than become that. And there were plenty of Googlers there just chilling making good money. It's the mid level managers that were making around 500k eyeing up the 1MM comp packages that were the problem.

Re: The magic of small engineering teams

#148

Post by bobmcnamara »

djstein wrote: post #119
bobmcnamara wrote: post #103

Earlier quoted context omitted.

I work in embedded. When I told my boss I was leaving he asked what the other company was offering me - compiler licenses. Without enough each firmware build took 40-60 minutes. With enough, 10 minutes.

hey! would love to hear your experience about this. we’re building a system that should help alleviate this pain when developing embedded systems. emails / cal link are within my person site on bio!

We were using a CPU core vendor's compiler with flexlm licensing(well, Edison Design Group frontend and proprietary backend). We kept using it for ages because it regularly beat GCC due to some issues in GCC with register allocation and instruction reordering that only microchip seems to have ever fixed.

A traditional makefile like setup would only build one compilation unit per compiler invocation.

Each compiler invocation requires a license checkout over TCP. This was badly impacted by Nagling and delayed ACK. The license server was not managed by engineering rather the IT department so we were unable to get them to enable TCP_NODELAY.

Multiprocess scaling was challenging - you could give the compiler multiple compilation units, but sometimes doing so would effect the order of things in the object file, now you lose reproducible builds. These seemed to always be minor things that didn't significantly effect the executable, but rarely you'd crash the compiler and all its jobs would need restarted on the next rebuild.

For those of us batching our compiler invocations for local development builds, the last straw came when an ops team unfamiliar with the tools was put in charge of license management. They started kicking out license checkouts beyond a few seconds in the name of fairness. Build times increased further, but license checkouts per second went up so they thought they were helping.

Eventually I realized it wasn't the 1970s anymore and since I no longer smoke I was bored out of my skull just waiting for timesharing computer to compute again.

Several teams did move to GCC when it got bad enough - hand tuning loops and such when needed.

Probably shouldn't've had so much code in headers - APIs had a lot of dependencies and when I needed to change CompanyName.h, I was in for a few 90%+ rebuilds.

It was a combination of: not my problem, nobody's problem, I got mine, codebase is already like that, death by a thousand cuts, we've never better so how can you say this is bad, network latency.

Re: The magic of small engineering teams

#149

Post by bdcravens »

seadan83 wrote: post #131
bdcravens wrote: post #125

Earlier quoted context omitted.

There are some roles like that in tech. For example, "charitable" positions like full-time OSS devs. Another one that is questionable are tech evangelists or dev rel. Sometimes those positions can be connected to revenue, but usually it's "mindshare" accounting.

OSS dev might be a bad example. OSS is often an internal product that is opened up to gain free OSS labor. Most often, the position would exist within the company if it were OSS or not. In other words, it is something the company is working on regardless of OSS or private codebase

Not all paid OSS development is the company's product/project. Many of the largest open source projects are dependent on corporate "charity".

Re: The magic of small engineering teams

#150

Post by ryandrake »

bobmcnamara wrote: post #148
djstein wrote: post #119

Earlier quoted context omitted.

hey! would love to hear your experience about this. we’re building a system that should help alleviate this pain when developing embedded systems. emails / cal link are within my person site on bio!

We were using a CPU core vendor's compiler with flexlm licensing(well, Edison Design Group frontend and proprietary backend). We kept using it for ages because it regularly beat GCC due to some issues in GCC with register allocation and instruction reordering that only microchip seems to have ever fixed. A traditional makefile like setup would only build one compilation unit per compiler invocation. Each compiler inv…

It’s crazy that in 2024 we are still struggling with the kinds of things highlighted in your comment. Almost all are self-imposed pain, too.
Post reply on HN