annoyingcyclist

A handful of the surviving planes are in museums. If you're at all interested in aviation and have the chance to see one, do. There's something special about them that doesn't come across in pictures.

If you're senior or have opinions about things, you know the feeling of falling into a rabbit hole of stuff you want to fix when you look at certain parts of your system. "I was going to rewrite this 3 months ago", "oh wait this part sucks too", "wtf is this class even for", etc.

Before coding agents, I'd have to weigh fixing these against my official work commitments, often getting shot down when I tried to get it prioritized or tsk tsked for delaying official projects to make code nicer. Now, to a much greater extent, I can just fix the things. The agents aren't perfect and the process isn't anything like hands off, but it's enough of a speedup that I can fit it in alongside my other work without having to get approval for it or try (and fail) to get it formally prioritized.

Not quite an oh shit moment, but having the end result of those rabbit holes be that the problems are fixed is pretty cool, and far preferable to what was often the case before ("we'll put in a ticket and prioritize it during the quality sprint!").

edit to add another:

I've personally never been a big fan of preplanning architecture at a code level. It makes a lot of sense at the system and data modeling levels, but code is both easy to get wrong if you're whiteboarding it before you write it and relatively easy (compared to system design and data modeling) to fix when that happens. If it's just me on a project, I'll happily start bashing it out with a vague idea in mind and evolve the design as I go, knowing that I'll probably throw a way a bunch of what I write at first. I know I do good work that way, and I'm not wasting a bunch of up front time on a design I'm likely to throw out later. It's hard to work that way on a team, especially as a lead, for obvious reasons. Coding agents fit really well for that work style. They'll cheerfully write dueling prototypes of my code architecture ideas so I can see which one I hate and which one I like without talking about hypotheticals and abstractions on a whiteboard. They never get mad at me for changing my mind, wasting their time, or throwing away their work. That's pretty cool. I can have a quick, cheap answer to "what would this look like if I got rid of class X and split its responsibilities between Y and Z?", and I don't have to feel guilty for wasting my time or my teammates time if the answer is "oh man that sucks, what a terrible idea."

To me, if "you are responsible for what you write" is to mean anything in an org, it needs to come with teeth. If you are demonstrably _not_ responsible for what you write, that needs to be recognized and treated as underperformance. I've seen a couple orgs who had some flavor of "you are responsible for what you write" guidance, and they mostly fail to follow through on it. People who ignore that guidance and ship a lot of low quality stuff (code, design docs, PRs) survive perf cycles and tend to get shout outs from management for moving quickly. People who take it to heart will tend to look slower by comparison (their work may be better, but often not in ways that are legible or compelling to management), and may be less favorably viewed when it comes to raises, promos, and so on.

I have no reason to doubt the sincerity of the authors of that post (and enjoyed reading it), I just hope they have a good sense of how they're recognizing responsible and irresponsible use and taking that into account in a perf process.

I don't think either of you is necessarily wrong (or good/bad here). They prefer to work the way they work (glaring issues and all), and are apparently successful working that way. You don't want to work that way, and want a role where you're not just crunching tickets (even if you could work that way). Just sounds like a bad fit to me.

For next time: it's really easy to accidentally ruffle feathers if you come in and start proposing tooling or process changes. People get attached to their project if they've worked on it for a while, and can take observations from an outsider as judgemental or an attack, regardless of how valid those observations are (many of yours seem valid to me). You coming from big tech can make people even more sensitive to this (if you're triggering their latent impostor syndrome or whatever as someone from a prestigious company). The way you summarize your manager's feedback makes me think that you either rubbed him the wrong way or offended some more tenured people who complained. Kind of hard to undo that now, but helpful to keep in mind for the future. If you demonstrate that you can hack it on tickets as you ramp up and establish some trust with your teammates over a few months, you'll typically have an easier time with this type of stuff.

(I would normally add a caveat that another good reason to wait a bit before bringing stuff up is that you might be missing the bigger picture, and that can help you ensure that you're actually arguing for useful change. I omit it for you because "we should have any observability at all for our production application" seems pretty uncontroversial to me and doesn't make me think you're out of touch or focused on unimportant things)

I kept reading and reading to find the part where the author took responsibility for any part of this, then I got to the end.

Organize professionally and/or advocate for ourselves with our elected leaders so the consequence of AI/LLM advancement isn't a bunch of people having to individually ask themselves this question.

I've been building an app to replace a long-suffering Excel sheet I've used for retirement planning. Started off as a calculator, eventually turned into something like ProjectionLab, though with a focus on what-if scenarios (e.g., how many years can I knock off my working life if I downsize to a smaller house or relocate to another state?) and risk evaluation specifically for early retirement. Not super fancy, but it's already flagged some risks that my spreadsheet didn't, and it's fun to have a codebase that's fully owned/controlled by me.

I've been slowly migrating logins off of a @gmail.com email and onto an email at a domain that I own/control for this reason. It's tedious and feels a little like an overreaction (presumably the odds of this happening to individual users are pretty low). On the other hand, the thought of some faceless fraud algorithm deciding that I should no longer have access to the credentials I use to log in to my bank, investment accounts, DMV, etc and having no real recourse beyond posting on HN and hoping that a sympathetic employee reads is pretty scary.

(I didn't want to actually host my own mail stack, so I just have a custom domain set up with fastmail and point the MX to them. Their UI is great and a breath of fresh air compared to gmail. I guess they could in theory decide to lock me out randomly too, though I trust them to have actual customer support and can just point the MX somewhere else in the worst case)

A founder who commits to 996 is as a side effect building a brand of "grit", "hustle", etc with their investors. That gives them options, regardless of whether 996 is actually useful for productivity and regardless of who is actually working harder as a result of 996: a golden jetpack into an executive role elsewhere when the company is sold for scrap, fundraising terms that give them liquidity not available to employees, a VC job, etc. They're also insulated from 996 to a degree that employees aren't. No one is going to count hours or badge swipes for the CTO/CEO of the company, and no one's going to tell them they can't leave the office early to spend time with their family. Even if they do work those hours, their job is different enough from normal employees to provide some protection from burnout.

As a rank and file employee, you get none of that. The investors don't even know who you are. The outcome for you if the company fails is that you're looking for another job while fighting burnout from longer hours and from working somewhere that doesn't respect you enough as a professional to let you manage your own time (which tends to come with other things that encourage burnout). All that to juice an "hours worked" KPI that research tells us is a questionable thing to focus on. You can do better.

Don't be silly, you have 0.01% of the company until they dilute you in their next raise.

I had this happen with an iPad that I received as an exchange when I sent one in for a repair. I booted the new unit up and was prompted to enroll the device in MDM for a school district in Florida. Kind of a frustrating experience, but Apple support was eventually able to get it unenrolled after enough escalations ("yes, I bought it from you", "no, I'm not going to sign in to an MDM-enrolled device with my personal Apple ID", "no, I've never heard of this school district and don't know anyone in IT there who could unenroll the device", "yes, I'm quite sure I didn't buy it off a truck").

I never learned what caused the issue.

Do you have a stake in the company – options, RSUs, golden handcuffs that you'd be walking away from, or whose value these decisions may be jeopardizing? If not, what are you getting out of staying?

It sounds like you're not aligned with leadership or the business on technical direction/prioritization, and the process of coming to the current technical direction has left you feeling underappreciated and judged for prior choices. It sounds like you're also an IC not in leadership and not embedded with the in group, so not likely to change much (especially if the business views this work as successful). I can't tell whether I'd agree with you on which direction would have made sense here, but it seems like you're just setting yourself up for frustration or worse by staying.

I have a year of living expenses in cash, several more in low-risk investments. I've been practicing interview skills (but I was doing that anyway). Making sure I have local copies of any personal creds from my work machine – 401(k) login, Carta, health plan, etc. Holding off on some home improvements – I'd probably like to have the money if I lose my job in a downturn, and I might get a better deal on labor in a downturn if I don't (or be able to snap up cheap assets or whatever). I chose to keep living in a HCOL tech hub even after everything went remote because I wanted exposure to both local and remote jobs – that's helpful in a good economy, and could be the difference between a job and no job in a bad one.

A lot of prep is done years ahead of time. Live within your means, save for retirement and for emergencies. Don't buy the most expensive house or car you possibly can – something that's technically affordable on a bubbly senior SWE salary is likely very not affordable on unemployment. With luck and discipline you can end up with enough of a nest egg that you don't have to stress too much about this stuff.

I graduated into the great financial crisis, and lucked into a couple of dead end jobs. A mistake I made was internalizing that the economy is bad, clinging to those jobs out of fear even after the worst of the crisis had passed, and losing out on some years of high earning after things started to get better.

I've been this in jobs, and am one of these people in my current job, so I can relate to what you wrote here.

There's a lot that goes into switching jobs, so it's hard to offer as general advice – it's much easier to do for some people than others. Switching into any new job is a reset switch for a lot of what you experience in your current role. You come in with no/minimal reputation, domain knowledge, relationships, knowledge of the code, etc, and you'll have to work to build all that – by itself, that's probably a refreshing change. If you switch into a company with a high talent bar, you'll get all that and also be nearly guaranteed of never being the smartest/most effective person in your area. This can be a big ego check, but also means that there's plenty of folks around to learn from.

I'm primarily a startup guy, and I'm good enough that I usually end up being a key person. I spent some time at a prestigious, trendy company filled with really smart people. I didn't like a lot of things about that place, but I _loved_ the caliber of my teammates. Everyone was above average, everyone pulled their weight, followed along in fast-moving discussions, politely/professionally challenged each other's ideas, etc. Definitely not lonely, and definitely a dynamic I miss in my current team.