Even worse, it normalizes being a vindictive egotist. People need to be grown up about feedback especially if they're in powerful positions. Not ok to be offended.
After having interviewed hundreds of engineers, I agree with the premise that elite TopCoder competition programmers are great not just at brainteasers. It takes a lot of discipline to improve skill to solve that fast, so they are smart and hardworking and can ace the design interviews too.
However, the fact is these people are inundated with job offers and very generous swag - like laptops. Everybody wants to hire them. It's hard to compete for one of these candidates let alone fill an engineering team. Centering hiring around that is an act few can follow.
Some of this advice is great, like getting out of the way, guiding people with how to think about trade-offs and doing daily coding. But it doesn't feel like 'Principal' level advice, at least in terms of Big Tech and the blog notes the author isn't sure what the distinction is with Staff.
The author complains that it's hard to be in the critical path at a senior level. This lacks self-awareness. It's always hard to be in the critical path. Shipping on time is one of the toughest deliverables of the software engineer role, and one that many people struggle with. Accurately estimating development costs including wall time vs. actual time someone has to work on a project is a very important skill. It's not acceptable for senior engineers to abrogate responsibility for this, especially if they claim to be mentoring other engineers.
Senior engineers own the business outcome and must weigh costs of all kinds, from security risks to technical debt. As scope increases, the feedback loops get longer and longer. A new engineer can tell if they did well with a comprehensive unit test. A junior engineer can tell if they did well with a performance or integration test. A senior engineer can tell if they did well with an A-B test in the market. A staff engineer can tell if they did well by seeing market share grow.
In Big Tech, senior staff and principal roles carry the idea of doing something to 'shock the world' - that is, successfully shipping innovation that people were afraid to, for example, because it seemed risky. Greasing the wheels of communication between teams and helping people avoid common mistakes is fine and a good thing. But there is limited business value in building consensus around the latest "architecture" or framework or language or whatever, however nice it feels to enjoy the social status as the person turned to for this kind of question. Step change innovation is the real value add and this article hardly touches on it.
> A senior engineer can tell if they did well with an A-B test in the market. A staff engineer can tell if they did well by seeing market share grow.
I don't get this, these are marketing and business skills. I don't understand why tech roles don't leverage the full power of engineering and instead engineers are steered towards tangential specializations. This isn't true across the board of course, but how can companies not see the value of letting some engineers become the technical experts without needing all these related skills? Knowing advanced CS and information theory can help, if anything to keep the other engineers up to date (and I think it would involve technical leadership, just not in terms of managing others), but it's not valued at all and without those other skills it seems engineers just stay as "contributors" (i call this bottom feeders).
Interesting feedback, thanks! What I describe in the article are the challenges of the role based in my experience. What you describe it's the business as usual work. Innovation, deliver and push key initiatives, etc. are the reason to be promoted to Principal in first place. They are important but they aren't what I find more challenging in the role.
Do the architects actually… build things? The description of the work there is more like a program manager. Which is an important organizational job which doesn’t have any power, but also isn’t the person doing the work, and so doesn’t have the understanding to design it.
Every SSD spec sheet has a Total Bytes Written (TBW) spec and Drive Writes Per Day (DWPD) and many warranties say that they don't cover wearout beyond those specs. It's akin to a tire rated for 50,000 miles; if it fails beyond that it's not defective.
Being considered the go-to person means you are first in line to make small tweaks (and config changes in code).
This increases the change count.
If there is a review process where another engineer has to approve work, this exacerbates the gap, as the go-to person can get their reviews done quickly. If they're trusted, the reviews might not be thorough.
This increases the rate at which changes go in.
These and other factors suggest that it's hard to split cause and effect here. Being seen as productive increases change count :)
This also seems to be labeling people as "top performers" based on how much code they get done.
And then measuring how many commits they do and wondering why those are correlated? Even besides the good reasons you point out ... this seems very obvious.
Also, my experience has shown that smaller commits are easier to work with so people with experience tend to make more smaller commits. This also seems to be fairly widely talked about.
With GitHub's API, commits are so easy to game. I'd never use commits as a measure of how good of a programmer someone is. I made a Python script in 15 minutes to commit to a repo every second, and the repo is sitting at about 750,000 commits.
Go is painful if you don't want to write high-quality heavily exercised production code. If you do, then you should be considering each error condition. Most code doesn't need to worry about error handling as it will run under close supervision on at most one machine over its lifetime. Go is a nuisance for that.
If you want to know that you have handled every error path, Go is awful because there is no language or compiler support for it at all. Completeness has to be ensured manually, by inspection.
Check out Rust's error handling approach sometime for an example of a language that truly values complete and correct error handling. It is a joy.
===
The reality is that Go doesn't have better error handling because the language designers value the simplicity of Go's implementation more than the simplicity of its interface - a trait that directly flows from its unix roots [1].
This is a fine tradeoff, and the right one for many problems. Go has been extremely successful in large part because of this philosophy. But you should not kid yourself that this is somehow the Right Way to handle errors, just because it's what Go does. Because even Go's designers are actively trying to fix it [2].
> Go is painful if you don't want to write high-quality heavily exercised production code.
That's the excuse that the golang authors give. The fact of the matter, golang is also extremely annoying when writing "high quality production code". golang errors are error-prone, and on more than one occasion we've had instances where errors are mistakingly ignored. This is much worse than exceptions where they have to be explicitly swallowed, otherwise they'd automatically bubble up.
I guess it's a question of whether you want drivers to be in the kernel source tree with supported interfaces, where interactions with other drivers can be mediated, or in userspace, where they can iterate without the kernel release process, which takes a long time to get to distros and end-users.
As this Intel MSR is not well documented, I would not argue strongly either way.
This write up covers a lot of ground from specific issues around language and protocol transport layer choice to general advice that organisational change without a strong senior sponsor is hard. If you feel that quality needs to be increased the first question you need to ask is whether that is a widely held view. People have different expectations of trade-offs and may even benefit from noisy failures - which can grant headcount and greater focus. It might really not make sense to improve something that will be retired soon.
In this video https://www.youtube.com/watch?v=DpO1Tfa4IZ4 keynote, Amin Vahdat explains how he led a transnational approach to reliability in a huge complex system. In response to a question about whether hiring should be changed to increase reliability he says no - just that it needs to be measured and emphasised as a priority.
Coming up with the idea of a portable personal computing device is easy. It's even possible to manufacture it (e.g. the Apple Newton). However it won't affect people's lives until it is quite polished. Similarly figuring out that people want to stream all their music is easy. The innovation in getting it to work, overcoming complex technological and social barriers is hard to explain to outsiders and less obvious. But it opens up these 'old things' to new people who couldn't access them before.
For another unicorn, clearly opening up new things to people: Oculus, though it wasn't the first virtual reality headset.
That said, cross platform compatibility is always going to be hard. I'm still amazed that Adobe let that platform die. It has taken so long and so much effort to recover equivalent functionality, and in some cases we are still lagging what Flash could do.
