vii (u/vii) - Readit News

vii commented on How to disagree with someone more powerful than you (2016) hbr.org/2016/03/how-to-di... · Posted by u/tomrod

thenerdhead · 3 years ago

These articles make it sound like people waste many hours creating cases for disagreeing with someone with more role power than you.

It's really not that difficult to show the right amount of candor while being objective about the disagreement.

This doesn't have to be a game of chess where you overanalyze your every move. People will respect the fact you said something that might be the elephant in the room anyway.

The challenge is that these articles assume that you're working with vindictive egotists, and there's plenty of those in corporate America.

vii · 3 years ago

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.

vii commented on How to interview engineers (2020) spakhm.com/p/how-to-inter... · Posted by u/telotortium

vii · 4 years ago

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.

vii commented on My thoughts about the Principal role galiglobal.com/blog/2021/... · Posted by u/antonmry

vii · 4 years ago

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.

vii commented on SSD makers start warning that mining products like ChiaCoin will void warranty guru3d.com/news-story/ssd... · Posted by u/RachelF

VectorLock · 4 years ago

Most SSDs aren't designed for the repeated writing Chia requires. "Data center" or "high-endurance" SSDs have that capacity but are consequently more expensive.

>One alternative explanation is that maybe farmers were just wearing them out quickly and playing naive to claim the warranty?

That's exactly what they were doing. If you use a low cost "consumer" SSD you can wear it out very quickly then claim it was "defective."

vii · 4 years ago

Is that a false claim?

The expectation that an SSD or even SD-card is infinitely rewriteable (practically speaking) is implicit in the marketing.

The idea that a drive can't be rewritten too many times should be explicit (like SMR HDDs)

vii commented on Why do most top performers have the highest count of commits and pull requests? swecareer.substack.com/p/... · Posted by u/thathoo

vii · 5 years ago

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 :)

vii commented on Don't Panic dolthub.com/blog/2020-11-... · Posted by u/bheni

throw_m239339 · 5 years ago

> that Rob Pike says it's OK.

I should say, Rob Pike didn't put in the language the features that would have helped alleviate the pain of writing 50,000 times the exact same statement littering Go code bases like a plague. Go errors are purely a convention that is no better than C style error code returns. Not good enough in whatever year Go was designed. There are solutions to that issue that are much more composable than that (options, sum types...).

People come to Go for performance and concurrency (although context is another one of these tacked on horrors) and they leave the language because of the crazy ceremonial boilerplate it incurs.

vii · 5 years ago

Rob Pike wrote this about handling errors https://blog.golang.org/errors-are-values

This is like an option type but manually built.

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.

vii commented on Linux Developers Discussing Possible Kernel Driver for Intel CPU Undervolting phoronix.com/scan.php?pag... · Posted by u/varbhat

jeffbee · 5 years ago

If it's just an MSR write, what do you need a driver for?

vii · 5 years ago

well that's the subject of the Linux kernel thread as the original patch was just to remove a warning from the use of the Intel MSR https://lore.kernel.org/lkml/20200907094843.1949-1-Jason@zx2...

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.

vii commented on Managing Technical Quality in a Codebase lethain.com/managing-tech... · Posted by u/r4um

vii · 5 years ago

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.