nostrademons (u/nostrademons)

nostrademons commented on That boolean should probably be something else ntietz.com/blog/that-bool... · Posted by u/vidyesh

breadwinner · 3 hours ago

Disagree. KISS is for bigger things like architecture. Exposing an enum instead of a simple bool is a good idea that will save you time later. The only time to not do this is if you're exposing internal info, i.e., breaking encapsulation.

nostrademons · 2 hours ago

It saves you time until you realize that those status flags are orthogonal. It's very common for a job to be both is_started and is_queued, for example. And a simple is_failed status enum is problematic once you add retries, and can have a failed job enter the queue to be started again.

KISS, YAGNI, and then actually analyze your requirements to understand what the mature schema looks like. A boolean is the simplest thing that can possibly work, usually. Do that first and see how your requirements evolve, then build the database schema that reflects your actual requirements.

nostrademons commented on Google has eliminated 35% of managers overseeing small teams in past year cnbc.com/2025/08/27/googl... · Posted by u/frays

greesil · a day ago

If you don't mind me asking, why did your team get bigger? Did your scope increase?

nostrademons · a day ago

I assume you're referring to my other comment, since I didn't mention my team size in this one.

I'd love to say that the answer is "because I'm a good manager", but I think that the real answer is "because there was money=headcount available, the layers of management above me successfully presented our value and inflated our needs enough to convince a VP to give it to us, and my own manager physically did not have enough hours in the day to have 1:1s with all the new incoming headcount without introducing some layers of management under us". If it weren't me, it would've been some other manager. For that matter, I wasn't a manager when I joined the team, but I was interested in managing and of sufficient level that I could pass department policies, so I ended up more than doubling my team size within 6 months of becoming a manager. The team was pretty busy for the first year or two after that - we'd gotten all that headcount by arguing that we were critical to some big strategic initiative, after all - but there were long periods after where we were oversized by a factor of about 2, so I just let everyone work 20 hour weeks and phone it in until the next big project came.

The more time I spend in the corporate world, the more I become convinced that success is a matter of meeting the minimum qualifications, bullshitting, saying yes to opportunities created by people who are themselves bullshitting, and doing the minimum amount of work needed to avoid being called on your bullshit. Businesses don't hire because they actually have work to do. They hire because they have money and money=headcount and headcount is the only way for a manager to get promoted or pad their resume.

nostrademons commented on Google has eliminated 35% of managers overseeing small teams in past year cnbc.com/2025/08/27/googl... · Posted by u/frays

frollogaston · a day ago

TLM is fine. TPM is the awkward one. I don't understand what hierarchy (if any) there is to TPMs, they kinda float around and ask people to do stuff. Some projects get passed around to different TPMs like hot potato. The skilled TPMs stick around and make things happen, but even then idk how that works because they lead people without having any actual reports.

nostrademons · a day ago

That is the point of a TPM. They're supposed to be the neutral third party that makes sure you're doing the work, and can explain to upper management why the work is not getting done. As such, they don't have any decision-making power on what the work is or how long it's going to take. Generally the manager and IC negotiate back and forth on what needs doing and on what schedule, they set their own deadlines based on the realities of the project, and then the TPM holds them to what they committed to.

Much of the reason the TPM job exists is simply so your manager can be an advocate rather than a nag. The nag job is offloaded to the TPM, but the TPM has no decision-making power, so you don't get perverse incentives where the manager burns all their relationship capital making you do your work, or sandbags the deadlines so they don't have to.

In many orgs TPMs are also in charge of goodies like fun events or device/swag distribution, as a way to offset the negative emotions that come from them basically being nags.

nostrademons commented on Google has eliminated 35% of managers overseeing small teams in past year cnbc.com/2025/08/27/googl... · Posted by u/frays

mandevil · a day ago

As someone who has worked in companies from <30 to >100k, I would say that what an EM does is more about communication. Think of a company with m employees as a m by m matrix, with a 1 where there regular communication and a 0 where there is no communication and a 0.5 for those hallway meetings which our CEO's assure us are why RTO is so important.

In a small company (let's say anything under Dunbar's Number), you have a very dense network organically, and EM's aren't necessary. As the company grows larger, the matrix becomes sparser and sparser- until you get to something like Google (180k employees plus maybe that many again contractors) and you have almost all 0's. So an EM's job is to solve the communication problem, because information still needs to flow around the company, in and out, whether it's "do this project" or "another team already solved this problem" or "this project is a never-ending world of pain and should be ended" to "employee 24601 is awesome and should be given more responsibility."

nostrademons · a day ago

That's a large part of it.

Probably the best description I've heard of the EM role is that "It's a large collection of part-time roles, all with disparate skillsets, that together are responsible for ensuring the success of the project."

Communication is a huge part of that - downwards (telling reports the information they need to be successful), sideway (getting information from cross-functional partners and managerial peers so you align your projects with theirs), and upwards (managing expectations and asking for direction at the appropriate point so upper management doesn't freak out).

But other skillsets involved are: playing therapist (managing anxiety, morale issues, resentment, and misconduct); coaching (both technical and interpersonal); splitting up vague exec mandates into subgoals; prioritizing; hiring; managing performance; serving as a point of contact for whatever random problems your reports bring you; negotiating; setting team structure; developing expertise among your reports; managing their careers so they get promoted; ensuring that they're recognized for their accomplishments; helping people have fun in the office; modeling a culture of respect; selling new product initiatives; and yes, enforcing company policy.

nostrademons commented on Google has eliminated 35% of managers overseeing small teams in past year cnbc.com/2025/08/27/googl... · Posted by u/frays

lanthissa · a day ago

we had this in my company it was pretty hit miss. Almost always the 'TLM' was someone who was in the role for a really long time and it warranted a second person, so it ended up being a 1-2 junior reporting in absorbing the knowledge that the tlm had.

If you were in a growing domain, and the TLM stayed engaged with the code it worked really well, but as soon as one of those failed it was a bad roi for the company and a pretty terrible experience for everyone. the juniors were never getting promoted since there was only room for 1 expert on the small domain. The TLM was just chilling getting 5-10% raises a year without going outside of their little kingdom, but making sure their domain worked well.

As their junior got better they coded less but their juniors couldn't grow as long as they were there because the niche didn't need that many people.

I don't think its a coincidence that all these companies eliminated these rolls after 2022. When you have unlimited money and massive headcount growth these roles can exist and give your good but not exceptional people room for career growth. At static headcount, you basically need to do what banks do -- yearly cuts or no one can be promoted or hired.

nostrademons · a day ago

I wouldn't actually say that, but I would say that the TLM role works at a very specific stage in a company's lifecycle, and many companies that use it (including Google itself from around 2010 onwards) have long since past that point.

IMHO, the conditions where a TLM role is appropriate are:

1.) You need to be in the company growth phase where you are still trying to capture share of a competitive market, i.e. it matters that you can execute quickly and correctly.

2.) There needs to be significant ambiguity in the technical projects you take on. TLMs should be determining software architecture, not fitting their teams' work into an existing architecture.

3.) No more than 3 levels of management between engineer and person who has ultimate responsibility for business goals, and no more than 6 reports per manager. The mathematically inclined will note that this caps org size at 6^3 = 216, which perhaps not coincidentally, is not much larger than Dunbar's number.

4.) TLMs need to be carefully chosen for teamwork. They need to think of themselves as servant-leaders that clarify engineering goals for the teammates who work with themselves, not as ladder-climbers who tell others what to do.

Without these, there is a.) not enough scope for the feedback advantages of the TLM structure to matter and b.) too much interference from managers outside the team for the TLM to keep up with their managerial duties. But if these conditions are met, IMHO teams of TLMs are the only way to effectively develop software quickly.

Perhaps not coincidentally, these conditions usually coincide with the growth phase of most startups where much of the value is actually created.

nostrademons commented on Google has eliminated 35% of managers overseeing small teams in past year cnbc.com/2025/08/27/googl... · Posted by u/frays

floren · a day ago

Do you have any opinion on the success/value of the TLM role?

nostrademons · a day ago

Former TLM that was involuntarily reclassified as an EM because I had too many reports. I'm from old-line (pre-2011) Google, so was an engineer back when the TLM role was one of our unique competitive advantages.

I have a lot of thoughts on this. IMHO, it's appropriate for the state that Google is in now, where it is a large mature conglomerate, basically finance & managerially driven, built around optimizing 10-K reports and exec headcount & control. It's not a particularly good move from the perspective of shipping great software, but Google doesn't really do that anymore.

The reason is because software construction and management is unintuitive, and concrete details of implementation very often bubble up into the architecture, team structure, and project assignments required to build the software. TLM-led teams have a very tight feedback loop between engineering realities and managerial decisions. Your manager is sitting beside you in the trenches, they are writing code, and when something goes wrong, they know exactly what and why and can adopt the plan appropriately. Most importantly, they can feed that knowledge of the codebase into the new plan. So you end up with a team structure that actually reflects how the codebase works, engineers with deep expertise in their area that can quickly make changes, and management that is nimble enough to adopt the organization to engineering realities rather than trying to shoehorn engineering realities into the existing org structure.

Now, as an EM with 10+ reports, I'm too far removed from the technical details to do anything other than rely on what my reports tell me. My job is to take a slide deck from a PM with 10 gripes about our current product, parcel it out into 10 projects for 10 engineers, and then keep them happy and productive while they go implement the mock. It will take them forever because our codebase is complex, and they will heroically reproduce the mock (but only the mock, because there is little room for judgment calls in say resize behavior or interactivity or interactions with other features and nobody's holding them accountable for things that management didn't have time or bandwidth to ask for) with some hideously contorted code that make the codebase even more complex but is the best they can do because the person who actually needed to rewrite their code to make it simple reports up through a different VP. But that's okay, because the level of management above me doesn't have time to check the technical details either, and likewise for the level of management above them, and if it takes forever we can just request more headcount to deal with the lack of velocity. Not our money, and it's really our only means of professional advancement now that product quality is impossible and doesn't matter anyway.

Ultimately the value of the TLM role was in that tight bidirectional feedback between code, engineers, and management. As a TLM, you can make org-structure decisions based on what the code tells you. As an EM, you make org-structure decisions based on what your manager tells you. But at some point in a company's lifetime, the code becomes irrelevant - nobody reads it all anyway - and the only thing that matters is your manager's opinion, and by transitivity, your VP's opinion. A flattened org structure with as many reports per manager as possible is a way for the VP to exert maximal control over the largest possible organization, mathematically, and so once that is all that matters, that is the structure you get.

nostrademons commented on House to investigate Wikipedia over allegations of organized bias thehill.com/homenews/hous... · Posted by u/xqcgrek2

Fricken · a day ago

It's time to move Wikipedia from the US to a safer haven

nostrademons · a day ago

You can just download it:

https://en.wikipedia.org/wiki/Wikipedia:Database_download

Downloading Wikipedia is usually a first step for people getting involved in prepping or data-hoarding communities, because it's so much easier than most other websites, and the utility you get from it is pretty large. And the downloads, while fairly large, will still fit on a typical home computer. There are probably tens of thousands of copies, if not more, floating around.

nostrademons commented on US Intel stratechery.com/2025/u-s-... · Posted by u/maguay

rswail · 2 days ago

Not only leverage, but also destabilizing those optimized businesses to harvest the capital assets from their balance sheets to pay for the leverage, while destroying the underlying business.

PE is arguably much worse than VC. VC's business model is well understood and by taking VC funding, you are committing to their expected returns.

PE is, usually, unsolicited and is designed to exploit what appears to be a "lazy" balance sheet, but which is actually a stable business producing output and providing a reasonable ROI.

PE has very few redeeming features.

nostrademons · a day ago

They're very much yin and yang. PE's operating model is to take businesses that are operating inefficiently, squeeze all the inefficiencies out, sell off assets that would be more productive under other management, and basically strip the company bare. If it kills the company, that creates fertile ground for new startups funded by VC.

Think of PE as the decomposers of capitalism, and VC as its seeds. Most people don't like to think of it that way because they don't like to be reminded that death is a part of life. But if you view capitalism as a living ecosystem and your role within capitalism as someone to accelerate growth and then accelerate death so that new growth can take its place, it all makes sense. And you can probably profit pretty handsomely from it, because most people don't view capitalism like that and instead seek stability in the dying parts.

nostrademons commented on U.S. government takes 10% stake in Intel cnbc.com/2025/08/22/intel... · Posted by u/givemeethekeys

eYrKEC2 · 6 days ago

Yeah. Risky compared to Intel. Intel manufactures chips _right now_. They have lost their process edge, but if I have to put chips into a drone tomorrow, I'm betting on Intel rather than any bag of scrappy kids. The risk that they _can't_ produce chips is the same risk as that of Hillsboro Oregon getting carpet bombed -- which is of course not 0%.

nostrademons · 6 days ago

Note that there are several drone microcontroller manufacturers based in the U.S. right now - ModalAI, ARK Electronics, Rotor Riot, etc.

The thing about drones is that they actually don't require much computational power compared to modern consumer computing. It's just math - control systems, calculus, trig, waypoints, etc. All of these were solved problems in the days of the Apollo Guidance computer, and will run comfortably on chips from 2 decades ago. The STM32F722 microcontroller that is one of the most common hobbyist drone chips is built on the 90nm process node, runs at 216MHz, has 512K of SRAM, and costs about $5/chip. FWIW, it's made in France and Italy rather than China, and STMicroelectronics owns its own fabs rather than outsourcing to TSMC or Chinese companies.

If you want to do things like computer vision on the drone, the computational requirements are quite a bit higher, but you can still run something like YOLO at orders of magnitude less computational power than what you've got in a Pixel 9 or iPhone 16.

...which makes me wonder if a better strategy for the military would be to fund a wide variety of domestic chip manufacturers operating at decades-old process nodes (eg. the 65nm process node from 2005 seems to be at about the sweet spot), rather than try to prop up the one American company that can compete on cutting edge 7nm process nodes. Particularly since the experience of WW2 was that simple, robust designs that could be easily licensed to other suppliers and mass produced (eg. the Hawker Hurricane, Grumman F6F Hellcat, Grumman/GM TBF Avenger, Liberty ship, escort carrier) were much more effective at turning the tide of battle than designs that were on the cutting edge of technology (eg. the Vought F4U Corsair, Gloster Meteor, Japanese Shinano aircraft carrier). The latter were often better in absolute performance, but arrived late, in small numbers, and with teething troubles that made the former carry the bulk of the battle. The Liberty Ship, for example, used reciprocating steam engines that were 50-year-old technology in WW2, but they were "good enough" and dead simple to make.