Looking at the list of affected architectures: Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), and SuperH (sh4) I think these are much much more likely to be run by enthusiasts than someone needing an affordable computer.
IIRC he works (worked) for Verily, and previously was at Valve working on their VR hardware. He's also mentioned having a business pre-Valve that made MRI safe controllers for users to interact with computers while inside an MRI machine.
I'm going to disagree with the "Asking a Lot of Questions" section. One of the best engineers I've ever worked with, who was at the Principal level, was completely unafraid to ask questions, no matter how basic one might think they were. Turns out he was rarely the only one who wanted to ask that question, and he was able to get understanding of a system or problem much faster than if he'd kept his questions to himself.
In the years since we worked together I've adopted his "there's no such thing as a stupid question" philosophy and it's served me really well.
I work with a staff level engineer that I think internalized the article's advice in the worst possible way.
Rather that asking questions, or reading code, when confronted with something new they will state "I don't understand X" or "I don't know what a Y is."
And then expect someone to jump in and fill in the gaps.
It's incredibly obnoxious and grating on a personal level and makes me not want to work with this person despite their other, genuinely valuable skills.
I can see myself saying exactly that in a meeting where we’re trying to explore a problem space to plan or make decisions - in which case I’d want to make it clear that I’m coming at that part of it blind, and am seeking enough information to identify tradeoffs.
What I’m not doing is expecting someone else to do the work of learning so I don’t have to. It’s limited to the topic at hand, and if it’s something that I expect I’ll encounter again I’ll spend time afterward diving in and learning enough to answer those questions for others in the future.
I’m perceiving your comment as you considering their actions to be laziness or disinterest. Is that accurate? If so, then yeah, that’s a huge red flag that could mean that this person isn’t suited for their role and expectations. If not, then it might be fruitful to sit down with this person to understand why they’re asking those questions and what they’re trying to accomplish. It could be that they’re simply not communicating their intentions.
The context is when this person joins an existing team/project to help out and do some work. So there will be, for example, a meeting where 4 people are up to speed, with this person present.
It's not expected that they know everything up front, of course. Onboarding to a new project takes learning.
A big part of the irritation to me is the fact that they decline to phrase their question as a question. Always a statement. They won't ask "what is X?", it's "I don't know what X is." Leaving the onus on others to reinterpret as a question for them.
> On the other hand, seniors who think they know it all are dangerous.
What’s working well for me is to open conversations by being explicit that I’m trying to make sure my knowledge is accurate, and that I’m phrasing things as statements of fact not because I know them to be true but because they are the premises that the weight of my position depend on. I want you to speak up if I’m wrong because I want us to succeed and I want to be right the next time it comes up!
I’ve also found that this bleeds over into other conversations, even where I’m not involved. If my team is used to working in an environment where premises should be challenged, they tend to do the same thing in other contexts. As long as the organization as a whole is accepting of this - and I can’t overstate how important that part is - the whole thing establishes and constantly reinforces a culture of collaborative skepticism.
I want to work somewhere that bringing an idea or a project plan to a group isn’t saying “this is what we’re going to do”, it’s saying “this is what I think we should do; if you disagree please try to convince me otherwise - because I want what’s best for us and I want to expand my own abilities”
I’m blessed to have a place like that today. I’ve had three in my career thus far, and I’ve stayed at each of those until I was forced to leave in order to grow as an engineer.
I interview with this in mind, and it’s very hard to tell from the outside. It seems that about 1/3 of the companies I’ve thought were suitable for me turned out to be.
Damn right, as an introvert all my career I have been afraid of looking dumb but talking to other fellow developers and reading things like the following made me aware of it.
I have a lot to say on this topic, but need some time to get my thoughts together before they’re coherent enough to share.
For context: I’m in my early 40s, have been in a technical role for ~20y, and have had a “SWE-equivalent” title for about 15y. My current role is Sr. Staff SWE.
Your comment resonated, though:
> as an introvert all my career I have been afraid of looking dumb
I remember feeling this way very early in my career. I wasn’t so much afraid of looking dumb, but of exposing to my colleagues that I lacked some critical knowledge, likely as a result of my not having a traditional CS education (or a degree at all).
A few years into my career I began to see that people were interested in what I had to say not because of who I was, but because of the way I presented the concepts. If I came at a problem openly, was clear about what I was and was not confident in, and spoke in terms of tradeoffs and balance, others would mirror this behavior and jump in to fill my gaps.
In moving into the staff engineer role, I focused on why some orgs I’d worked for were more effective than others. I came to the conclusion that it was cultural, and therefore also concluded that the way I could make the biggest impact was through building and guiding that culture.
I make it a point to ask “dumb questions”. Often I already know the answer, but have identified that if I were wrong there it would have an outsized impact - so I explicitly challenge those preconceptions and ask for argument.
I’m constantly telling people at all level (but especially those more junior who seem to speak up less) that asking those questions is important. I reach out to them early and directly, and offer to always be willing to ask questions that they’re afraid to ask on their behalf, and without attribution. If it ends up making a positive impact, I immediately and publicly give them credit. If it’s not well-received, I own it. There have been a couple of times that I’ve refused to tell leadership who a question like that originated from because they were looking for a scapegoat. I actually lost a job by doing that before I reached “staff” level (or perhaps before staff engineers were a commonly-understood concept?), and don’t regret it.
These days I work for a company whose culture doesn’t look like a good fit for me at all. I’m in a very red state, steeped in that culture (though not the politics - long and irrelevant story), and expected quite a bit of friction. What I found was that I could lean in to the “blameless/egoless” paradigm and make it work for me, and in the process make it a more effective organization as a whole. Now I find my self saying things like “I know you’ve hear this before, but I mean it: you can treat this as a safe space. I want to help our org succeed, and I want to help you succeed. I’ll do everything I can to protect you from the politics, help you grow as an engineer and as a professional, and be happy. If that means tapping my network to find places fro you to interview because you’re not happy here, I’ll do it.” - and I’m saying it as a big bearded dude with a deep Southern accent and absolutely no shame.
To put it another way - I’ve reached the point in my personal and professional life where I know exactly who I am. I’m not threatened by what others think of me, and am confident in my abilities to the point that I want to be aware of and clearly communicate my shortcomings so I’m as effective as I can be.
We all have moments where we don’t know (or can’t remember) something we should know. I’ve gone from being ashamed of that as a junior to seeing it as an opportunity to demonstrate that it’s normal and an accepted part of our company’s culture at the staff level.
The more senior an engineer is, the more important demonstrating difficult but necessary actions becomes. It makes you more effective as an individual and is essential for building effective teams.
It depends on the context. If it is a mentoring session, of course, fire away.
If it is a meeting with 10 or more people, asking a basic question can be interpreted negatively a) you are trying to embarrass the organizer of the meeting implying they are clueless b) you are trying to disrupt the meeting.
I’ve been in meetings as a Sr. Staff SWE where the expectation was that I could provide guidance and direction for projects using tools, architectures, or stacks that I’ve not used extensively… or at all. In those cases, I try to make it clear where I’m not confident in my knowledge and ask questions designed to uncover what I need to know to do my job.
I’ve learned to do that even in areas where I’m almost completely inexperienced. For example - I’ve never worked with Java and Spring Boot, but I’ve worked with the JVM and many application frameworks in other contexts, so I’d ask questions to help me understand the strengths and weaknesses of those tools, with a focus on areas where I’ve found friction in other projects with similar architectures.
I’m also always worried that I’m “taking over the meeting”, and every couple of rounds of questions I pause and explicitly ask if I should continue to investigate or take it offline and come back with findings.
What kind of meeting calls in 10 or more people? It's either a workshop (where questions should be welcome) or a complete joke (where I'd zone out, no questions needed)
That's great unless you're in an organization with insecure higher rank (ex-engineer management, staff engineers, etc) who take that as an excuse to dismiss anything else you say, treat all your concerns as XY questions, etc etc.
commentary from first time staff engineers should be taken with a grain of salt because they can be silly trying to prove themselves. same as first time people managers with an engineering background. if they're not a few iterations through the engineering manager pendulum, they're still getting their bearings.
if you're at a company where leadership doesn't understand this, do your mental health a favor and leave.
Can someone explain why we measure these datacenters in Gigawatts rather than something that actually measures compute like flops or whatever the AI equivalent of flops is?
To put it another way, I don't know anything but I could probably make a '1 GW' datacenter with a single 6502 and a giant bank of resistors.
Yes! The varying precisions and maths feels like just the start!
Look at next gen Rubin with it's CPX co-processor chip to see things getting much weirder & more specialized. There for prefilling long contexts, which is compute intensive:
> Something has to give, and that something in the Nvidia product line is now called the "Rubin" CPX GPU accelerator, which is aimed specifically at parts of the inference workload that do not require high bandwidth memory but do need lots of compute and, increasingly, the ability to process video formats for both input and output as part of the AI workflow.
To confirm what you are saying, there is no coherent unifying way to measure what's getting built other than by power consumption. Some of that budget will go to memory, some to compute (some to interconnect, some to storage), and it's too early to say what ratio each may have, to even know what ratios of compute:memory we're heading towards (and one size won't fit all problems).
Perhaps we end up abandoning HBM & dram! Maybe the future belongs to high bandwidth flash! Maybe with it's own Computational Storage! Trying to use figures like flops or bandwidth is applying today's answers to a future that might get weirder on us. https://www.tomshardware.com/tech-industry/sandisk-and-sk-hy...
As a reference for anyone interested - the cost is estimated to be $10 billion for EACH 500MW data center - this includes the cost of the chips and the data center infra.
Mh, in my recently slightly growing, but still tiny experience with HW&DC-Ops:
You have a lot more things in a DC than just GPUs consuming power and producing heat. GPUs are the big ones, sure, but after a while, switches, firewalls, storage units, other servers and so one all contribute to the power footprint significantly. A big small packet high throughput firewall packs a surprisingly high amount of compute capacity, eats a surprising amount of power and generates a lot of heat. Oh and it costs a couple of cars in total.
And that's the important abstraction / simplification you get when you start running hardware at scale. Your limitation is not necessarily TFlops, GHz or GB per cubic meter. It is easy to cram a crapton of those into a small place.
The main problem after a while is the ability to put enough power into the building and to move the heat out of it again. It sure would be easy to put a lot of resistors into a place to make a lot of power consumption. Hamburg Energy is currently building just that to bleed off excess solar power into the grid heating.
It's problematic to connect that to the 10kv power grid safely and to move the heat away from the system fast.
My understanding is that there is no universal measure of compute power that applies across different hardware and workloads. You can interpret the power number to mean something close to the maximum amount of compute you can get for that power at a given time (or at least at time of install). It also works across geographies, cooling methods, etc. It covers all that.
If you think about it like refining electricity. A data center has a supply of raw electricity, and a capacity for how must waste (heat) it can handle. The quality of the refining improving over time doesn't change the supply or waste capacity of the facility.
Because, to us tech nerds, GPUs are the core thing. With a PM hat on, it's the datacenter in toto. Put another way: how can we measure in flops? By the time all this is built out we're on the next gen of cards.
Assuming a datacenter is more or less filled with $current_year chips, the number of of flops is kind of a meaninglessly large number. It's big. How big? Big enough it needs a nuclear power plant to run.
Not to mention it would assume that number wouldn't change...but of course it depends entirely on what type of compute is there as well as the fact that every few years truckloads of hardware gets replaced and the compute goes up.
It simplifies marketing. They probably don't really know how much Flops or anything else they will end up anyway. So gigawatts is nice way to look big.
The yt-dlp devs also talk about this openly, in GitHub issues and elsewhere. I think there have been multiple front page stories about how yt-dlp works here on HN over the last few years.
That feature is called "reachability" and is designed to let the user access controls at the top of the screen with their thumb. It's a nice idea but triggers unintentionally too often IMO.
Thank you! I couldn't remember the name of it (and didn't feel like digging through menus to find it), so I haven't been able to disable until just now!
reply