Ask HN: How do big software companies maintain high engineering standards | Hacker News Reader

Ask HN: How do big software companies maintain high engineering standards

10 pointspj_mask5 comments

I can assume that when a company grows very fast (FAANG Fast) the number of ideas, good and bad, grows. What are the known ways for huge software companies ( the ones that opens dozens of teams per year ) to maintain high engineering standards? How do they successfully teach their techniques for dealing with scale, maintain good architecture, etc. I am aware that in reality there are a lot of badly written projects even in Google and that there is no silver bullet. But I do believe there are a few techniques I can learn from (Since many of these companies have super well engineered projects and they constantly recruit juniors).

Let me name a few: Design review committees (problems: covers a small amount of the code, requires constantly re-checking on design changes), multiple code reviews before merges, Managing PEs and assigning them to groups, ICs, architect-only teams (problems: many)

This is a very easy problem to solve. Companies can do things when the truly believe those things are important. However, that means when you stack rank things that matter, your thing floats towards the top AND your leadership all believes in and values those things. That's the long way around saying - it has to be important, culturally, and the culture has to be strong.

Otherwise, it's just screaming into the wind.

I think any great company regardless of size benefits greatly from an open culture which encourages trust and learning and balances throughout and quality with (agile) processes and retrospectives, planning, collaboration/pair programming, code reviews and ambition to do a great job and create value through good products and services.

In many cases, having soft deadlines works. You can double check and do code reviews for ever, it is never perfect and we can always think of a better way. Regardless of the experience of the engineer less time to complete a task means prioritizing making code just work, over making code optimal.

I think this is very important, not having a deadline can mean nothing ships and having a hard deadline I have seen quality and best practices slip due to pressure to cut corners.

Other general things that I’ve seen help. Code reviews should not be a rubber stamp, the reviewer should understand everything, there should be a degree of overlap of feature development between devs, end-to-end tests to check for regression can be highly useful once a project is if reasonable complexity.

Leaders create a replicable culture, but the key is in the leadership culture and how senior engineers number one job is leading.

Reply on news.ycombinator.com