Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

oliveoil posted:

If there wasn't poo poo to deal with and everyone just did what they needed at all times without obstacles then I'm not sure managers would exist tbh. Maybe TLs, but not managers.

This always makes me curious about companies like Valve or other places that have extremely horizontal setups; like how the gently caress does anything get done? It's either paradise or a nightmare. I also am very curious about the stuff that isn't...'fun' for another word, like incident management or security or compliance.

Adbot
ADBOT LOVES YOU

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
On the topic of moving around: I've been in big tech for a while now (10+ years, although I just recently switched over to dev from engineering / ops a couple years ago) and I'm trying to plan my next couple years out, so not actively looking right now but more thinking about what I'll do next. I'd like to try working somewhere less...constantly on fire and incredibly massive and complicated. I've heard good things about midsize tech companies from posts online, but my assumption is that these places are probably less well known than the big tech places.

I'm not against taking a pay cut to have a better job, but if you were planning a similar move, what sort of company would you look for, and how would you try and sniff out lovely places? I'm not looking to just find somewhere to coast; I've just constantly been on teams in big tech that have so much technical debt and deprioritized work you could double their size and never make headway and sometime's it's hard to feel like it's fulfilling, even if I do appreciate working with smart people and all that.

Falcon2001 fucked around with this message at 14:56 on May 11, 2023

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

lifg posted:

I don’t think you can get a feel for company culture from just the size. I’ve been in smaller/mid sized companies with 10+ hours of meetings a week.

One good signal you can find out beforehand is if the company is a technology company, or a company that has technology as a cost center. It’s a bit blurry sometimes, but a simple question like “does this company have a CTO” is start.

There's definitely some stuff that gets significantly more complex with size, from a dev/operations perspective. Like working with infra at BigTech is often a nightmare of hundreds of competing permission models and stuff to where a simple 'I want to do X' turns into a fifteen step nightmare process.

https://www.youtube.com/watch?v=y8OnoxKotPQ&t=1s It's just this video, all the time.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

bob dobbs is dead posted:

you can also just apply to oss companies and inspect their poo poo beforehands like i did with metabase lol

power move: Submit a PR along with your resume.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

leper khan posted:

I'm not a huge fan of the questions of those forms. The only things that stick in my memory are the hosed up times.

Questions like 'tell me about a time you X'? Because more and more those are becoming the majority of 'behavioral' questions for non-entry level positions at big tech (and so will probably cascade into other places); they're safe and provide a reasonable fascimile of concrete experience, as opposed to pure speculation questions.

FWIW I'd basically sit down before an interview and do some note prep on your side. Sit down and list out all the questions like that you've gotten and come up with examples ahead of time; you won't cover everything of course but it makes you think about the possible directions they could go and when not under pressure you might be more inclined to remember a more convenient example.

Like 'Tell me about a time you disagreed with your manager' is a trap question but you can absolutely answer it in a way that makes you look good, such as saying 'My manager asked me to implement X, and I was concerned about the performance implications so I did Y research and asked him Z questions, and then we went with solution U instead, which avoided the concerns I raised while satisfying the requirements' instead of 'Yeah last week he asked me if we could just control the .is top level domain and I had to take anti-migraine medication to avoid a stroke'.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

luchadornado posted:

Fun topic, what are your interviews from hell? I can think of two right away:

I had just started at a vendor company for Microsoft (very entry level, had only done help desk before that) and my new boss called me up and said there was a team wanted an experienced SQL DBA, but they wanted to pay entry level prices. He told them he'd send someone over to interview at the salary rate they wanted, and someone who could complete the job requirements, and asked me if I'd be willing to interview. I figured sure, I wouldn't mind being a DBA if they were okay with hiring someone with basically no experience but willing to learn. So I was interviewing with MSFT FTE employees; not for an official job there but just as a pass/fail thing for them to give the okay to the vendor team.

I showed up and sat down and they immediately started grilling me with high level SQL questions and I was like 'Ah so basically, I've done some really basic SQL stuff at college, but my degree (which I didn't have, I dropped out) was not in DB, but boy I'm happy to learn' and they just...refused to engage with this idea.

Six hours of interviews. I sat through six hours of increasingly angry devs trying to interrogate SQL knowledge I didn't have out of me. I was too young and scared of losing my job to protest or anything (the job I had just left was a loving nightmare) so I just...took it. Smiled, kept insisting I didn't actually know much about SQL but I'd love to discuss general options or other things I could help out with. Six loving hours of this, just hammering some kid fresh out of college as though I was secretly a DBA greybeard and was going to crack and go OKAY I UNDERSTAND DEADLOCKS AND HOW TO AVOID THEM YOU GOT ME. Surprise surprise, I didn't get the job. My boss called me up later and I explained what happened and he was like 'Jesus dude, you should have called me, that's ridiculous.' So I don't really think he had any idea what was going on. I started another gig there soon and it was much better and that kickstarted my career.

It literally hosed me up, like this day ended up being a frequent topic in therapy for me later. For years I was scared of interviewing and it kept me in lovely jobs constantly because my friends would have to literally sit me down and force me to apply places. As I started taking interviewing training as microsoft as an FTE later it was loving shocking to me because I realized that they absolutely could have just gone 'Oh yeah this dude doesn't know much' and either let me go home early or try and figure out what other skills I could bring.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

McCracAttack posted:

Who has that kind of time? Like, the people doing the interview I mean.

It was like, six different people. I honestly don't know, I ended up working with that team later on pretty closely and it still mystified me.

Like I've stopped interviews early (only a few times) or at least pulled my manager and next interviewer aside after my time slot to be like 'uhhh this is not gonna work out' - but I would never berate the interviewee even if it was a waste of my time; I'd just shoot the poo poo for the rest of the time or find something they've done to talk about, and I've never worked with anyone who would do that either.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

lifg posted:

I interviewed for a startup using Rails back when Rails was still new. This was back when every job requirements mentioned Ninjas or Rockstars.

The interview was a lot of… tricks. Like at one point they walked me through a problem of a server having troubles, and just narrated what was happening. I would say with my next action, and they would narrate the results. I was supposed to figure out the problem. Like an awful RPG, except a real job was on the line.

I didn’t solve it.

Then I was told the answer was, “the server had run out of space.”

Which is a problem that I had actually solved in real life. Multiple times. Sometimes after being paged in the middle of the night. And in real life a lot of small things goes wrong that points you in the right direction, like vi will complain about not being able to create a swap file.

And I tried to explain that to the interviewer, and talk about my real experiences, but he didn’t want to hear it—I had already failed in his eyes.

This one's wild to me because I've used this same style and the whole point is not 'Solve my RIDDLE' the point is to see what the interviewee would think about during that investigation, because every reasonable person who does this sort of stuff knows there's a million things that could go wrong and without actual access to a real server it's hard to tell. I often do have a specific answer I'm testing on here, but pass/fail doesn't mean getting to it; if you guessed it right off the bat that isn't a point in your favor, and if you use the time going over totally reasonable and meaningful options that's not a failure either.

Honestly, I think a lot of interviewer problems come down to people setting some sort of One True Answer to any given question and refusing to accept anything that doesn't fit their definition. If hiring was that easy you'd just have people come in and submit a scantron or something.

Falcon2001 fucked around with this message at 21:56 on May 12, 2023

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
FWIW: I have worked with professional developers at legitimate big tech companies that basically never bothered figuring out their debugger and just use print statements. It blows my mind because it's just so incredibly inefficient.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

TooMuchAbstraction posted:

Hello, yes, I rarely use debuggers. Not that I can't, but my experience with trying to use them for every problem is that I spend a lot of time diving through hierarchies of containers, and manually taking notes. The console provides a useful history that makes it easy to compare iterations -- often the bugs I'm dealing with are things like "sometimes when I call this function, it explodes, but usually it's fine". So I need to do a comparative analysis to find the differences between the working and non-working calls. Gathering large amounts of data in the debugger is tedious -- probably there's some way to make it less so, but it's still going to require me to set up the stuff I want to watch, then run the program, which is basically similar to print statements, so what have I really gained?

Debuggers, for me, shine when the amount of state I need to review is limited and easy to display.

I'm not saying there's no situation where a debugger doesn't make sense, and certainly sometimes it's hard to get setup (remote debugging can be complex in certain business situations/etc) but more that it's a very powerful tool. Nothing wrong with a simple print if that's all you need, or especially if you're just like 'what's in this goddamn dictionary' or need to parse things over time. But often a debugger has *really* helped me, especially on the last service I was working on, which had a long startup time and did a bunch of data collection before dumping into the interesting part; the guy I was learning from at the time just did print statements, but I was able to just dump into a debug session and then iterate through the data much quicker.

Logpoints sound rad for a lot of stuff though, so I might check that out.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
Yeah I mean the CEO is a little clueless, but remember they don't know your tech stack at most companies. Vulture Culture is 110% right here, and that response also makes you look like the sort of person a tech-unaware CEO wants in charge of their technical stack.

Like if magic was real tomorrow, and you had to hire a staff of wizards, you probably would send them some poo poo like 'I HEARD THIS RUNE CAN TURN YOU INSIDE OUT???' and you would want them to be in control of the situation and not to be like 'we don't use Bigby's translocation pattern here gosh jim read the arcane scriptures'

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

Pollyanna posted:

“I've seen a billion ways to do it wrong, and now I know not to step in poo poo” doesn’t sell as well, unfortunately.

I ran outages for a major tech company for a decade, including being part of a lot of in-depth technical discussions around repairs/etc, which left me with a ton of useful insight into exactly that topic. I can confirm that people were much less interested in that and way more interested in 'But do you have X years of Y experience' when I tried cutting over into dev instead at that company.

Which is a shame, because once I finally was able to transition over to a dev role, my team is super excited that I have all that experience and are trying to push me towards promotions because as it turns out it actually is useful.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

Pollyanna posted:

So my manager dropped some hints in today’s 1x1 that I’m not meeting expectations for my level, and that is loving me up. Obviously I’ve been kinda burnt out and dissatisfied on my current team, but this changes things and makes it feel a lot more like a personal failure. Which feels pretty fuckin’ bad.

Preface: That sucks man, it's always rough to get into a situation like that.

The best thing you can do right now is to try and get constructive, concrete details on what the gap is between where you're at and expectations - this serves a couple points. First, it gives you a chance to examine those and be self-reflective, and second, it helps identify whether it's bullshit or not.

If it's bullshit (handwavy answers, things that don't make sense, or just generally your manager doesn't seem interested in helping you fix it), then be polite and start focusing on getting a new job ASAP; don't bother putting a lot of energy into the feedback unless you're going to try and ride for a 'I'll leave quietly with some severance' package that some companies give if a PIP comes up. I had a job (pretty recently, possibly same company if I'm reading the tea leaves right here) where I literally got poo poo on by my skip level over and over again and there was zero explanation other than a general sense they thought I was being uppity. Once I got some confirmation from others I wasn't crazy, I just bounced.

If it's a real problem, then being concrete on 'what are some examples of ways I'm failing to perform' lets you sit down and think about those; it could be that those are things you can legitimately improve on and hey, maybe you'll come out of this better off. I got my rear end handed to me by a boss once for legitimate reasons and it actually turned out pretty well in my favor once I figured out what the problem was. If your manager actually wants to move you to a PIP they're going to need to move in this direction anyway, so heading that way generally shows good faith.

If the problem is 'You're not doing X', but the reason is because of some other thing, start building documentation/etc and looking around at how others are accomplishing it. If it turns out you're basically getting hosed (ex: "You need to show more cross-organizational collaboration, but we've been making you work on nothing but busy work for months and refused to give you a chance to do that") , then again, go back to the 'it's bullshit' part and prep to bounce.

One thing to consider is that you might just not be in the right team to be at your level; every big tech company wants to pretend that engineers of the same level and title are a totally fungible resource, but there's a huge difference in skillset between teams/etc, and you might be way more successful elsewhere in the company...or elsewhere at a different company.

Ninja Edit:

One time earlier in my career, I was at Microsoft and (during the days of stack ranking) got a 4, which was 'Needs improvement'. I sat down with my boss and was like 'alright, walk me through it and how this came up' and he told me that my project performance had dropped off a lot about six months before. I pointed out that was right when he assigned me to be the lead for a shift with three brand new guys who were all struggling and took all my time coaching them, and when I mentioned that you could tell he immediately realized he had hosed it up. It was too late to do any adjustments (stack ranking was a loving nightmare), but I was able to have a frank conversation with him about how I needed to get that information sooner than review season/etc, and we came out of it alright, although it was one of many reasons I realized he was a poor manager.

Anyway the moral of this story is that it's worth trying to approach your manager straight on and get details from him. If the guy's an rear end in a top hat or a lovely manager, that might not fix the problem, but at that point you shouldn't be sticking around anyway, because a manager's job is to help you improve and if they can't do that, don't work for them, because they'll gently caress up your career through apathy, if not straight malice.

Falcon2001 fucked around with this message at 03:16 on Jun 23, 2023

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

biceps crimes posted:

All feedback is valuable, but not all of it is good for you or is something that you should action upon, and the people who give it to you often don't have your best interest in mind. Your manager is giving you information when they give you vague bullshit feedback and don't want to be specific.

That's also true, but it is worth being direct with him about what it means. If you tell one of your directs that they're not performing up to par, you kind of owe it to them to help raise them up to wherever that is.

If it's just a vague warning that they're on someone's shitlist, then maybe they literally can't do anything about it.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

Mega Comrade posted:

I've only been a team lead for 4 months and probably have to do this for the first time next week. Guys throughput is just poo poo. You can't measure someone's complete performance via tickets closed but he's got half the number as everyone else on the team and most of them aren't difficult tickets, I've been trying to give him easy ones to sort of lift up his productivity.

But I honestly don't know how best to communicate that without just making him feel bad or panicked for his job.

You could also see if there's anyone else on the team that could help them out for a bit; or if there's something they're getting stuck on/etc. That might not be the case, but it's a good way to broach the topic in a way that can seem a little more comfortable.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
Others have mentioned it, but adding my support to the whole 'tie to something people give a poo poo about', but also...it does help if you have leadership that at least tries to give a poo poo.

The biggest problem with quality is trying to turn it into a measurement in terms of 'If we add tests to this codebase that has none, we'll accomplish XYZ savings', which is often very difficult to guess at, even if reasonable people will all agree it does improve it.

Blinkz0rz posted:

Stealth edit: it’s worth noting that engineer attrition is a lever you can pull in terms of incentives for product to want to do something about quality as well.

Adding onto this: the people who are going to leave due to stuff like this are also often the ones you want to keep, not the ones you quietly hope quit on their own to help you lower headcount.

Finally: re: AI - My company is also going balls deep on AI and I find it just baffling. I haven't seen any actual AI Engineers who are backing up the insane claims that PR people are making, and while I certainly think there's room for it to do cool improvements (ML in general I think does have some very interesting ideas for finding patterns in large datasets, for example), some internal video just called it one of the most important developments of the decade and I'm just like 'uhhhhhhhh'. I'm in the same boat as Pollyanna; I'm happy to continue not thinking about it.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
BIGPOST ALERT:
My background is in large-scale live services crisis management, so I have a lot of respect for networking teams (and a lot of first-hand insight into how terribly they tend to be treated, too, unfortunately). I did some schooling in networking as well, so I learned enough (long enough ago) to understand how complex networking is.

First, this sounds like a hilarious application of 'more devs is always better'; which I don't FULLY disagree with (In my time there, Microsoft was WAY too willing to fling contractors at problems that really should have had a small team of devs assigned instead for example), where you value development experience over domain knowledge.

Pollyanna posted:

My team also has a bad reputation:

We are slow. Let's take one of my first owned features for the big new non-production project thing as an example: ACLs.

It took us over a year to implement ACLs as asked. I first started work on them shortly after I joined in October 2021. Whole thing's stop and go - "stop" because the ACLs team doesn't like the solution and keeps rounding back for concerns and changes, "go" because how loving DARE we block the project? At one point I misinterpret the requirements and start emitting the wrong ACLs, leading to the feature getting kicked back. No harm done in this instance other than some failed tests and annoyed stakeholders, though.

Problem is, it keeps happening, keeps getting delayed, keeps trying to deploy and getting kicked back because something's hosed. Eventually I get sick of the back and forth and hand off the project - it was such a bad experience that I don't want to touch ACLs ever again. The current lead dev on the team took up the feature and has been working on it since.

To this very day the ACLs are still breaking poo poo and blocking project delivery. Because we are passing those ACLs along, we break poo poo and block delivery. You can repeat that story for every other kind of configuration that goes on a networking device, and there are a lot.

This just sounds like classic requirements failures, and any network engineering team worth it's salt should be the ones that should be screaming the loudest about it, not necessarily y'all. Networking is a complex, state-rich system with the most demanding uptime in your entire company, and thus requires real investment to work at scale. Not only should you have access to real networking engineers to work with, you should probably have some fulltime on your team at the bare minimum (or at least a handful of your devs having real concrete networking background).

Pollyanna posted:

We are dumb. In reality, we are software engineers with responsibilities that require a non-trivial amount of network engineering experience. When I first joined, I was assured that I didn't need to be a network engineer - but it turns out that whoever's in charge of the software that configures a network should probably have network engineering experience! "What do you mean you don't know the default BGP configuration for <insert random hardware here>??? Why are you annoyed that we're submitting bugs with a chunk of vendor-specific switch config and nothing else???" We've regularly asked for assistance from actual network engineers, to which the response has been "no and gently caress you for asking". I am no longer interested in network engineering, I'd rather go back to fart apps.

Yup, this ties directly into my original point about 'just throw devs at it, how hard can it be?'. poo poo's complicated. A lot of networking is not really understandable to folks without domain knowledge at first blush and there's a lot of concepts that for good or bad reasons, are not clear.

To put this another way: I have regularly had arguments with senior loving developers about how them getting a 500 error doesn't mean I need to page the entire networking org "just in case". (Before someone mentions it: No, we didn't use any layer 7 networking equipment; nothing in our network stack was emitting HTTP signals of any kind). The idea that just any dev should be able to quickly pick up much more complex networking concepts such as ACLs or WAN connectivity is loving baffling to me, given the real risk associated with failure to your company's bottom line.

Pollyanna posted:

We are unreliable. See ACLs. We have a track record of submitting changes and fixes that have to get rolled back because something was misunderstood, some requirement was not properly communicated, something else broke on someone else's end, or some rando team isn't ready for XYZ feature. Stakeholders get mad, tickets get kicked back, sprint progress gets reverted, I lose confidence in my ability to deliver and understand the domain.

In a perfect world, this should be leading to actual changes in your process. Either better requirements development, better testing, etc. The management churn you're mentioning is probably contributing to this, but this is yet another example where this isn't really your fault for loving up; your team needs to be seriously sitting down and examining why these occur and producing action items to close that gap. (Again, not you, but your team.)

Part of what really shocks me about this is that Google has produced a fair amount of work in this space, such as the O'Reilly Site Reliability Engineering book, although having worked at companies that size before, I am not entirely shocked that they aren't a hivemind and that some areas are worse than others.

Pollyanna posted:

We keep breaking things. The reasons why are complicated and incredibly stupid and thinking about them hurts my head, so I'll just summarize it with:

code:
Y U BREK DEVICE. U RUIN EVERYTHIGN!!!!!!!!!!!!
Followed by, and this is hearsay, literal shouting matches and tears. This leads us to:

We are the bearer of bad news. What our team does happens to be the nexus of many different stakeholders and services that I don't feel comfortable elaborating on. If anything goes wrong along this entire pipeline, it shows up in our service first. It's especially bad when something breaks further up this pipeline and we get pinged for a breakage that isn't our own!

For example, we originally called out to an internal P4RT library as part of generating switch/router configuration. At some point, someone screamed at us because a change in this library broke a device (took it offline, caused it to fail a test, whatever), and we switched to a hardcoded version of the pre-change data. Then recently, the internal library team got mad because they assumed we were depending directly on that library and would be able to handle some new feature that needed it - turns out we couldn't cause the hardcode was too old! When we pinned ourselves back to the internal library, the tests broke again and we were interrogated about it - back to the goddamn hardcoded version.



Without knowing the details, this definitely sounds like your team doesn't have the backing from a senior/principal engineer who should be putting their foot down and going to bat for you on stuff exactly like this, because if someone asked me what the outcome of switching away from a shared library to hardcoded settings, I would have predicted the rest of your story because...well anyone should be able to.

Another point: Being the bearer of bad news really requires that your org has the respect necessary to deliver that bad news, and that means both being able to deliver quality output (of whatever output is your requirement) as well as the backing of leadership to pull rank sometimes and say 'no you have to fix this or we're going upstairs'. Crisis management / safety engineering is the exact same boat there; I only talk to people when poo poo goes wrong, and I've been in orgs before where leadership only paid lip service to us, and so every discussion about 'hey that big outage is gonna happen again unless you do x' turned into 'welllll we really don't want to make time in the schedule to do x, so instead we're just not going to'.

Pollyanna posted:

So what the gently caress.

Mostly emptyquoting this because it covers a lot.

Pollyanna posted:

<Timeline stuff goes here.>

My problem is that this is clearly implying that poo poo's bad because I'm bad, not that I'm bad because poo poo's bad. How personally, exactly, should I be taking this? There's two possibilities here:

So, I don't know you from adam, and I can only take your story at face value and compare it to what I've seen in my time at other companies (never there specifically), buuuut:

I really don't think this is your fault in any meaningful way. This is what can only be described as ongoing systemic failures of management, and since management is, as an entity*, almost entirely immune to being self-critical in any meaningful way, means that they're looking at the 'well we have to reduce cost and headcount' and instead of having hard talks about what has to be done to keep networking running, are pulling a Principle Skinner and have decided that "No, it's the engineers who are wrong." You can either try and ride it out with a sort of zen equanimity or you can polish up your resume and look elsewhere. In my advice? b]Get the gently caress out of there.[/b]

* Individual managers can be, but in my experience any company big enough to get to Google's size, will never actually say "whoops we hosed up, sorry folks, we're going to try and make things better." It happens sometimes, (in fact my current job is in the recovery phase of one such massive fuckup that management is actually big on trying to avoid again) but it really requires poo poo crashing and burning hard enough that nobody wants to survive it.

Edly posted:

Sorry Pollyanna, what a shitshow. Sounds like your managers failed you; you're not supposed to have to figure all this out on your own.

Oh yeah that's a good final note: If you were at some tiny rear end company and running into these issues...well, that might be the breaks. There might literally be nobody there who knows any better. But at scale, one of the biggest challenges any large company has to address is sharing best practices across the company. You don't want to be Google's size and having each individual org relearn how to loving manage.

Falcon2001 fucked around with this message at 04:15 on Jun 25, 2023

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

bob dobbs is dead posted:

general ordinary technical skill, up to and including programming, has been declining in recent years. dunno the strict cause but my old profs and buddies of mine who became profs and adjuncts and such are pretty unanimous about it. so i dunno about the demand side necessarily but the supply side is favorable for already-skilled touchers, and i can't say that portents of permanent doom are apropos

now, doom for the 15-25 months starting last november when the big layoffs started hitting in earnest? i could see it. but doom for 15 months is not permanent doom

Yeah; I think the days of VCs handing ungodly amounts of money to hucksters to hire people with no experience for 250k a year is probably past us, but there an actual delivered promise underneath the hype for a lot of 'boring' IT stuff, so I also don't buy the whole 'oh yeah tech's gonna evaporate'. I think we might see wages flatten out and I definitely am not as big on it for folks to drop private college degree money on unless that's what you REALLY want to do, but at the end of the day there's a huge efficiency gain to basically every single industry by including tech stacks; either managed (at which point you're just paying someone else to maintain and write it for you) or in-house, where you'll need your own devs.

Salaries might flatten a bit but I don't see it turning into a minimum wage job any time soon, gods willing.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

bob dobbs is dead posted:

we're not back to 1980s interest rates, we're back to 2006 interest rates. which, peeps were doing vc in 2006, just less of it. and the late 70s and 80s actually saw the first big vc successes, in apple and burroughs and dec and poo poo

Nah I don't mean there won't be any VC funds, I just think the bar has risen quite a bit. But tech isn't all vultures looking for profits, there's a lot of actual product around tech that isn't entirely speculation driven.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
My team I joined a few months ago at a FAANG company is in an interesting position of being post-death spiral, but only for one of our three locations.

We do basically a shared devops sort of thing where we're doing platform style support (hundreds of services) but with actual devs and our own tooling/etc. Apparently the previous manager of my location was a nitwit (Don't have the full story, but apparently it was a combination of just incredibly poor management and some minor racism), and it lead to basically everyone except for one lone dude quitting the team and the other two sites having to work a lot of extra time to cover our time slots while we rebuilt. (That lone remaining guy is very, very smart but definitely falls into the entrenched category.) The good news is that management went 'wow uh gently caress that's a real problem' and hired some new folks in management that are a lot less lovely, and recent conversations among the leadership team have actually addressed tough questions like 'how do we promote people for reasons other than New Shiny Project that we will immediately abandon once that dude gets a promo' and 'how the gently caress can we balance maintenance with operations and whittle away at our decades of tech debt'. The team is also ancient, like basically as old as the company in one form or another, so we have a lot of accumulated cruft.

The upside is I'm at least reasonably confident we're moving in a generally good direction, and we rehired a guy that left to go off to another company because he thought the old direction was poo poo, and he's a real smart dude with some very good ideas, and came in as a principal engineer so he actually has enough clout to get poo poo moving.

The downside is that we definitely still have the '2x the work for the staff' problem, so...y'know, there's that.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
Two more notes about this whole thing:

1. It is part of your job responsibilities to raise legitimate concerns about your job at any sane company BUT learning how to land that feedback is tricky sometimes for folks. At Amazon they have a concept called Disagree and Commit, which I think is honestly a very smart setup: the idea being 'you should always raise concerns, but also recognize there's a time to disagree with the plan and commit to it anyways'. I've been operating this way for years and my managers have generally appreciated that I'm willing to say 'Hey I think this is a bad idea because XYZ', because if the answer is 'well we have to do it anyway because of random management thing' I generally just shrug and go 'alright, here's what we should worry about risk-wise'.

That being said, this process really does require trust in your organization to not be retaliated against or a sort of dead-eyed madness I gained at some point.

2. Sometimes I think that people get too cynical about management (which is not surprising given everything about late stage capitalism). The purpose of management, and really any hierarchy in business is not to 'manage down', it's to make individual workers more effective at doing their job. If this wasn't the case, we'd probably have a lot more completely horizontal companies. A good manager not only helps direct work, which is top down, but also takes feedback and pushes it back upstairs, as well as helps organize decision making/etc to reduce the need for individuals to duplicate effort/etc. You should expect your managers to be actively helpful, if they aren't, that's feedback.

If your manager views your relationship as purely one-way, then frankly put, they're not worth working for, although obviously that's a complex problem and we can't all pick who we work for. But IMO a good manager is way more important to me than TC at this point in my life because it influences so much about my job not being a pain in the rear end.

Rocko Bonaparte posted:

Heh I couldn't tell you. Maybe? I was interviewing at FAANGs as a generalist previously and the feedback was that I aced all the technical and behavioral questions--even the system design stuff for distributed systems I never normally even do, but they still didn't think I had the skills. So whoever I was stepping in front of was able to keep me out. I developed a bit of a complex over that but the solution so far has been to just dive all-in on whatever Linux kernel stuff I can get out of my current job and at least specialize in that. As far as I can tell, those roles tended to be pretty remote even before the pandemic, so I could do that under a rock somewhere and nobody would complain.

In my experience big tech companies have a weird relationship with generalists because one of the concrete differences between big and large companies is scope: a big company lets you be someone who specializes extremely narrowly, such as being a BGP specialist, whereas a company with 30-40 people is going to require your networking guy to know literally everything at least a little bit.

So by nature, a lot of big tech tends to produce very specialized people, which can sometimes be a problem when you try and go somewhere smaller or move around. On the other hand, people that move regularly in a big company tend to figure out the similarities between specialties and understand how to generalize things in a way that's frankly very helpful to do.

Add onto that individual org decisions on how they feel about generalists. I really struggled with the same thing you did while trying to switch roles to a junior dev title (along with the pearl clutching 'but your tc will go down!!' conversations I had with people) but once I did move I was pretty immediately helpful because it turns out have a broad knowledge base to draw on does make you reasonably good at picking up new things quickly, even if it doesn't help you get extremely specialized quickly. Some managers really get hung up on 'we need someone with our exact skillset' instead of considering the possibility of training someone into the role, which I find to be a really poor decision.

Falcon2001 fucked around with this message at 17:30 on Jun 26, 2023

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

jemand posted:

More lovely workplace talk

Some questions and comments:

1. Has your team tried pushing back on these expectations around instant interchangeability and timelines around that? If not, you should probably sit down and try explaining "this isn't how this works, and the proof is *gestures around at everything*." If you have folks on your team that are rapidly able to switch between expectations, maybe highlight what lets them do that.

FWIW: some level of interchangeability is a good thing and prevents your team from having a single important person win the lottery and move on and leaving you high and dry, but the answer to this is not 'magically everyone's good at everything', it's a process involving cross training and having specific domains be covered by multiple people. It's a team problem, not an individual one.

2. This whole 'have a direct, now deal with it' is pretty lovely and I'd just be blunt with your manager about that. A first time manager should not be generally getting someone who needs to be managed out or has large improvements to make, that's basically asking for an HR nightmare, not to mention a burned out new manager. IMO you did exactly the right thing here, and this is a good experience in how a good manager can do more than simply manage down and gently caress over people. However, your manager needs to be doing the same for you, and it sounds like that's not the case.

3. There's a lot here's that falls into 'there's a buzzword train we just got hit by' in regards to generative AI and I don't have any good answers for you there. Management is suddenly going to be very interested in something they are absolutely lacking in fundamental knowledge about, and are getting fed massive amounts of PR bullshit from marketing at companies frantic to catch the wave. This is yet another example where your team should be having reasonable discussions about reasonableness and effectiveness.

I've had luck very bluntly asking management before questions along the lines of "So our team doesn't think this is feasible to do X in Y time, why do you think it is?" Getting into a sort discussion of first principles can sometimes help drag up what is actually the disagreement, instead of arguing about second-order issues. For example, if your boss wants you to turn around a new solution in 4 months and thinks that basic setup should take 1 week but actually takes 3 months, you might both not realize that's the actual problem if you're stuck on the overall timeline.

Sometimes the answer is 'well leadership says it needs to be done in 4 months' and then I mostly shift it to a discussion of 'Alright, we could do that in 4 months if X feature and Y feature aren't included, or if Other Project Z is deprioritized and the folks working on it can work on this instead', but there's also a time to just say 'There's no way we can deliver that in this timeline; leadership can want what they want, but it's not feasible and I'm not signing off on that timeline, but we'll do our best.' A lot of this is org dependent, but I did a lot of work in a space where we had constantly shifting leadership priorities and luckily the 'Alright we'll focus on X, what do we deprioritize instead' was a pretty good line of inquiry, because most of the time dumb requests from last month were no longer important.

4. If you want to pick a single fight to really have, it's around requirements gathering and being clear on expectations. "This should sound more colloquial" is not a requirement; you're never going to get the c suite to sit down and open tickets, but at the bare minimum you can take those and scope them yourself into requirements and get buyoff from your manager and maybe skiplevel first, then move forward. If you exist in a state of trying to read tea leaves from c suites all the time you're never going to escape this nightmare cycle. Once you have it down to actual requirements, you can then have discussions about delivery dates/etc in a more structured, "delivery-oriented" way.

One trick on that is to frame all your conversations in terms of doing your best to meet these delivery targets/etc. "In order to meet deadline X, we need to priority X over Y" / etc. Figure out the language of your management structure and use that against them whenever possible.


Unfortunately though, none of this advice might be helpful; as it requires management to listen. But ultimately if they don't listen, it won't produce the results they want, it will just produce burnout and loss of productivity and failure to meet deadlines, and finally attrition (see the Dead Sea analogy that's popped up in this thread recently). They might not know it, but that's the reality and countless businesses have hosed around in this exact same way and found out.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

jemand posted:

Thanks so much. I'm going to pull some of the questions out & answer in a bit of a different order, since it might help organize themes better.

How do people actually do this?? "Hey boss, ur doing a bad job?" Even dressed up a lot, that isn't something I'm comfortable with. "Hey boss, we might appreciate more clarity here" -- I do this type of thing, and I do usually get a response where he tries, he's just pretty bad at saying anything substantive or useful at all.

Landing messages like this isn't easy, and it takes some getting used to, especially if you're used to the idea that your manager just demands things of you.

For example though, let's talk about delivery deadlines/etc. "Hey boss, I'm concerned that our delivery deadlines aren't realistic and that we're going to run into problems once we start missing them." is a reasonable way to broach the topic without calling him an rear end in a top hat or something.

jemand posted:

But something backward facing like "hey dude, what you did to me as a brand new manager was super uncool" -- what's he supposed to do with that?


So really, the right time to push back would have been when he started dumping his concerns about your direct report onto you. "It sounds like you have a lot of pretty big concerns about this person, I'm worried that's not a very good fit for my first management position because I don't have a lot of experience in dealing with those sorts of issues, and I don't want to fail to support this person in improving." is a kind of generic example that hits on the major points.

jemand posted:

Even trying to spin that into a more forward looking statement, I don't think he's super clued into, at all, the like, emotional "morale assessment" type of thing managers are supposed to do. Comments I make to the point of "I think our team needs more team-building time & room to be people" results in him taking 20 seconds at the beginning of staff meetings to ask how our weekend was, not listen to the answer, & launch into some product detail nobody on the team has the context for. The weekly 30 minute "coffee chat" meetings we coordinated ourselves to just chill as humans, he'll come on, engage for maybe 2 minutes on whatever topic we had, then hard swerve into some latest AI hype or ask someone to give an impromptu project status update for everyone to "swarm" onto & "help."

For team allocations: his preferred methodology suggested way back when he first started managing us (2.5 years ago) was flipping coins. At the time, I suggested some more strategic reasons he might wish to consider but was extremely careful not to let him offload his sense of responsibility for owning the outcome of allocation choice to me, but at least he hasn't offloaded it to chance since then either (or at least, hasn't said so). I've contributed occasional ideas on strategy as it relates to people assignments since, & sometimes he hears some of it, but I don't think he really gets the principles involved here, that individuals have unique experience, skills, & career desires to balance. Instead I've started indirectly helping some of the colleagues that get hit hardest by this -- encouraging them to be extra clear with the product team on expectations & then following up after planning sessions with our senior product leaders.

From a general performance standpoint, I basically consider my manager a paper weather-vane. He'll push basically whatever the last thing he heard was, but there's not really any SUBSTANCE for me to push on if I try to manage up, he'd either crumple fold or just get mad at me (or misunderstand entirely). Also: he doesn't have the greatest reputation in the org at large and has basically zero political capital, so this is also a frustrating position for me. My skip level is a rising star in the org, & being on his team is good for my career, but I do have my concerns about our larger strategic direction and also wondering exactly why he's left my rather poorly performing manager in place for so long.

So this just gets into 'I have a manager who isn't very good at people management', to be blunt, and that's not a fun place to be in, and honestly might be in 'reach out to Ask A Manager' territory. It sounds like you're making some decent attempts at working around him, but I think one key point is that it's not a bad thing for your manager to know you expect more out of them. There might not be a lot of solid things you can do to fix that.

If possible in your company's culture, I recommend getting semi-regular 1:1s with your skip level (every two months or so is probably fine, but even a few ad-hoc ones would be good). This is tricky, since you don't want to do an end-run around your boss because that doesn't look good, but one thing you can do is mention general issues your team is having without blaming anyone.

This is also an opportunity for you to ask them questions like 'Can you let me know more about why we're doing X' - their perspective on it might be really interesting or illuminating, and it wouldn't surprise me if your manager isn't disseminating that information well.

jemand posted:

There are a few of us who produce pretty well after sudden switches. One such colleague I'm really worried for, since the methodology they use is to just work like 80 hr weeks and they are appearing more and more overwhelmed recently. And I actually have been quite good at it myself, but mostly because my focus has been identifying the specific problem first, then working back from that to whatever tools are needed. Now all the energy in the room is in having GenAI as the solution in hand and trying to shop it around for whatever problems it might fit for. The "specific problem" now basically appears to be "empire building by executives during an active hype cycle" -- and this isn't really the type of problem my skills are best matched for.

Any business process that revolves around people working regular 80 hour weeks is already a failure waiting to happen. I assume you are all salaried, so yeah, there's gonna be crunch times/etc around major events where people have to put in extra time in most companies, but you're just robbing from yourself when you work hours like that, so any time you start doing it regularly it's a surefire sign of failures starting to come down the pipe. This is absolutely something where you should be vocal about it, because surprise surprise the consequences are a lot of stuff you've been talking about, like people getting overwhelmed and burned out and ineffective.

I don't have any good answers for surviving the hype train though, good luck with that.

jemand posted:

I don't see much org interest here. A lot of the hype is actually not coming from external consultants, but people on our team who have fully bought in. Example: someone recently was promoted up from not-a-DS title to a senior DS title higher than my manager's on the strength of how he slings demo poo poo out the door fastest & doesn't worry too much about any specific measures of value or requirements. His favorite saying is "we're building the plane in the air here!" and is basically allergic to set requirements that touch on any sort of end-use specificity. My manager, bless his heart, is actually fighting the good fight here and has been doing what basically feels like rearguard action to get some seriousness on requirements here. But for reasons described above, my manager is just generally ineffective and marginalized, probably because the same sorts of skills lacks that drive his poor managerial performance also restricts his ability to influence the org generally as well.

Basically every single book about managing software development workflows nails this point home in one form or another; you'd be hard pressed to find any written resource that doesn't list requirements gathering and solidifying as important.

One thing you can do on this, is look backwards and start pulling together examples of where this has cost your company time and money. For example, I wasted a month on a project on my current team because my lead was being handwavy about the requirements and I didn't have enough comfort to push back on it yet. We ended up having to drop the feature entirely once we realized that his expectations were wildly different than the two sentence blurb in the task, and I wasted a month figuring that out - and now I use that experience as a direct example for why we need to be clearer on requirements.

Other places to find this sort of waste would be projects that never get delivered, or have massive changes in scope or scale. You can pretty quickly start assigning actual cash numbers to that, too - or at least engineering hours, which starts talking the language of management.

One note: Be careful not to mistake 'we didn't know X at all and it surprised us' with a lack of requirements. Sometimes stuff will surprise you and you'll have to pivot, which is why your requirements can't ever be absolutely set in stone, but you do need to have some basic level of 'the person working on this will output something that the requestor expects'.

Extra note: This also sometimes requires senior people to be able to identify and call out bullshit like the demo-slinger. "We're writing code that's going to take us 2-3x as long to expand or improve on later" is the sort of thing managers should be taking seriously, unless you're specifically writing proof of concept or demo stuff. Nothing wrong with writing lovely demos/POCs, to be clear: management just have to understand there's a tradeoff.

jemand posted:

Our larger enterprise is in general extremely conservative and highly risk-averse, and I keep hoping that we'll hit the downswing of the hype cycle and have some cooling action come from areas that are increasingly getting annoyed at the current empire-building. Then we'll get to a more sensible steady state, where we can get back to building specific stuff for a specific business context that produces a specific piece of value.

I'm definitely worried about burnout & attrition, I'm a lot less worried about "loss of productivity and failure to meet deadlines" because, if it doesn't matter at all WHAT you ship, just ship any random thing by date and you hit those metrics.

I guarantee that somewhere your management probably cares about loss of productivity and failure to meet deadlines, and I also guarantee that most of them don't give a poo poo about burnout until you start talking about it in terms of productivity and failure to meet deadlines. You can sometimes make an emotional appeal when something sucks hard enough, but the cold hard truth of business is that if you can't represent a problem in the form of cost savings or efficiency gains or ability to deliver X thing, you have a huge uphill battle to getting those changes made.

Falcon2001 fucked around with this message at 01:19 on Jun 27, 2023

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
Ah, it sounds like I might have the wrong idea then. I haven't worked closely with a data science team so ill trust that you're right on all that.

Are the "users" implementing your products internal or external to your company?

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
I'm seriously considering trying somewhere much smaller next time, if only for the change of pace from a decade and a half at big tech. Not a startup or tiny shop, but something smaller than 'the largest engineering company on the planet' might be nice.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

downout posted:

I feel like I've been promoted because I learn how to get poo poo done in a company. Every company has bureaucracy; learning to navigate it is valuable.

Fortunately for me, I love doing this bs.

I do try to help the engineers who want to keep coding to do that. Attempting to address repeated blockers, yell at mgmt that they need to provide true IC career paths, etc.

I don't love it, but this has also been very useful to me; learning how to read the tea leaves and figure out how to get poo poo done is a very useful skill.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

csammis posted:

Following on with not having had the best luck navigating weird situations lately, I had a really hosed up interaction with my direct manager today in which:

  • i forwarded him some positive feedback about myself that I'd received from my peers. I've done this before, no big whoop, just building a case for a good EOY review.
  • he called me into his office and said forwarding him positive feedback wasn't going to offset other things that were wrong with my performance
  • me: uh...what are you talking about?
  • he told me that he had all the positive feedback about me that he needed and instead I needed to tell him when I'd done something wrong
  • i said that I don't hide things from him, and if I'd done something wrong that he knew about and I didn't then he needed to tell me so I could course correct
  • he insisted that no, I should be the one to tell him first and then he would confirm

this went back and forth a few rounds before he abruptly dismissed me from his office and I think was starting to have an emotional breakdown :psyduck: In four years reporting to this guy (and like eighteen years reporting to lots of other people for that matter) I have never seen this sort of thing and am...at a loss for words. I genuinely have no idea what the gently caress just happened and have no idea how to proceed.

Is everybody's leadership just going totally insane lately?


edit: my :tinfoil: suspicion is that he was told to get rid of me but can't find a reason to put me on a pip, and my company "doesn't do layoffs," so he's stuck. But that makes no rational sense at all because I work in Kansas and no one has ever needed a reason to fire anybody in this state.

Honestly I wonder if the dude was having a mental breakdown or something, that's bizarre all over.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
poo poo like csammis post is why I'll never be a manager. I would probably just quit if I was ever asked to unjustly fabricate a reason to fire anyone.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

cum jabbar posted:

It shouldn't be necessary to make poo poo up. If the manager has any kind of performance indicators, that will point to who to lay off and provide the paper trail at the same time

The point is that sometimes you're asked to poo poo can people to make budget work, in those cases what do you do if your team is solid?

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

wins32767 posted:

It sucks, but you figure out who you can best live without. If the company is losing money, eventually nobody has a job

You're talking about layoffs though, which don't require a pip or any faking of data. I'm talking about when companies basically say "you need to find a way to fire someone with cause"

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

Pollyanna posted:

Is there such a thing as a “right” current and a “wrong” fish, or vice versa?

Adding onto what others have said:

There's a limited amount any individual can do to affect an organization's culture, and so you do have to do some soul searching to decide 'am I willing to put up with this? Will I change or can I change things?'

Sometimes the company practices aren't as bad as you think, and maybe you're overblowing it; other times it's a dumpster fire and you'll never be able to fix it. Other times, you might be able to be a force for good and help things improve; I'm finding myself (hopefully) in that last position. I'm in a team where higher level folks are very vocal about priorities I also think are important, and I'm able to help impact change at my level around those goals, and it works because I'm in sync with those goals. There's higher level goals I don't agree with, but I've made my peace with them for now.

Another example: there's a category of devs who are very vocal about 'I just want to write code and not talk to people', and honestly, there's very few places you can do that anywhere that isn't just entirely personal projects. Open source projects are just as full of weird politicking as business, with the added bonus of the tyranny of having no leader and everyone just arguing about everything. Academia is the same and a giant cesspool of it. Working in government means you lose a lot of the dumb parts of business and replace them with bureaucracy and glacial pace.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

sailormoon posted:

Thank you all for the great feedback. So, my next question is... how do I tell my manager + team I'm switching without feeling guilty? I know this is also more of a personal question, but not sure of what the tact is here.

Depends on your relationship with the other person but in general I'd say don't say anything until the ink is dry on your new offer. Especially these days you can't risk saying your leaving too early and having something fall apart.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
I actually really enjoy spending time with my old team doing Q+A about the product I used to own because the new dev is very smart and easy to get along with so we just have periodic one hour meetings where we dive through code. It's fun.

Now the reason we have to do that is because it was an untested, undocumented nightmare. :D

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
I try and settle stuff out every day to some level of 'stoppable' and then update whatever task/etc I'm using to track the activity; I keep a work journal but it's more to just be like 'what the gently caress did I do last week' and less 'what should I be doing tomorrow'.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
Another option is just to look at maybe working at places that wouldn't pay as much but give you more personal investment and interest; that's a lot of question marks there but still, it's something I want to try doing for my next gig unless I get seriously caught up in some cool stuff here.

A long time ago a friend of mine got an IT job at Johns Hopkins and when I asked him why, he said it was because his girlfriend of 10 years had died of cancer and so he gets to show up every day and help support people trying to fix that, and it gave him an immense sense of satisfaction. Dunno if that lasts forever, but it might be nice to have my company meetings consist of more than the JP Morgan Chase CEO crowing about how much loving money they're going to save this year.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
FWIW: I also generally recommend folks just in general talk to a therapist semi-regularly. They're not going to be able to prescribe drugs/etc, but talk therapy has absolutely been a huge thing for me on a bunch of levels. You gotta find someone you click with, but I've been in therapy for the last 8 years or so and the folks in this thread should be able to afford it for the most part. It's not just for like 'I have severe trauma to deal with' but a lot of just daily burnout stuff is useful to talk through.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

prom candy posted:

This is good advice. I just talk to mine a few times a year now but during covid when my anxiety was really bad talk therapy helped me a lot. I still deal with anxiety but I have better tools for dealing with it now.

Yeah, I can't recommend it enough, because just having a time every week or so to have to focus on your life and talk through things is really valuable in my experience. Sometimes it's helped me work through work problems too; I was having a hard time with my skip level and talking through it helped sort through 'stuff that was unique to my personal trauma that I was being unreasonable about' and 'stuff that was legitimate business concerns'.

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
I attended a lecture one time from a Professor who did research on retirement, and what he found was pretty interesting: There's a solid split of folks who are happy to just chillax in retirement and take it nice and easy, sit on their porch, and enjoy their lives vs folks who need to have a project or a 'job', and it's not necessarily tied to your personality in your career either. Some classic TypeA folks just hit retirement and BAM, vacations and taking it easy, other folks that never were driven suddenly find themselves having to have something to fill their time.

A lot of folks he interviewed called themselves retired, despite working 40 hours a week at some job or another. One guy in particular was a construction supervisor. The professor asked him 'If you work 50 hours a week, why do you think of yourself as retired?" and his answer was "Because if I wanted to, I could just stop showing up tomorrow!"

Definitely agreeing with folks who say to talk to a therapist because this is some CLASSIC therapy discussion and I guarantee there's therapists in your general area that have either dealt with this sort of thing or specialize in it and it can do you a lot of good to reflect in a structured way.

But also on a higher level note: The goal of retirement should be to do what you want to do, not to just stop working. If you want to keep working, then you can do it on your terms. I'll probably work until I can't anymore, but you bet your rear end when I retire it won't be for a FAANG.

Edit: Honestly the meme that your retirement should always be a wholly self-centered endeavor about just vacationing or sitting at home and not being part of society is kind of deeply hosed up and says a lot about how hosed up our relationship with labor is in the modern era. Not to say that isn't a wholly viable option, but I don't see anything wrong with continuing to be part of improving the world after retirement, as long as you can do it on your terms and you don't have to be forced into wage slavery until you die.

Falcon2001 fucked around with this message at 23:57 on Jul 7, 2023

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug
The reason I couldn't ever be a manager was something I ran into when I was a team lead (sort of) at a previous gig. I had two guys working for me.

The first guy, John (fake name obvs) was the sort of dude to show up 10 minutes early, friendly, easy to work with, and hardworking. He also absolutely did not get it. I've only like, flipped out and yelled at someone at work a few times in my career, and one of those times was at 6am when John called the head architect for our product (who was oncall that day) to let him know that we were having problems in Region X, when Region Y directly next to X and containing many major dependencies for X was currently on fire. I apologized later, to be clear: it was a super lovely move on my part. But yeah, this was the sort of dude who you'd tell what to do, and then you'd have to walk him through it each and every time. I'd fight to the death to let that guy keep his job though because despite all that, he was a fantastic coworker, and if you kept him on lower level stuff he was great and could do a good chunk of the overall work; he just couldn't work alone.

The second guy, Jake? New to the industry, no real role experience, and he absolutely loving nailed it. You could tell him what you wanted done and thirty minutes later he'd be back with the output. He just got it.

Being a manager means that it would be my job to make John more productive and to be rewarded for Jake being a good employee, but I had no input on the second and no idea how to improve the first.

Adbot
ADBOT LOVES YOU

Falcon2001
Oct 10, 2004

Eat your hamburgers, Apollo.
Pillbug

Pollyanna posted:

I mean, this also depends heavily on the work to be done itself, plus the organization you work for and the development support you get. You can be a perfectly good engineer and still have trouble delivering in a particular domain if you happen to work in a black hole of sanity and brain cells. Sometimes something sucks to work on and doesn’t make sense, and sometimes you just don’t gel with the subject. It’s a stone soup like everything else.

Yeah, I want to be clear that I'm trying to not make a...human value judgment there. That dude was fantastic. I loved having him around. He is no less of a valuable human being than Jake was; but in terms of the altar of capitalism, there was a value discrepancy, and managers are expected to help fix those things. I know because when I left the team a guy I know ended up being a manager there and got three other dudes, all less effective than John, to manage, and he hated it.

Edit: the other part of it is that being a manager means that your success is based on other people's work, and as someone with pretty intense imposter syndrome and work anxiety already sometimes, boy that sounds like just ulcers waiting to happen.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply