|
Rocko Bonaparte posted:...what the hell are they looking for instead? Typing code real fast?
|
#
?
Apr 16, 2024 18:15
|
|
|
|
| # ? Apr 30, 2024 05:48 |
|
|
Yeah, we're still hiring but we absolutely need to be able to say "we want to hire this person because they have this specific exact skill we need". Hires just for the sake of increasing headcount don't get approved regardless of how good we think the person is.
|
|
#
?
Apr 16, 2024 20:24
|
|
|
Achmed Jones posted:always be interviewing is great advice, but it's kind of like 'have a great github portfolio' in that it's no big deal at all to do when you have no responsibilities, but gets really obnoxious when other people have legitimate claims on your time. it's probably much more sustainable to hit the circuit on a cadence (say, yearly). of course i don't do that either, but it at least isn't a non-starter Just like, send your resume to 5 places a week through your preferred job site, and start accepting calls from recruiters. If you can't even get a recruiter call in like, 2 weeks, you already have a leading indicator that your resume is grossly out of date and needs an overhaul. Do one call a week on your lunch break. Scheduling calls with recruiters is like a 46 second task I've got a little kid, wife who travels all the time and other life stuff and I don't find this challenging to juggle at all and I'm wildly disorganized
|
|
#
?
Apr 16, 2024 20:26
|
|
|
Rocko Bonaparte posted:...what the hell are they looking for instead? Typing code real fast? The hiring manager is hearing "please diagnose your problems and point me at them," and finding the burden of Actually Managing being too great to bear, stop the process rather than have a moment of reflection.
|
|
#
?
Apr 16, 2024 21:48
|
|
|
How do you deal with the guilt of a horrible engineer who is way over leveled (shouldn't even be above Junior) that you know needs to go? I've been having to provide examples of how poor they are, and working with my manager to toss them soft balls they still can't hit, and it's just a bad feeling overall. Extremely unfair to the actual performers on my team, and myself given the amount of extra time I have to spend with them, but a bad feeling nonetheless.
|
|
#
?
Apr 16, 2024 21:49
|
|
|
I want to loiter on what Vulture Culture wrote a little bit more:Vulture Culture posted:"I've done a lot of tech jobs and I'm good at most of them, so my bosses always point me at their biggest problem. I honestly do not care if that's staff engineering, managing a struggling team, or building something important that's missing, as long as I'm doing it at a good company" I get that there's still a major trend towards hiring specialists because my rear end has been beat by that repeatedly, but that introduction sounds more like a senior engineer pitch, and I would expect that to soften. I'm assuming the interviews are for positions with some level of seniority where any of those capacities would be very important. So I'm disappointed in the process if the reaction to this is either/both of two things: 1. "We don't want a senior person with those capabilities, we want a senior person that's really just an individual contributor that just crushes it with [insert technical domain/skill here]." 2. "We don't want a generalized senior person, we want one that does just one of those senior skills things really well." Both notions are pretty horrific to me for different reasons.
|
|
#
?
Apr 16, 2024 22:08
|
|
|
They're looking to hire someone to fit into a particular slot on a particular team, and the easier you make their job to do that, the more they'll like you.
|
|
#
?
Apr 16, 2024 22:23
|
|
|
Breadth is very important for both tech leads and managers but depth really matters if you want to stay on the senior IC track.
|
|
#
?
Apr 16, 2024 23:37
|
|
|
Good Will Hrunting posted:How do you deal with the guilt of a horrible engineer who is way over leveled (shouldn't even be above Junior) that you know needs to go? I've been having to provide examples of how poor they are, and working with my manager to toss them soft balls they still can't hit, and it's just a bad feeling overall. Extremely unfair to the actual performers on my team, and myself given the amount of extra time I have to spend with them, but a bad feeling nonetheless. Been there, done that and the only thing that worked was not spending time on them or even thinking about them. Be friendly and available to them, but make it understood with leaders that you're directing your energy other directions because the ROI isn't there.
|
|
#
?
Apr 17, 2024 00:44
|
|
|
ultrafilter posted:Breadth is very important for both tech leads and managers but depth really matters if you want to stay on the senior IC track. This is where I am right now: even though we don't distinguish, from an HR perspective, the difference between the "senior IC track" from the "tech lead" track, I'm wondering down which road I should go, because I feel like I should pick a lane. Understanding the big picture and explaining how things work are things I'm really good at naturally and so you'd think I pick the tech lead track due to the extrinsic validation, but I get a lot of intrinsic validation from that deep knowledge (plus I'd imagine the job security is a lot better if you have depth in how the company's primary revenue center works).
|
|
#
?
Apr 17, 2024 00:46
|
|
|
Good Will Hrunting posted:How do you deal with the guilt of a horrible engineer who is way over leveled (shouldn't even be above Junior) that you know needs to go? I've been having to provide examples of how poor they are, and working with my manager to toss them soft balls they still can't hit, and it's just a bad feeling overall. Extremely unfair to the actual performers on my team, and myself given the amount of extra time I have to spend with them, but a bad feeling nonetheless. Good luck, its never fun. Is this someone who reports to you or do you both report to the same person? In the end, the way to get rid of someone is to talk to their manager/HR and get them on a PIP. Do you have any thoughts on how this happened? Are they good with people just not engineering or is their specialty outside their current area? One of my senior engineers is great once he can really settle into a problem, but ask him to do something quick and its a real clown show. I also think that as engineers get older, some stop looking for new ways to do things and just end up falling way behind. I say this as an oldo myself.
|
|
#
?
Apr 17, 2024 01:48
|
|
|
luchadornado posted:Been there, done that and the only thing that worked was not spending time on them or even thinking about them. Be friendly and available to them, but make it understood with leaders that you're directing your energy other directions because the ROI isn't there. This is what I've been doing. It helps if you can steer time-insensitive tasks their way. Every few weeks I'll get tired of them sandbagging, and go unblock them/take away their current excuse, but it's getting easier to not do that the longer I practice it. The hell of it is that my useless engineer isn't even useless, he's just doing very junior level work. He's fine and even almost reliable if a bit slow while working on small tasks. I.e. a junior engineer. The frustrating thing is that they're getting paid more than people who are way more dependable then them. But that's not my problem, I'm not a people manager. I explained to their manager what was happening and do my best not to let it bother me while advocating for the other engineers. FWIW, their people manager didn't believe me until I let useless fail really visibly. Fortunately, since then they've been on board with the "no important tasks for useless" plan. Plenty of defects for them to work on anyways. *** Speaking of, thanks for all the advice on not stressing. I'm trying to take it to heart and focus on just the defects that are most important for next sprint (I mostly do planning work so I need to stay at least a sprint ahead). I guess I've been lucky in that all the places I liked working at would spend somewhere between a third and half of their months in pure bug fixing mode. The places I didn't like (mostly from my consulting years) were so on fire that their defect list wasn't relevant because they were always in emergency mode. So I'm not used to this in between state where we have a big defect backlog but also aren't so on fire that I can't pay attention to it.
|
|
#
?
Apr 17, 2024 01:50
|
|
|
just lol at the notion that this guy being overpaid is unfair to the other workers
|
|
#
?
Apr 17, 2024 02:26
|
|
|
thotsky posted:just lol at the notion that this guy being overpaid is unfair to the other workers Sounds like this guy is living the dream I see no problem here
|
|
#
?
Apr 17, 2024 02:36
|
|
|
Good Will Hrunting posted:How do you deal with the guilt of a horrible engineer who is way over leveled (shouldn't even be above Junior) that you know needs to go? I've been having to provide examples of how poor they are, and working with my manager to toss them soft balls they still can't hit, and it's just a bad feeling overall. Extremely unfair to the actual performers on my team, and myself given the amount of extra time I have to spend with them, but a bad feeling nonetheless. During times of plenty, I would try to go to another team, steer them to another team, or just otherwise avoid them and let my manager know that I'm avoiding them (nicely) because working with those types is an exhausting black hole. Managers usually use layoffs to dump these folks off from what I've seen, even if their position loss doesn't fit whatever narrative/reasoning is being given. I've known managers to see them as padding when the writing is on the wall for headcount reductions in the near future. If you're still stuck with them, it's on your manager. I've found that as long as you've made it clear to management that they're a drag, the day-to-day for your sanity is a mix of creating space for yourself away from them and steering them towards low effort time-suck tasks and meetings. Eventually they'll get promoted to management or they'll get fired/laid off. It may take years though I wouldn't really frame it as what is fair and what isn't, that doesn't work in corporate life. Just survive and try to keep yourself from burning out. Feeling righteous about other people being employed or not is a short path to burn out and being a raging dick to be around biceps crimes fucked around with this message at 03:32 on Apr 17, 2024 |
|
#
?
Apr 17, 2024 03:28
|
|
|
I'm not a manager but a tech lead for about 5-6 engineers and this person is dragging down velocity, and morale, immensely. They just aren't very good at anything. Poor communicator, which is probably the worst part. Also not inquisitive and don't know how to explore the code base or try things for themselves, coupled with really zero technical ability at all (code looks like a first semester college project). To boot, they put up a PR that had a feature breaking bug displaying a total lack of baseline understanding for one of my team's biggest features that this engineer was working on for months, which lead me to wonder if they got handheld in the earlier PRs and the other eng(s) just never brought that up to my manager? The ROI is drastically negative for the team and especially a negative multiplier on mine and the other most senior engineer's mental health. My manager suggested that he has had eyes on performance for 3 quarters now, but he wants to "look closer on a week to week basis". There isn't much I can do besides oblige his asks to look at her PRs and tickets, but he's so clueless as to our technical side of things there's now overhead of me explaining poo poo to him. The worst part of this is that I feel zero real support or help from him, just hand wavy bullshit, and timelines are slipping a bit. For example, I pointed out I had given this engineer a ticket with step by step instructions and they still couldn't even spend a few hours exploring before pinging another engineer on the team, after the last assignment that likely should have taken a week took 4. My manager's reply was just "Yikes!". Countless examples of less than poor performance and negative feedback across the board but zero change. And of course two of our engineers a level below this person were passed up for promo! Good Will Hrunting fucked around with this message at 04:20 on Apr 17, 2024 |
|
#
?
Apr 17, 2024 04:13
|
|
|
Hadlock posted:Just like, send your resume to 5 places a week through your preferred job site, and start accepting calls from recruiters. If you can't even get a recruiter call in like, 2 weeks, you already have a leading indicator that your resume is grossly out of date and needs an overhaul. Do one call a week on your lunch break. Scheduling calls with recruiters is like a 46 second task When people say 'always be interviewing'...every tech job I've ever had, an interview is a *full loop* and takes an entire workday. Is this not normal? because I absolutely could not burn a day every few weeks on an interview. Do you guys just mean like 'try and get an offer for a loop' or am I just so BigTech that I have a wrong assumption about what 'interviewing' means?
|
|
#
?
Apr 17, 2024 05:01
|
|
|
Good Will Hrunting posted:I'm not a manager but a tech lead for about 5-6 engineers and this person is dragging down velocity, and morale, immensely. They just aren't very good at anything. Poor communicator, which is probably the worst part. Also not inquisitive and don't know how to explore the code base or try things for themselves, coupled with really zero technical ability at all (code looks like a first semester college project). To boot, they put up a PR that had a feature breaking bug displaying a total lack of baseline understanding for one of my team's biggest features that this engineer was working on for months, which lead me to wonder if they got handheld in the earlier PRs and the other eng(s) just never brought that up to my manager? Being a tech lead without the ability to fire people on your team sucks rear end. I've had this problem several times and I have tried four different strategies. 1. Trying to mentor dev into something useful. 2. Giving the dev my honest feedback about his work capabilities and general worth as a human being. 3. Ignoring the dev, pretending they are not on the team, and giving them no real tasks or work. 4. Get a better job. 1 is the by-the-book strategy. It takes a lot of effort. Sometimes it even works - you can mentor someone over the span of weeks or months into a decent developer. Then years later you run into a company holiday party and they remark about how fat you've gotten. I can't recommend this strategy. 2 doesn't work and gets you a visit with HR. It turns out people don't appreciate when you speculate about whether their performance is caused by a brain injury or drug addiction to their face. 3 takes a long time and is very passive aggressive. With 4, you get paid more money and the problem goes away.
|
|
#
?
Apr 17, 2024 05:13
|
|
|
Bruegels Fuckbooks posted:Being a tech lead without the ability to fire people on your team sucks rear end. I've had this problem several times and I have tried four different strategies. Realistically the right answer is 5 - Make it that person's manager's problem. This guy's loving up your time, their boss is responsible for dealing with it. That comes back to you a bit as a tech lead, but if you can't fire them, you can make it the problem of the person who can. biceps crimes posted:Your useless/bad coworker problem is actually a manager problem. They either need to manage the person out, or they'll face various issues with morale, burn out and the team fracturing into various back channels. All you can really do is provide feedback. If that doesn't work, you have to either change teams, change jobs, or figure out a way to survive the dysfunction. This basically. Falcon2001 fucked around with this message at 05:42 on Apr 17, 2024 |
|
#
?
Apr 17, 2024 05:33
|
|
|
Good Will Hrunting posted:The worst part of this is that I feel zero real support or help from him, just hand wavy bullshit, and timelines are slipping a bit. For example, I pointed out I had given this engineer a ticket with step by step instructions and they still couldn't even spend a few hours exploring before pinging another engineer on the team, after the last assignment that likely should have taken a week took 4. My manager's reply was just "Yikes!". Countless examples of less than poor performance and negative feedback across the board but zero change. Your useless/bad coworker problem is actually a manager problem. They either need to manage the person out, or they'll face various issues with morale, burn out and the team fracturing into various back channels. All you can really do is provide feedback. If that doesn't work, you have to either change teams, change jobs, or figure out a way to survive the dysfunction.
|
|
#
?
Apr 17, 2024 05:40
|
|
|
Falcon2001 posted:When people say 'always be interviewing'...every tech job I've ever had, an interview is a *full loop* and takes an entire workday. Is this not normal? because I absolutely could not burn a day every few weeks on an interview.
|
|
#
?
Apr 17, 2024 07:18
|
|
|
I was waiting to hear that this poor performing developer counters that they "didn't have enough information" when confronted about it. I could score my bingo card. I also have a another box for "says nothing or mumbles when you sit down to pair program with them and they can't even start writing the syntax for a loop." I also agree it is the manager's problem now. Actually, the manager's problem is now: 1. That underperforming developer. 2. The giant vacuum that's sucking everybody into the person sucking at their work. 3. Everybody burning out from it. That manager should be less worried about the one person that might not be able to get another developer job and should be worrying about the ones who can instead.
|
|
#
?
Apr 17, 2024 07:28
|
|
|
Falcon2001 posted:When people say 'always be interviewing'...every tech job I've ever had, an interview is a *full loop* and takes an entire workday. Is this not normal? because I absolutely could not burn a day every few weeks on an interview. Do you guys just mean like 'try and get an offer for a loop' or am I just so BigTech that I have a wrong assumption about what 'interviewing' means? interviewing does not mean final interview. you should probably be interviewing more if your view has skewed that far. Artemis J Brassnuts posted:Yeah, same question here. Lots of places I’ve interviewed had multi-hour or even multi-day “take home” programming tests. if you dont think the place is worth the time for a take home, you can always reject them. you should be able to get enough information to know whether you want to continue by the time you get a take home. bunch of people itt thinking interviews are just for the company with the opening. it's a lot easier to get enough of the signal you care about as a candidate. if you're not, figure out what you're doing wrong. e: consider interviewing as an opportunity to select another team or project to work on, and how impactful the team or project you're on could be to your career or personal health leper khan fucked around with this message at 13:09 on Apr 17, 2024 |
|
#
?
Apr 17, 2024 13:05
|
|
|
biceps crimes posted:Your useless/bad coworker problem is actually a manager problem. They either need to manage the person out, or they'll face various issues with morale, burn out and the team fracturing into various back channels. All you can really do is provide feedback. If that doesn't work, you have to either change teams, change jobs, or figure out a way to survive the dysfunction. It is absolutely a bad manager problem. All of these things you (and player above) mentioned are right. The biggest reason it's frustrating to us is that our team is very much a harder team in that we own like 4 projects and it requires independence to ramp up and understand them. Our sister team had 1 project with so much low hanging fruit for a bad dev to contribute to slowly. My manager is just too spiteful to move this engineer back there.
|
|
#
?
Apr 17, 2024 15:29
|
|
|
Hadlock posted:Just like, send your resume to 5 places a week through your preferred job site, and start accepting calls from recruiters. If you can't even get a recruiter call in like, 2 weeks, you already have a leading indicator that your resume is grossly out of date and needs an overhaul. Do one call a week on your lunch break. Scheduling calls with recruiters is like a 46 second task oh wow thank you, so that's how to take phone calls and send emails. i'm talking about the actual interviews, dude.
|
|
#
?
Apr 17, 2024 16:29
|
|
|
you can't do an all-day every month, but every quarter or twice a year or so is quite realistic
|
|
#
?
Apr 17, 2024 16:34
|
|
|
re: being a generalist, that's never been the actual move to do really well on interviews. it's been _good enough_ when the hiring bar is low, but nobody actually _wants_ to hire somebody they have to train up to fix their problems. they are _willing to hire a generalist_. they _want_ to hire a specialist in the problem that they have (who, as a non-idiot, can also learn other things just like the generalist). if you can demonstrate that you are already 80% up to speed, you're way ahead of the pack. once you're in a technical leadership position, they are frequently looking for someone to even _tell them_ what the problems are. so the interview becomes not telling how you'd solve problem x, but showing how you can identify and solve problems. you aren't a generalist, you're an expert at leading organizations/teams in such-and-such domain. maybe that's infosec, maybe that's infrastructure, maybe that's deployment pipelines, maybe that's app development, but you gotta have some kind of expertise and "i have one year of experience ten times" isn't impressing anybody. "i can figure out old scripts in whatever language you want" only puts you above people who literally can't do the job. the skills are almost certainly there - get better at the pitch.
|
|
#
?
Apr 17, 2024 16:35
|
|
|
bob dobbs is dead posted:you can't do an all-day every month, but every quarter or twice a year or so is quite realistic agreed, that's why i said the thing about slowing the cadence down (sure i said once a year, but same vibe). i'm still almost certainly not gonna ACTUALLY do it, but that's because i'm lazy, not because it's a real problem to plan for Falcon2001 posted:When people say 'always be interviewing'...every tech job I've ever had, an interview is a *full loop* and takes an entire workday. Is this not normal? because I absolutely could not burn a day every few weeks on an interview. Do you guys just mean like 'try and get an offer for a loop' or am I just so BigTech that I have a wrong assumption about what 'interviewing' means? nah you're right, and you're talkin about the same thing i am. the main thing is, like, i'm getting a couple cold messages a week. i'm pretty confident that if i wanted the interview, i could get one at least half the time. maybe this is hubris talking and they'd all ghost me as soon as the recruiter saw the calendly invite or wtfever, but  Artemis J Brassnuts posted:Yeah, same question here. Lots of places I’ve interviewed had multi-hour or even multi-day “take home” programming tests. i can't see this without complaining about take home assignments. i must complain. im ok with the one hour timed "show us you know how to stdlib" stuff, but the "this should take you three hours, but you have a weekend  " nonsense is the quickest way to make me nope out (unless i really want/need the job ofc, ill fold like origami paper if i have to)
Achmed Jones fucked around with this message at 16:43 on Apr 17, 2024 |
|
#
?
Apr 17, 2024 16:37
|
|
|
leper khan posted:interviewing does not mean final interview. you should probably be interviewing more if your view has skewed that far. Look if I say 'What about X' and your response is 'Well X is actually Y and if you X'd more you'd know that', like...yeah? That's why I'm asking. Our team basically has a call with a recruiter that is just pitching you on the company, a phone screen that is basically 'is it even worth talking to you more', and then a full 1-day loop with 5-6 interviews. I'm at a FAANG, so that probably is different than other smaller tech places, so that's why I'm curious, but my last big tech job also basically had a similar setup. Internally to these big companies you can do what we call 'Informationals', which are basically semi-informal meet and greets with managers, but otherwise I guess you're just talking about going through a lot of...phone screens? Which I guess kind of makes sense. bob dobbs is dead posted:you can't do an all-day every month, but every quarter or twice a year or so is quite realistic Yeah, this doesn't sound insane. I mean, it would be tough for me to manage but a couple times a year feels at least doable, but I guess I didn't think about '2-4x a year' as 'always interviewing'.
|
|
#
?
Apr 17, 2024 16:46
|
|
|
you take one of them 1-hour calls monthly or so, and a full-day quarterly or 2x a year
|
|
#
?
Apr 17, 2024 16:48
|
|
|
Falcon2001 posted:I'm at a FAANG, so that probably is different than other smaller tech places, so that's why I'm curious this is how it has been at every job i've had and every interview i've done. at the minimum it's been a half-day. granted i haven't interviewed in five years at this point so it's possible that the small shops have relaxed their interview practice, but i doubt it. the "nice" thing about it is that it makes getting into a faang much easier when all the non-faangs ape the interview style anyway - might as well take the shot the bad thing of course is that the faangs tend to at least build some non-discrimination stuff like rubrics etc into their practices, where the small shops will take all that stuff out but leave the awful leetcode style bs in, so you get the worst of both worlds
|
|
#
?
Apr 17, 2024 16:49
|
|
|
There's about an 80% overlap between recruiter/hiring manager calls, and the non leetcode portion of loop interviews, in my experience In other news the last week of recruiter contacts were 90% "contract to hire"
|
|
#
?
Apr 17, 2024 20:54
|
|
|
StumblyWumbly posted:
Not just olds, I'm currently seriously hampered by a very junior leader on a team I depend on that failed his way upwards and refuses to accept any radical ideas like "we need to have acceptance criteria" and "you can't change the scope of the ticket when it's in code review" because they didn't need to do this when the company was 5 people so they shouldn't need to when it's 500.
|
|
#
?
Apr 18, 2024 16:38
|
|
|
Ensign Expendable posted:"we need to have acceptance criteria" and "you can't change the scope of the ticket when it's in code review" because they didn't need to do this when the company was 5 people so they shouldn't need to when it's 500. Are you floating those ideas because you're explicitly trying to solve related problems or just because they're "good things" to do? Agreed that it's not an age problem, it's an expert beginner problem. Although you're probably more likely to see it in the olds that have been doing dev for 15+ years and have no idea why you'd ever try new things.
|
|
#
?
Apr 19, 2024 01:07
|
|
|
Yes, it's an annoying and recurring issue where my devs end up spending several hours or sometimes days trying to diagnose a bug in their code that arose because the behaviour of the API endpoint was changed under them even though that ticket was already marked as done. If you're lucky the new changes are mentioned somewhere in a Slack thread but usually they are not documented anywhere at all. To make things worse, the old (now incorrect) behaviour and data models are still in Jira.
|
|
#
?
Apr 19, 2024 05:28
|
|
|
Ensign Expendable posted:Yes, it's an annoying and recurring issue where my devs end up spending several hours or sometimes days trying to diagnose a bug in their code that arose because the behaviour of the API endpoint was changed under them even though that ticket was already marked as done. If you're lucky the new changes are mentioned somewhere in a Slack thread but usually they are not documented anywhere at all. To make things worse, the old (now incorrect) behaviour and data models are still in Jira. One of the points I always make when we discuss this kind of thing in tech strategy meetings is that we can document stuff in all the Confluence articles and Jira tickets we want, but those links will eventually get broken when we migrate to whatever the next thing is. You know what won't change, though? The docstrings and markdown files in the Git repo. The people who own these components 6 months from now probably won't be the same as they are today, and we all know we're gonna get re-org'd eventually, and so we should try to make things easier for those future engineers... because eventually they're just gonna throw all our stuff out and remake it from scratch.
|
|
#
?
Apr 19, 2024 13:19
|
|
|
The markdown files in GitHub are also tremendously out of date and that team is highly siloed because absolutely no value is seen in making your code accessible to anyone else. I don't care if it's Confluence or Jira or a Google doc, as long as the information is kept up to date in some place and everyone knows where that place is, but right now there are 3-4 different places one can potentially find documentation and none have correct or complete information.
|
|
#
?
Apr 19, 2024 14:20
|
|
|
Love Stole the Day posted:You know what won't change, though? The docstrings and markdown files in the Git repo. That’s right. They won’t change after being originally authored and will become increasingly stale, wrong and misleading
|
|
#
?
Apr 19, 2024 15:38
|
|
|
imo if your organization is so
|
|
#
?
Apr 19, 2024 16:00
|
|
|
|
| # ? Apr 30, 2024 05:48 |
|
|
Never understood the "docs become out of date quickly" bullshit. There's a degree of truth to this if you're talking about docing how methods work at a line by line code level or something, but documenting pointing to where some product functionality happens in a feature of the platform, or a service, or whatever? Highly disagree. Wiki style docs for people who are working on complicated things is hugely impactful and if your documentation is structured and scoped properly it can be a tremendous force multiplier in breaking down silos and getting team members involved in areas they don't traditionally work. Do you just expect every single person who wants to work on an area of code to figure the entire thing out themselves without docs on how to run it, e2e test it, entry points to various pieces of functionality, that kinda stuff? This is, of course, company and team dependent. At my last company docs were a lot less useful as everything was pretty isolated microservices which created other issues, but here? Docs are invaluable working on a mega Monolith. You need a culture that supports this though. Good Will Hrunting fucked around with this message at 16:09 on Apr 19, 2024 |
|
#
?
Apr 19, 2024 16:06
|
|