6 ms·

Hey, n00b, we didn't hire you to complete tasks

• atomicnumber3 4mo ago
  I sure wish I could relate to this but I haven't been at a company that hired juniors since i was the junior being hired 15 years ago.
  • ethagnawl 4mo ago
    Same. This does not align with my experiences working with early stage startups at all.
• LPisGood 4mo ago
  This is an interesting perspective(and a great roadmap for juniors to try to improve), but I think for the most part the thesis is wrong, at least in my experience. Companies do not hire juniors as some long tern play to develop them into good engineers. They hire juniors because they have junior level tasks that need completed.
  • colechristensen 4mo ago
    >Companies do not hire juniors as some long tern play to develop them into good engineers Working for companies, as a manager, I have. I have said to my management that is what my intention was, and subsequently hired people for exactly that.
    • wseqyrku 4mo ago
      The thing is when you're starting out this is probably what you have in mind for each job you apply. But that only happens one out of ten.
  • mohamedkoubaa 4mo ago
    Not anymore. We give those tasks to genies and hire juniors as apprentices
  • jordand 4mo ago
    That does happen, and that junior level work is constructive, but what I've also experienced and noticed is that companies put a lot of effort into finding and hiring exceptionally skilled juniors (industrial placement schemes, graduate fast-tracks, etc.) where they can make safe bets on those people delivering significant value to their companies/projects. Some bigger companies do make an effort to build a mutually beneficial working relationship with a clear 5 year career roadmap (some sectors really struggle with those best candidates choosing FinTech instead). I've worked with high-performing junior programmers that have (quantitatively and qualitatively) dramatically outperformed experienced mid-level programmers, so I'm always an advocate for investing in them.
    • danbolt 4mo ago
      This is often win-win as the junior ends up with a robust list of resume bullets that help push their career forward.
  • SanjayMehta 4mo ago
    We used to hire explicitly to train junior engineers in the days before the dotcom boom. Stock options which vested over 5 years were meant to make it worth everyone's time.
  • moregrist 4mo ago
    > They hire juniors because they have junior level tasks that need completed. I have never worked at a place where this was true. Either senior devs would pound through the tasks, or we’d cut them as unimportant. The only reason we ever hired a junior was because we saw potential and thought they could grow into solid colleagues.
• chalupa-supreme 4mo ago
  For a B level: > * You did not cause other people unreasonable amounts of work.* I would be careful with this one. As the examples listed after, such as an on-call incident or extra review of code isn’t necessarily on the n00b. Maybe I’m biased being only 4 years into my career but engagement on stuff you did wrong or even points on what you can do better are extremely valuable. From my standpoint, screwing up isn’t a problem if you can engage with the team to recover and learn from it.
  • teeray 4mo ago
    I would as well. If you didn’t stop it at the review stage, it’s the team’s problem. It’s not “X’s code broke prod.” In at-will, X can up and leave before you have time to give them shit for it. Then it’s the team’s problem anyway. Make sure you collectively own what you merge.
    • sleples 4mo ago
      It's not so simple, especially in the AI slop era. Reviewers are already flooded because people of varying skill opening PRs at a rapid rate and it's not practical to be able to dive deep into every line. It's up to the implementor to take some responsibility and make sure things are correct. Because of the AI lunacy going on at most companies, if you call any of this out you get labelled a luddite and are put on top of the layoff list, so at least for now it's just something you have to deal with.
  • accurrent 4mo ago
    A lot of this article reads like an egotistical toxic senior dev. I agree with your take. I tend to agree that "not generating unreasonable work" is not a good signal. If I do 0 work I can fall in the "not generating unreasonable work" category - thats not a good signal. Also the "Your manager or your tech lead could finish those in much less time and with much less hassle than it takes to help you through them." suggests that he is not hiring talented juniors. It is also a good senior dev's job to architect and scope tasks so that juniors dont bring the whole system crashing down.
• noodletheworld 4mo ago
  The A signals are not A signals in this article, and this: > You may be wondering where this “extra” time is going to come from. You’re already committed up to your eyeballs. …We’ll talk about time management, task queue management, diff queue management, and other topics that will accelerate your progress. Is just corporate dog whistling. If you are over committed, no amount of time management will solve your problem. Using AI wont solve your problem. You have a fixed amount of time and too much work? Work. More. Hours. Thats the real game; spend extra time outside of your normals hours doing extra. Congratulations, you’re an “A”. Makes no difference; your resilience against restructures is not correlated with how much respect you have from senior developers. That shouldn't be your goal. There are many places that do what they call “data driven” performance evaluation (translation: avoid being racist by looking only at anonymised numbers) and they do, indeed, look at 40 completed tasks and go: we will keep this one. The strongest advice for a new starter is: at your specific company ask what you will be reviewed on, and do your best to do whatever that is. Generic advice is a dime a dozen; don't fall in the trap of assuming [generic advice here] will apply to your specific workplace.
  • colechristensen 4mo ago
    Eh. There is a lot to be said about how efficiently you work. This involves making choices about how you solve problems, in what order you solve problems, how you manage people interrupting you, your personal life interface with work, how you advocate for what work to be done... on and on and on. An easy example: spending 2 days on automation for a task that takes an hour to do manually -- is this a task you have to do once a year or once a week? -- what do you choose to do? How many meetings do you schedule? How many do you accept? How long do you spend struggling on a problem before asking for help? How often do you not even try something before asking for help? And on and on and on.
    • noodletheworld 4mo ago
      This is self-help nonsense your manager will tell you when giving you too much work. Companies will smartly balance the amount of work allocated to people. …and then they will push you to take on more work. High achievers, across the board, consistently demonstrate putting more effort in. Its just a bitter pill to swallow for some people.
• smackeyacky 4mo ago
  I work at a place that is actively hiring juniors. While they don’t have an explicit rating system I feel like we unconsciously follow a similar pattern with new coders and it’s unfortunate. Given that older staff generally have a legacy of responsibility they don’t always have the time required to coach people who lack that self-starting spark. The quality of the questions and how much effort they have put in to answer things themselves are what differentiates a C from a B. Mostly you can quickly answer something a B asks. But a C who sponges up your day quickly gets categorised into not being given fun or difficult work. With funding and resources this wouldn’t have to happen but the industry treats mentoring time as lost time. You aren’t getting your story points done if you’re helping somebody else do theirs. The stupid agile bollocks management style has no eyes on the future of an organisation.
  • mlinhares 4mo ago
    Not to sound soulless but why would you want to invest on the C’s? Unless we have no options I don’t see why so that. I’ve had to deal with people like that and it’s a tar pit.
    • analog31 4mo ago
      One thing is that the A's are watching how you treat the C's. They might not have a good gauge of the culture from their own experience because they take care of themselves.
      • mlinhares 4mo ago
        They should be getting praise and more mentoring, not sure why they'd worry about how the C's are being treated. It should also be clear to the C's that they are not making the cut and either they get better or they leave. There's something that is very pernicious in the government in Brazil (where I'm from) where in a department there's one person that does all the work while everyone else sits around. You can't fire the non-performing ones or push them because there is a very strong worker protection system for them. Back in college it took me a full week to get my grade history because the person that did all the work was on vacation and nobody else bothered to learn how to pull it or cared if students couldn't get the report. These are the C's, people that have to be forced to do the work, and that will eventually cause all the work to pile on everyone else. There's no fun in working in an environment like that and its a quick recipe for a burnout.
• ANarrativeApe 4mo ago
  This makes complete sense in an environment where people transition from noob to senior engineer within the same company. It makes less sense in an era when tenure is better measured in months than years. It makes even less sense in an era of LLMs. One area where it might be relevant is the military. People are more likely to stay for longer (unvalidated assumption) and the same personnel jacket follows them if they are transferred. It might also be thought of as a guide as to when to jump ship. If you have managed to get yourself categorized as a C, then leave. Start fresh somewhere else, take the learning with you, and discover if you have what it takes to make it as an A or B.
  • malux85 4mo ago
    I completely disagree with you and it seems like your assumption is that the transition times are years. I've seen a B player on my team turn into an A player in just the last couple of months But I do agree with you about the C thing, if youre a C you need to move immediately to at least a B, otherwise leave
  • sieabahlpark 4mo ago
    [dead]
  • luipugs 4mo ago
    > It makes less sense in an era when tenure is better measured in months than years. If a person's tenure in companies is measured in months then they're signalling they're a C by your logic, or is at least raising a red flag to whoever's hiring. I may be showing my age but that sounds wild to me if that's the norm now.
    • Antoniocl 4mo ago
      Maybe this depends on the framing? Ex. 18 months is fairly common in some circles, but that could alternatively have been expressed as a year and a half. 6-12 months? Red flag 12-24 months, especially early-to-mid career? Not uncommon
  • ecshafer 4mo ago
• thin_carapace 4mo ago
  what a foolish take. our benevolent overlords currently are bragging about how many lines of code that AI writes for their companies. clearly output volume is the only relevant metric, why would anyone bother demarcating quality and quantity
• jofzar 4mo ago
  > We seniors have our regular work to do, but we also have to figure out which category you fit into. We support the superior performers as much as we possibly can. We support the solid performers enough to help them mature. Brutal as it seems, we’d like to expend as little effort as possible on people who aren’t going to make it. Holy crap this person has only ever worked in toxic work environments
  • titanomachy 4mo ago
    I think he worked at Facebook for a long time, which is… pretty toxic by some standards.
• BobbyTables2 4mo ago
  Some new hires end up cleaning the mess that their manager left behind from back when they were the noob…
• logankeenan 4mo ago
  > You uncover a better design and submit a string of diffs not only implementing the task but simplifying other parts of the code too. Bonus points for doing this before you implement (make the hard change easy then make the easy change). The last part of this really stands out. A high performer understands that software is malleable. However, the way you shape it, when things change, and how much is changed at one time matters a lot
  • Fr0styMatt88 4mo ago
    As a senior you can get into a bad habit of being scared to make changes. It happens after enough experience with enough codebases. It’s good to not just go change things for the sake of it — it’s equally as important to ask yourself if you’ve gone too far in the other direction and to always remain curious and critical of yourself.
    • N_Lens 4mo ago
      What if you’ve become too curious and critical of yourself?!
      • dolmen 4mo ago
        You're now a C.
  • adamors 4mo ago
    The flip side of this is the "high performer" who is constantly refactoring legacy code because they can only understand code that they wrote. And then add overly DRY refactors all over the place that is a pain to then make specific again.
• AtlasBarfed 4mo ago
  Yeah, someone is pulling up the ladder here.
• 0xbadcafebee 4mo ago
  "Brutal as it seems, we’d like to expend as little effort as possible on people who aren’t going to make it. It’s your job to get in the category you want to be in and send us the signals that tell us that’s where you belong." And this is what a complete lack of leadership looks like. "We are paying your salary now as the option premium on the engineer you are going to become. If we play this game right, we’ll have a kick-ass next generation of engineers." Not if you do jack shit to help them improve.
  • N_Lens 4mo ago
    Post is emblematic of a toxic workplace and reminds me why people remain stuck at a particular level - they learn the wrong lessons that “work” in their environment, and they just think “this is how it is”.
• econ 4mo ago
  You missed figuring out if your position is supposed to make [grandiose] proposals. Monitor what everyone else is doing, how fast they do it and what you can do to help. Condition everyone to think it's Xmas if you hand them something. After doing that 200 times hand them something obviously nonsensical just for laughs.
• iJohnDoe 4mo ago
  This only works if the culture is healthy and the seniors are mentally healthy. Usually, most are trying to protect their turf. Because even having “seniors” in the first place means they been there for a few years and they would like to keep it that way. Otherwise, no one gives a crap about what the n00b is doing.
• radley 4mo ago
  > You submit useful diffs in areas that having nothing to do with your team, but not at the cost of finishing your official tasks. > You write up what you learned in an interesting, useful and persuasive way. Very curious (and appreciative) that some company cultures allow this. I haven't had such experience (although I work in a parallel role). It's usually just grinding out tickets.
• nilirl 4mo ago
  I've met maybe 1-2 people in my whole life who were clearly beneficial 'A' from the get go. There's also a weird 'A' that tries very hard but causes more pain than inspiration. Meaning, they're clearly smart but think that's all that's necessary to be useful. I once worked with an intern from MIT who came in and immediately submitted large PRs everyday that improved the algorithmic complexity for a bunch of functions. Which was awesome to see but the changes were off the hot path and the code was much harder to read. The part that still comes to me was when I'd said during a code review that there were other more pressing concerns, the intern said yes but you can't argue against the improvement in time complexity. Smart guy. Inspirational, even. But better suited to a large corp than a startup. I think a startup 'A' has a lot more to do with attitude about speed and uncertainty than competence.
  • renegade-otter 4mo ago
    Related, but the best quality to have in a startup is knowing when and what corners to cut instead of going on these side quests.
    • apsurd 4mo ago
      I used to think this but you only know which were the right corners to cut after the fact. And most things are not obviously right or obviously wrong, instead it’s a slow zombie death by a thousand fuzzy signals. And the management tier of the startup will too easily color the signal by the flavor they want to see. My latest take on this matter is to separate speed as in fast from quick. Quick is the thing you want and almost always good. Fast is what usually gets lauded and measured but fast just gets you large volumes of fuzzy signal faster. (quick means that something can take time and be measured, not rushed, things can bake, and the feedback loop is responsive quickly throughout the loop. while fast is looking at wall clock time and goaling on the end-result yield from the loop. i think it’s very misguided. things very often need bake time)
      • deleted 4mo ago
        [deleted]
      • 4mo ago
• asveikau 4mo ago
  So much of this is written with an air of superiority over the noob. Indicates a bit of an ego problem. Yes, the noobs are noobs, but the goal isn't to exercise your status over them. Or even to waste that much time trying to categorize between A, B, C. The goal should be to boost everybody's productivity instead of treating them like a game.
  • solannou 4mo ago
    I agree. A more modest way of speaking would be welcome. It takes effort to get through but the content is quite interesting: it gives pragmatic milestones.
  • projektfu 4mo ago
    I think the article is explicitly saying, "Ok, you're green, we know that. We're spending extra time with you to make you productive. You can help that process or hinder it, and if you're unteachable or uninspired, we'll probably end up letting you go. So here's some attitudes that get people singing your praises at this early stage." I'm not sure if this is the last gasp of this type of thinking as AI changes the landscape. There's a good chance that the future is just noobs, perpetually begging LLMs to do better until it works.
    • lokar 4mo ago
      One possibility is it makes grasping these points quickly even more important. IME new grad hires are break even effort for me for the first 6-9 months. If it’s clear they will become positive after that I put more effort into helping them. LLMs may alter that break even math.
  • IshKebab 4mo ago
    Yeah, the author clearly has his head up his own arse.
  • eudamoniac 4mo ago
    The seniors are superior to the noobs. Kind of by definition.
• graphememes 4mo ago
  at this point i'd take people who complete tasks
• psadri 4mo ago
  It’s interesting that you have to be an A to tell the rest apart. And good luck if you have a lot Bs that believe they are As.
• jswelker 4mo ago
  I have known a lot of people who think they are (the only) As and spend all their time bike shedding and generally dicking around with tooling and griping about patterns that they prevent everyone around them getting anything done.
• danavar 4mo ago
  This perspective is more of a confession about the current state of employment in big-tech, less so than engineering in general. There are plenty of places outside of FAANG where you can just be a butt-in-seat, completing tasks. I met plenty of principal, staff engineers in defense and medical device companies who were just amazing engineers who knew how to complete tasks and dispatch them. > That stack of tasks you have to do? Your manager or your tech lead could finish those in much less time and with much less hassle than it takes to help you through them" Ehhh.
• deleted 4mo ago
  [deleted]
• boje 4mo ago
  Sounds very similar to that leaked Mr. Beast document.
• casey2 4mo ago
  This kind of process oriented thinking eventually hits a scaling limit. Look at Meta as they struggle to scale their way out of basic problems that builder oriented labs had little trouble with. Zuckerberg bet on open weights but his company doesn't own GLM-5.2. >If I am trying to sway others, I would say that an org that has only known inefficiency is ill prepared for the inevitable competition and/or belt tightening, but really, it is the more personal pain of seeing a 5% GPU utilization number in production. I am offended by it. — John Carmack’s resignation letter from Meta (December 16, 2022) It's definitely possible to have a builder culture in a large company, but you need to insulate them from the rest of the org and have protective management. Nobody who happens upon a breakthrough is expecting it, all startups expect a breakthrough (their owners are crazy). Don't create a pattern of "stealing" tech from your employees; "tax" them instead. If this is correct then I'd expect to see breakthroughs out of valve in the next decade or 2.
• codemog 4mo ago
  [flagged]
  • girvo 4mo ago
    > And when corporate needs to lay off 30% they’ll think nothing of it. Having seen this literally play out this year: it was all of the C’s that were first to be cut shrug
    • codemog 4mo ago
      > Typical Kent, trying to do the right thing, regardless of the cost. Unfortunately, this time the cost was him losing his job. Well Kent got fired from Facebook, so maybe he wasn’t such an A player in their eyes. ;)
    • AlexeyBelov 4mo ago
      In a couple of companies I'm familiar with the cuts weren't based on performance in any discernable way.
  • projektfu 4mo ago
    If I hired a full time programmer and found out they had two other jobs I'd probably let them focus on those other two. If they were showing the "C" behaviors in all three jobs, they have no job security, unless they work where they can't be let go.
    • ponector 4mo ago
      Shouldn't you measure output instead of hours spent on the job? People could be productive or not with one job as well as there.
      • projektfu 4mo ago
        LOL
      • feoren 4mo ago
• foobarbecue 4mo ago
  I don't think this reductionist view of colleagues (dividing them into categories rather than discerning individual strengths and weaknesses, team-building, empowering) is very success-oriented.
• jchw 4mo ago
  Reading through this, for some reason, something clicked for me that I've really struggled to understand for a long time. I have received a truck load of positive feedback (but of course some negative too) in my career and I've always felt somewhat undeserving of it. It's not even imposter syndrome, I just never felt that, for example, "attention to detail" was really something I was good at, but I got that one over and over. In fact, I've often felt I am more than a bit hasty. I always edit my comments after posting them to fix something minor. Sometimes I am so hasty, that I force push the same branch like four or five times in a row before I actually have things in order. But I think I get it now. Attention to detail is what it looks like. I probably pay attention to fewer details than average, but through experience I've honed a pretty good sense for which ones are most important. The things I tend to screw up and need to amend quickly are usually mundane things that in some cases should possibly even just be automated. But even when I do realize shortly after pushing that something is full-on not gonna work, it's not that I sat there and did a careful sweep over all of the important details; my undiagnosed executive dysfunction would never allow for that. It was rather that I double checked just a few details as a sanity check, running things through mental models. And I think having a very good sense for what details you need to scrutinize is exactly what looks like careful attention to detail. It's nothing special, just experience; kind of like when they analyze the gaze of experienced drivers vs inexperienced and can see that the experienced drivers quickly fixate on important details whereas inexperienced drivers are less focused and scan more broadly. What does that have to do with this article at all? Well, when I read the C list I felt a little nervous. I mean I've broken production a fair few times. Have I ever failed to adequately communicate what I'm working on? Not often but certainly too many times. Generally I am also just mediocre at best at the parts of the job that aren't writing code. But, then when I read the A list, it just felt like reading a description of how I like to work. And I'm not special in that regard at all, but it's at least easier to understand what types of concrete behaviors might set us apart from less senior engineers, aside from more gray hairs and remembering using Windows 98, whereas most peer and manager feedback often feels too detached from the actual behaviors; because the feedback is what people perceive. And I am realizing it's actually rather important to understand the gap between how you feel inside about yourself and how people perceive you, if you really want to earnestly accept feedback, both negative and positive. I fully realize there is no non-conceited way to format this comment. "Oh, woe is me. I receive too much positive feedback that I feel like I didn't really earn." But, there really is a uniquely bad feeling from getting compliments you don't feel you have earned; what do you say, "But you're wrong! I suck!"
• pts_ 4mo ago
  Details are important. Tasks are details.
• Anuj7411 4mo ago
  [flagged]
• simon84 4mo ago
  I see the article focuses on tasks and things to do or not do. These are primarily driven by skills of the junior. Though you should expect they have none. What sort of comes out between the lines is the attitude of the person, and I think this matters most and should be framed directly. You want someone curious that will peek beyond what you asked. Someone proactive that will not sit and wait for an assignment. Someone meticulous that will not self-satisfy of quick-and-dirty. When said like this, the article content resonates as the consequences rather than objectives.
• dosisking 4mo ago
  Generally A players work for C players. B players tend to work for the government. The person who the article sounds like a complete moron, though.
  • mlvljr 4mo ago
    [dead]
• dukodk 4mo ago
  This reminds me of a company where they wanted to put me at 100% contribution after 2 weeks. I just told them “I can’t contribute as fast as seniors so they will just have to do more work to hit your burndown charts” There were multiple red flags so I only lasted 2 months
• helloplanets 4mo ago
  The trope of "ABC players" is tired at this point. To be honest, even talking about "players" is kind of square in my opinion. In a similar way as the saying "don't hate the player, hate the game" is square.
• cyh555 4mo ago
  If you can't help your employer to be more profitable, it's not meaningful to talk about this. It is all about capitalism
• rambambram 4mo ago
  So, these self-proclaimed seniors... are they the one who signed the employment contract with the juniors? No? Then you're not their boss, you're a colleague. So stop confusing the two. Take some classes in employment law first. Guys like this are exactly the reason I don't work in big orgs. They might want their ass kissed, I'm not the one who is going to do that.
  • titanomachy 4mo ago
    No offense but you sound like you’d be a huge pain to work with.
    • rambambram 4mo ago
      If you want a slave, I'm indeed a huge pain to work with.
      • ukprogrammer 4mo ago
        employment is slavery lol
• watwut 4mo ago
  > That stack of tasks you have to do? Your manager or your tech lead could finish those in much less time and with much less hassle than it takes to help you through them. I just don't find this to be true and if this is true then the company should rethink how they use juniors. Maybe stop micromanaging them as much and expecting them to do thing your way. Or maybe give them lower stakes or easier tasks. Or maybe let them figure out some stuff by themselves. I dont know what the exact issue in this hypothetical company is, but if they are slowing you down so consistently, something is wrong. I also find this expectation that a person should do the listed "A" improvements from the get go weird. Juniors, but actually also new seniors, employees grows from just closing tasks to suggesting bigger improvements over time. The people doing A things grow from people doing B things, as they gain experience with particular code base, experience with local politics and mainly gain confidence - or loose excessive confidence. > You include solid unit tests. (I wish this was a B signal, but baby steps...) Like, for christ sake, tell them in the first code review. It is not that deep.
• watwut 4mo ago
  Compare and contrast following two A points: 1.) You make a convincing case that the task needn’t be done at all. 2.) You implement the task several ways. I think that I can make convincing case that doing task several ways is not needed at all. And also that task is actually done only after the decision which solution to pick was made.
• black_13 4mo ago
  [dead]
• tamimio 4mo ago
  Sounds like boomers crap, lemme guess, when you were a noob, was there any of this crap? Highly unlikely, probably no one even noticed you were sitting in the corner talking your sweet time to learn. Don’t make it harder on the new generation it’s already hard on them, thanks to you, mr.boomer. It is a job that’s making someone’s else wealthier, not a lifestyle, stop treating it like that or adding yet another source of stress. Even if they don’t perform the best that’s ok, it’s job, we are not supposed to be “maxxing” every category in life, mediocrity is mostly accepted in a lot of life categories. The crazy demands I see sometimes in job descriptions..
• hknceykbx 4mo ago
  I’m a “junior” senior and I’ve got a junior whose faith I’ll need to decide in a few months. How do you know if they are gonna be good? And how do you give them all of the possible tools to actually be good? Not like I don’t have a clue, but I’ll appreciate some advice. I think the biggest problem is that they almost dont ask questions. It’s like one question in two days. In past I had to deal with juniors who would flood me with questions, and with them it was pretty clear how they are doing (yes we talked about it).
  • dunder_cat 4mo ago
    I like to always tell interns/new hires that I measure their productivity in the amount of questions they're asking (whether its to me, seeing them roam into people's cubes or in company chat systems). AI has changed that calculus a bit since they can use the magic talking box to query the codebase with varying degrees of accuracy or as a search engine for someone's random internal wiki article/ticket from years ago. Nevertheless though, we're blessed with a codebase that is several orders of magnitude larger than what the human brain can fully internalize so if you're trying to do anything remotely interesting, you're going to have questions.
• shirleypatrick 4mo ago
  [dead]
• brailsafe 4mo ago
  Funnily enough, ostensibly for creating more work for others, I was just fired... before my day started. I'm not sure what failed or why, but because some of the team was on the opposite coast, they found out sooner and had to roll something back. All I know is that it was probably among a stack of deliberately organized PRs that definitely created more value than not, and were all reviewed and approved by the people responsible for the system, one of whom fired me and definitely couldn't have shipped most of the changes on their own. Despite it being a mistake and putting me in a vulnerable position now, I found it to be a sort of hilarious example of a headstrong control freak making impulsive decisions that detract from the team.
• Avrio15272 4mo ago
  [dead]