Hacker News Reader

Comment by __turbobrew__ | Hacker News Reader

> That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits

Yea, in the current place I work at we do not measure coding performance metrics, but if you look at the top commiters to the repo — by number of commits — you will see all of the people who bring the most value to the company. Even at staff eng the best engineers are still the ones who crank out code, albeit maybe as not as much as a senior engineer. Staff engineers who only commit 1 a month are usually the ones who don’t bring value to the company, especially given their high pay.

View on HN

At my last gig I spent the last year and a half as staff engineer and made almost no commits because I was constantly writing proposals, defending them to execs, doing architecture reviews, doing design consultations, and planning long term responses to large incidents. I know for a fact that I brought a ton of value to the company but it was very uncoupled to commits. I didn’t really like it because I need to code, so I’ve moved on to a role where I commit like a maniac again. :)

Just check all of your proposals and design documents into source control, and you’ll still have plenty of commits!

Yea it is dependent on your company.

When I think of highly functioning staff engineers Im thinking of people like Jeff Dean and Mitchell Hashimoto. Similarly at companies I have been at, even the highest level principal super staff++ engineers still code. They do the high level strategy and design, but they are still writing PRs at least every week or two. If you are spending 100% of your time on politics and architecture as a staff eng I think that shows a somewhat dysfunctional organization.

Writing proposals, doing architecture reviews and doing design consultations sounds to me largely like busywork and bureaucracy rather than real and productive work.

Maybe in a business where the cost of iteration is very high, it makes sense to do this. But in a good business you should not be doing architecture reviews and writing proposals, you should be doing refactoring and creating prototypes, respectively.

Funny, I've evolved the opposite attitude over time.

Solving business problems using bespoke software solutions surely is the absolute most expensive option on the table, and should be aggressively avoided unless no other options are available, AND the problem is in a domain which is a core competency and market differentiator for your business.

The process of figuring out what your company needs, and how best to solve that problem long term, is dramatically more valuable to a business than software/technology implementation.

Software doesn’t live in a bubble.

Architecture reviews ensure that there is some strategy on how things are being solved at an organisational level.

Reply on news.ycombinator.com