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.
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 :)
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.
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.
For the recursive functor application example on a tree, normal meta-programming would be a macro taking the type as an argument, and then generating the resulting case by case application code, at compile time.
This would be much clearer and could automatically keep working if more cases were added (adding new node types is common when adding language features to abstract syntax trees).
This is a very awesome demo but my experience with other templating systems in IDEs (like autogenerated toString and other methods in Java) is that making boilerplate easy to write doesn't help make it easier to read or modify.
This paper is surprisingly accessibly written given the complexities involved and depth of expertise of the author, DJB, who has made great contributions to many fields.
Unfortunately nearly all decision making processes are vulnerable to this kind of attack: processes are never clear, selection criteria always up for debate, and generally people pick a special option to present preferentially.
This generally just leads to suboptimal decision making - we're lucky to have DJB's focus here to improve this one.
The power of the Apple brand is so extreme that the fact that many users experience near weekly or daily crashes from this bug (or series of bugs) does not convince them to buy other machines.
The CalDigit TS3 dock is pretty solid for me on Linux, though sometimes it doesn't power on the DisplayPorts and the dock itself needs to be reset. I have a smart plug to do that.
However - given the high performance and deep system integration (PCI,USB,video) that Thunderbolt provides it's fairly extraordinary that hotplug works at all!
Setting a good objective function is pretty hard. In this context of consumer goods, it is at the intersection of three difficult problems:
- equivalent to incentivising salespeople, which is known to be very difficult, as short term incentives often are in opposition to long term ones
- distinguishing and dealing with spammers, robots and crawlers
- and setting up a stable reinforcement learning behaviour even for the short term, which is tough even without the first two problems
For these reasons, naturally business partners, designers, and others will be very curious how the bandit affects the customer experience.
Many years ago to solve this I made a system that would emit a list of (suboptimal) rules to exploit the opportunities learnt from small A-B test groups (like an epsilon greedy contextual bandit). These rules were reviewed by relevant stakeholders and then explicitly deployed to production as a configuration change, which allows for manual consideration of issues in the three above areas that are hard to automate.
There are many alternatives for distributed tracing like Lightstep, Jaeger and so on but the ambitious level of integration with log searching (like ELK) and payload tracking is like an integrated in-house Splunk. Great idea and great to see the energy and enthusiasm put into making debugging tools better! One dream feature for a tool like this: code execution counts showing which version of the code and even which lines were executed - in aggregate is useful but ideally for each trace.
Unfortunately, the tradeoff of value gained saving debugging time against cost of infrastructure and development is hard to manage. The storage costs are very easy to measure so it is tempting to go after them rather than the more intangible benefits that rely on a counterfactual of how hard things would be to debug without it.
The title is a little confusing as DNS over HTTPS is the technology that comes to mind for DNS privacy. That hides the DNS queries in an HTTPS tunnel, which means fewer actors can see or spoof DNS results.
The QNAME minimisation technique described in the article is about showing only partial requests to intermediate authorities in the DNS hierarchy. DNS over HTTPS can protect the request until it gets to the resolver, and then the QNAME minimisation system can hide it from interested intermediate DNS authorities. I guess in practice this means the .com servers can't tell whether someone is going to xxx.substack.com or yyy.substack.com just that they're asking about substack.
As the article points out, most users ask a shared DNS resolver to perform resolution for them, and if you want to, the Cloudflare public resolver 1.1.1.1 uses this technique.
The recommendation algorithm generally tries to avoid showing directly similar content. It's surprising it is all cats especially if you ever swipe. Perhaps this is an A-B test and you are in a group with lower boredom avoidance settings :)
Older firmware has exploits, which allow installing Ubuntu, etc. To prevent exploiting, old firmware refuses to boot if the new firmware has ever booted. This is marked by blowing fuses.
Note - there is even a fuse that when blown, prevents other fuses from being blown!
It's not surprising that a simple theorem doesn't deal with practical trade-offs. In my experience if you feel you are running up against the CAP theorem you need to take a moment to think about the real needs of your application and looking for a more detailed theorem isn't going to guide you well, instead you need to think about what you actually want to happen when various kinds of failure occur. In finance for example, often trading systems will choose to be available and accept transactions when there is a failure and then reconcile afterwards - swapping the risk of making mistakes but in a trusted environment to prevent the potentially catastrophic condition of not being able to trade.
The article claims that the CAP theorem only prohibits linearisability as a consistency model. The original CAP paper talks about "Atomic consistency" which is clearly at least linearisability. However as the proof formalizes, it's obvious that if you accept writes to totally split and separated systems which cannot communicate together (network partition), you cannot be consistent across the two parts. This is confusing because this kind of consistency only loosely matches the definitions in the ACID acronym which are geared around invalid database states in a single machine database, not about different requests to different database machines giving inconsistent answers.
> while maintainers are aware of that they sometimes intentionally bypass the process, they were surprised of the magnitude of unreviewed patches
Would love to see an analysis of these changes - are they just simple merge style fixes or rearrangements, or more significant?
And then there is the hard to define distinction between a security bug and a normal bug, which is then mixed into the the incredible productivity and pace of kernel development:
> Koah-Hartman argues that only a small fraction of Linux kernel security fixes are assigned to CVE entries. From 2006-2018, 1005 CVEs were assigned to the kernel. He argues that, on average, bugs with CVE entries are 100 days fixed in mainline before they get a CVE assigned.
Seems there is long lag between the bug being introduced and the exploit discovered, so there must be many potential security exploits that are never discovered before they are fixed - and so are not practically exploitable as they never get into downstream distribution kernels.