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

If we had the best product engineering organization, what would it look like?

jamesshore.com

Post reply on HN
Print view View original

51–60 of 126 posts

Re: If we had the best product engineering organization, what would it look like?

#51

Post by ggregoryarms »

skeeter2020 wrote: post #40
zeroonetwothree wrote: post #4

There’s a weird disconnect because on the one hand I agree you can’t measure productivity and on the other hand we all know that some engineers are vastly more productive than others. So what gives?

I have an incredibly productive staff developer. Not only does he work a lot , he also produces, and it's very high quality. He also does a relatively poor job of upskilling his teammates, and is a little rough when mentoring. This is not intentional (i.e. he's not a jerk). Overall I don't know if, in the context of a staff developer, he's vastly more productive than say, another dev I have who produces less but leve…

Maybe that other dev has a unique ability you should reward. Sound awesome. Focus on that.

Re: If we had the best product engineering organization, what would it look like?

#53

Post by mickael-kerjean »

grogenaut wrote: post #50
emmelaich wrote: post #43

Earlier quoted context omitted.

So they do joins in code rather than SQL? Wouldn't that risk hiding scaling problems?

It can but it's usually more obvious what's happening with code and how to fix it. Amazon wants you to think about the scaling issues while building as they don't want to lose the area under the customer curve on the far right. The theory is that with rdbms you have a magical box that scales vertically until it doesn't. And when it doesn't all you can do is scale back the customers until you fix it with sharding or a…

I recently finished a contract at a company who has gone full on dynamo with the idea that if we have slow queries and dynamo is good for Amazon, then it's good for us too. I've ran some explain on the queries causing issues and of course those queries didn't leverage indexes like they thought ....

Re: If we had the best product engineering organization, what would it look like?

#54

Post by blululu »

gwern wrote: post #31

OP is an example of how AI-generated images are usually clutter. Not only do the images not add anything meaningful to the text, and arbitrary parts of the images could be deleted or randomized without affecting the reader's understanding, most of them could be randomly shuffled without anyone noticing. (Which makes them worse then clipart/stockart: if an article swapped the 'hacker hoodie' stockart with the 'neural…

Came here to say exactly this. The ”author” didn’t even bother to use a decent quality image generator. The first image I saw maxed out my AI slop filter and I stopped reading. Made me wonder how much of the article was written by ChatGPT.

Re: If we had the best product engineering organization, what would it look like?

#55

Post by noirbot »

holografix wrote: post #33
Sevii wrote: post #17

Earlier quoted context omitted.

I like how he says he doesn't need FAANG level people. Then his next paragraph describes working at FAANG. "We’re an inverted organization. That means that tactical decisions are made by the people who are doing the work, not managers. (In theory, anyway, we’re not perfect.) So we’re looking for people who have peer leadership skills, who are great at teamwork, who will take ownership and make decisions on their own.…

Exactly right. People who have “leadership” skills are the ones that pay attention to their own leadership and are manage up more than anything else. They usually repackage people’s work around them into their own, take ownership and defend loudly their territory (project ownership) and methodically build relationships with leadership. Having “leadership skills” and being good a team work are often orthogonal to each…

I mean, that's the sour way to put it. As someone kinda stuck in that sort of position now, I own a project and have been able to do very little of the work because I'm spending 90% of my time making sure leadership actually makes decisions so I can get the decisions my team needs in order to proceed. I'm spending hours in meetings with other teams to get them to prioritize our dependencies and data access needs.

If you're not lucky enough to have management that's exactly technically aligned to your project someone has to be managing up and paying attention to leadership or else expectations will be totally off from reality.

Re: If we had the best product engineering organization, what would it look like?

#56

Post by noirbot »

skeeter2020 wrote: post #41
fshafique wrote: post #35

Earlier quoted context omitted.

Gut feeling uses all your internal predispositions and biases.

you don't need to rely on gut feeling and risk bias. You can stop looking for the "productivity metric" and instead bet on measure, then track the change over time. It's the only thing that's ever worked for me.

Sure, but which measure you pick is itself a gut feeling and biased. It's the easy way to miss people doing whatever sort of work that you aren't measuring that may be what's letting everyone else excel at what you are measuring.

Re: If we had the best product engineering organization, what would it look like?

#57

Post by infomaniac »

Sevii wrote: post #21

I appreciate that they have a programming philosophy that they want people at the company to adopt. A common problem I see at companies that don't have onboarding is that people join the team with assumptions from previous jobs but you never level set them with the company. So 12 months down the line the new guy wants to change the process and you have to repeat the same discussions about what agile means for the nth…

> Amazon does not use relational databases

This is false, at least in my very thin exposure to the company: I interviewed for a team last year which was maintaining EC2 SSH keys using MySQL.

Re: If we had the best product engineering organization, what would it look like?

#58

Post by supriyo-biswas »

noirbot wrote: post #55
holografix wrote: post #33

Earlier quoted context omitted.

Exactly right. People who have “leadership” skills are the ones that pay attention to their own leadership and are manage up more than anything else. They usually repackage people’s work around them into their own, take ownership and defend loudly their territory (project ownership) and methodically build relationships with leadership. Having “leadership skills” and being good a team work are often orthogonal to each…

I mean, that's the sour way to put it. As someone kinda stuck in that sort of position now, I own a project and have been able to do very little of the work because I'm spending 90% of my time making sure leadership actually makes decisions so I can get the decisions my team needs in order to proceed. I'm spending hours in meetings with other teams to get them to prioritize our dependencies and data access needs. If…

This is not a sour way to put it; extreme levels of information hoarding, cookie licking[1] and building and defending fiefdoms were the norm from what I saw at my time at a FAANG.

[1] https://devblogs.microsoft.com/oldnewthing/20091201-00/?p=15...

Re: If we had the best product engineering organization, what would it look like?

#59

Post by xwolfi »

saghm wrote: post #46
Sevii wrote: post #21

I appreciate that they have a programming philosophy that they want people at the company to adopt. A common problem I see at companies that don't have onboarding is that people join the team with assumptions from previous jobs but you never level set them with the company. So 12 months down the line the new guy wants to change the process and you have to repeat the same discussions about what agile means for the nth…

> Amazon does a good job of training new hire on the 'Amazon way'. Amazon does 6 pagers, they do design docs. Amazon does SOA. Amazon does not use relational databases. Everything has an API. Because of the 'Amazon way' and the training they do new team members understand at least some of the context and expectations. As a counterpoint, a huge part of Amazon's culture (or at least, AWS's) in my experience was the emp…

Which is the only way to learn tbh, you can receive as much positive reinforcement imaginable, nothing prepares you for a large scale incident like living through one, building the connections you need to solve it, getting the shame of your life, and losing sleep over your failure.

Re: If we had the best product engineering organization, what would it look like?

#60

Post by scarface_74 »

emmelaich wrote: post #43
vamega wrote: post #32

Earlier quoted context omitted.

Relational databases are not the preferred storage mechanism at Amazon. If a team wants to use an OLTP relational database it’s possible that it will be a decision they will need to defend at any kind of design review. Of course there are relational databases running OLTP workloads, but it’s far away from the norm. There was a program a while ago to shift many RDBMS systems onto something else.

So they do joins in code rather than SQL? Wouldn't that risk hiding scaling problems?

Look up design patterns in DynamoDB. If you know your access patterns and you often do with well defined microservices. You don’t need to do joins.
Post reply on HN