munchbunny

We do this and then no one reads it.

My experience with AI-written documentation is that, as a category, it contains just enough technical errors that more often than not I end up spending time running down confidently stated errors the old fashioned way: cross-referencing API documentation, reading code, etc. At that point you inevitably end up trying to get in touch with a human from the other team.

In other words, it's not because I don't know it's there, or I don't want to read it, it's because my priors tell me it's going to waste my time. What I end up doing is searching, finding the docs, and reading until I start to get the feeling of hallucinated factual errors.

I'm sure there's AI-written documentation in there where the authors really did a good job reviewing it, and I just didn't notice. But I've also had engineers under me lose weeks of productivity at this point because of documentation confidently presented, insufficiently vetted, that turned out to be wrong.

If it’s a problem you’re willing to solve with money and don’t want any special stuff like mods, you can pay for a server with Realms and then you don’t need to think too hard about it.

But the canonical way to do it that is both free and infinitely customizable is to host your own server. It’s pretty straightforward to do these days. However, before you do, I would suggest playing the game a bit to understand what the settings are/mean. You and your kids could play together a bit on a Realms server or a community/public server to get a feel for what you want in a custom server.

If you're not set on a "survival mode" design, could you design it as counting up instead of counting down? And maybe showing a "par" time, that way players can opt into the challenge vs. just a morning brainteaser.

Another idea: maybe time how long you take for each word, and for the competitive among us, show stats on how long you took compared to everyone else, and a leaderboard for who took the least total time.

I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped.

I'm not sure I would go that far, but I would definitely say that I remember many, many moments where a Python codebase hit critical mass and the amount of time I spent documenting and checking types exploded. It wasn't really about static, explicit typing, so much as "once my tools (IDE) are taken into account, how much time am I spending trying to reason about correctness?" Reasoning about types was the main contributor to that with Python before type annotations.

The whole “you could only possibly pretend to care about other people” response to the book is vaguely psychopathic.

I prefer to interpret it charitably: the line between influence and manipulation can be pretty fuzzy, and some people come to a conclusion of, basically, "don't do it at all because it's always selfish."

I think it's a flawed view because it's impossible to go through life not influencing anyone and not wanting anything from anyone, so you may as well try to do it in a way that is generally win-win or at least not win-lose.

for some reason I got it in my head that it's a sort of red pilled book that teaches you how to manipulate people.

It's two sides of the same coin. Many techniques in that book are things that both genuinely kind people and manipulators do, the difference is intent. In that sense the idea of the book is a bit of a Rorschach test, although the way the author goes about it makes it pretty clear it wasn't meant to teach manipulation.

When I read the book over a decade ago, it did not feel like a red pilled book, it felt like a guide for well-intentioned people to learn how to express that more effectively. On the spectrum between "people orientation" and "task orientation", I was a task oriented person learning how to navigate personal and professional relationships more like a well-adjusted person would, and I suspect I and everyone around me was happier for it.

It’s rough at first but you will learn the baby’s rhythms and preferences. If you track their sleep and wake up times (I did it the old fashioned way in a notebook) you’ll see a pattern emerge pretty quickly, and then it gets easier because you will figure out how to work with it.

Every baby is different so most of the advice you find won’t work, but if you try enough things you’ll eventually find something that works consistently. Or you might just luck out and get a good sleeper.

But as any parent knows, changing nappies is really one of the easier parts of looking after babies and toddlers.

For sure, probably because stinky diapers are visceral but psychological challenges aren’t, yet I think most parents would agree about having to dig far deeper into our inner resolve to deal with age-appropriate behavioral issues.

"E2E teams" are difficult because your success depends on specialized teams to not screw you over - and not just in terms of politics, but it can happen just from them protecting their codebases and trying to focus on delivering under the pressure they're getting from their management, independently of the "E2E team's" goals.

If you think about the people in your team who command the respect and trust to be able to get past all of that wariness of team outsiders, it's usually a really small number of people, and usually they are veterans who've been around for long enough to have built those relationships.

I sneak thirty minutes in here and there for it regardless of my manager. If you work, say, 40-45 hours a week, you’re probably doing 20 hours of true focused productivity. It’s easier to borrow here and there from the other half of the time to flip through a paper or two.

In my experience it doesn't really work that way. It's somewhat akin to a house that's undergone multiple remodels. You eventually run out of the house's structural capacity for more remodeling and you have to start gutting the interior, reframing, etc. to reset the clock.

At least today the coding agents will cheat, choose the wrong pattern, brute force a solution where an abstraction or extra system was needed, etc. A few PR's won't make this a problem, but after not very long at all in a repo that a dev team is constantly contributing to (via their herds of agents) it can get pretty gnarly, and suddenly it looks like the agents are struggling with tech debt.

Maybe one day we can stop writing programming languages. It's a thought-provoking idea, but in practice I don't think we're there yet.

The point of the question is to have something remotely understandable for both sides to talk about, that’s it.

I think a lot of people miss this point.

Real projects are complex and have tons of context at the historic layer, political layer, and technical layer. If I have one hour to do the interview, I need to get to some shared context with the candidate quickly, or else it'll just be an hour of me whining about my job. And I usually don't need someone who is already a senior subject matter expert, so I'm not going to ask the type of question that is so far down the rabbit hole that we're in "wheels haven't been invented yet" territory.

Fundamentally, that's why I'm asking a somewhat generic design question. I do also dig into how they navigated those layers in their past experience, but if I don't see them in action in some way then that's just missing signal I can't hire on, and that helps neither me nor the candidate.

In another company or timeline perhaps I could run a different interview style, but often you're working within the constraints of both what the candidate is willing to do and what the company standardized on (which is my current situation).

While I agree, how much training does anyone get as an interviewer?

TL;DR: not enough training.

As a hiring manager, whenever we start a hiring period I have a conversation with my interviewer team about what qualities we're looking for and review the questions they plan to ask in order to normalize the process. Stuff like "what does a good answer look like, and why? what does a bad answer look like? is this something easy for a candidate to engage with or will you spend half the interview just explaining the background? is this coding question unreasonably hard?" and so on.

I also look at the evaluations that interviewers give relative to other interviewers. Almost every hiring cycle I've done I've had to deal with some interviewer (all over the seniority spectrum) asking unreasonably hard questions.

It depends on the situation.

Sometimes you just have a bad interviewer who is looking for something specific from you but isn't telling you. If you're experienced in these interviews, you catch the signs and adapt by asking questions to suss out which direction the interviewer wants to take it.

Sometimes your answer is plausible but the interviewer wants to see you justify it. Sometimes your answer is wrong but the interviewer wants to see if you can reason your way through it, and maybe come up with an alternative.

If you're junior/inexperienced, it's often hard to tell and it'll feel arbitrary/unfair, and unfortunately that's just how it goes. As a more senior/experienced candidate, you can often figure out which situation you're in by asking questions to feel out the interviewer and then try to pivot during the interview, though it still takes valuable minutes out of the interview that you could have otherwise spent showing your competence.

Having been both the interviewer and the candidate in this kind of situation, this is really a big interviewer training failure.

The general way to handle this as an interviewer is really simple: acknowledge that the interviewee gave a good answer, but ask that for the purposes of evaluating their technical design skills that you'd like for them to design a new system/code a new implementation to solve this problem.

If the candidate isn't willing to suspend disbelief for the exercise, then you can consider that alongside all of the other signals your interviewer team gets about the candidate. I generally take it as a negative signal, not because I need conformance, but because I need someone who can work through honest technical disagreements.

As a candidate, what's worked for me before was to ask the interviewer if they'd prefer that I pretend ____ doesn't exist and come up with a new design, but it makes me question whether I want to join that team. IMO it's the systems design equivalent of the interviewer arguing with you about your valid algorithm because it's not the one the interviewer expects.

If they're good at whatever it is they end up doing, that's good.

As a former PM (now an engineer), I think that's pretty much it. Teams and companies will vary a lot in terms of what they want the PM's to do, with some common patterns emerging, but as long as the PM's do the work well then the team is much better off. The key issue is how much you can trust the PM to hold up their end of the project.

A common theme I've noticed among good PM's: good judgement. When the team can trust the PM's judgement, the whole team flows better. When the team can't trust the PM's judgement, the PM is worth negative bandwidth.

I generally agree with the take. At the moment the models and agents aren’t good enough for someone who isn’t trained to build and maintain a production system. So as long as Eng isn’t significantly more bandwidth starved than PM, PM’s writing production code is not a high leverage activity.

The key issue right now is that the models falter in the last mile, and the last mile is where you need the training and experience to make sure the thing that lands is production quality.

At some point in the next few years I believe the roles will merge. I suspect that PMs will be forced to specialize towards a discipline (design, data science, engineering, etc.) while engineers will also start to see more of their responsibilities covering former PM territory. Most engineers will probably become closer to “product engineers”.

I've definitely found that I could inhale information faster and memorize much faster as a teenager. I think I was even faster in college.

In my mid-30s, I'm definitely slower to pick up new things than in my college days, but I have much more mental discipline and patience, a broader base of knowledge to draw from, and maybe the biggest differentiator: a much more developed sense of priority and focus in order to get more benefit out of less time.

My personal experience with this from the manager's perspective: I aim to promote someone as soon as they are ready, but no sooner. If I promote someone who will not succeed against the expectations of the higher leveled title, I'm just setting them up to get fired or "managed out" when they were otherwise perfectly competent in the level they're at. That's ignoring the natural fuzziness and storytelling element of defining and measuring competence, of course, but that's the general idea of where I put the threshold.

"Readiness" means that I believe that after their promotion they will be able to execute at the higher level at least most of the time. That doesn't necessarily mean they need to be already doing the higher leveled job, but in practice they do need to show that they can sustain some approximation of it.

This is cool. It feels a lot like business school cases where you get a packet of context and need to think about how to navigate the many factors at play, though with more direct practice, much less of the social dynamics of a class discussion, and less of a main character storytelling vibe, which are all good things IMO.

If there was a way to combine this with coaching sessions, I think this could be a very effective way to train IC's that are stepping into leadership roles (managers, staff/principal IC's, PM's, etc.). It could also be interesting to have a variant of the exercise where you ask the student/user to write their own message.

Or it could be both. Time will tell.

ConcernedApe's next game is also built on MonoGame, so he has self-interested reasons to want MonoGame to continue to be maintained. But just because ConcernedApe has self-interested reasons to donate doesn't necessarily mean that it doesn't also come from a charitable place.

MonoGame is basically getting a sponsor. The ecosystem benefits. I'm personally happy to leave it there rather than asking for moral purity.

I would like to see how fundamental the requirement to have directories are to AI workflows.

In my experience, it's not that directories are inherently important, it's that an organization mechanism is, in the service of a few key problems:

1. Privacy and data handling requirements

2. Versioning

3. Partitioning

4. Probably some others I'm forgetting

Hierarchical storage is a useful all-purpose tool for these things.

2. People behave as if they believe AI results are authoritative, which they are not

I'm not so sure they actually believe the results are authoritative, I think they're being lazy and hoping you will believe it.

In practice, it's like how having Adobe Reader used to be. You mostly don't need it, but occasionally you need it for interoperability with other people, such as lawyers.

Otherwise, I keep it around for the desktop Excel app. Still my preferred spreadsheet app, even though Google Sheets does pretty much all of what I need.

It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow.

Yup, this is the key issue and what makes it primarily a people problem. Technical solutions don't work if the main problem is getting buy-in to spec/build/adopt one, unless you're willing to build a lot of things you end up throwing out. So instead the bulk of the high risk work is actually negotiation between people.

Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues.

There's a small but substantial number of engineers out there who haven't operated at the kinds of scales where hyperscalers' limits become normal architectural problems and don't have the humility to imagine that it could be the case. (e.g. blob stores do in fact have limits you can hit, and when you operate at petabyte scales you have to anticipate in the architecture that you can hit them for even trivial operations.) I also work on petabyte datastores and have encountered a bunch of those engineers over time.

To be fair though, that's the small minority of engineers I've encountered, and if it wasn't arguing about the types of scale problems unique to petabyte scales, it'd be about some other nuanced subject matter. It's a humility problem.

As a data engineer in big tech, the two hardest problems I deal with are:

* Conway's law causing multiple different data science toolchains, different philosophies on model training, data handling, schema and protocol, data retention policies, etc.

* Coming up with tech solutions to try to mitigate the impact of multiple silos insisting on doing things their own way while also insisting that other silos do it their way because they need to access other silos' data.

And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs. As someone who gets to see all of those approaches - most of their approaches are both valid and flawed and often not in the way their leaders think. A few are "it's not going to work" levels of flawed as a result of an architect or leadership lacking operating experience.

So yeah, it might look like technical problems on the surface, but it's really people problems.

Some fairly simple examples where accommodations make the test more fair:

* You have a disability that hinders your ability to type on a keyboard, so you need extra time to type the essay based exam through vocal transcription.

* You broke your dominant hand (accidents happen) so even though you know all of the material, you just can't write fast enough within normal "reasonable" time limits.

* You are blind, you need some way to be able to read the questions in the test. People who can see normally shouldn't need those accommodations.

I don't think those are cases where you are lowering the bar. Not by more than you are allowing the test taker a fairer chance, anyway.

The problem is when you get into the gray area where it's not clear than an accommodation should be given.

You do need to expose your team to some of the shit that's getting flung or else your team gets used to operating under clean conditions and loses its tolerance.

For better or for worse, politics and randomization is just a thing in our jobs, and for at least some people in your team that means part of career growth is learning to handle it. If you, the manager, are the sole person capable of being the "shit umbrella" for the team, that's another way that your team gets a bus number of 1. (I learned this the hard way.)

In an ideal world you have some senior engineers who are more of the "don't bother me and let me cook" persuasion, and then you have at least one who is probably on track to become a manager, and they are your backup when you can't be in two places at once.