New senior dev at a new company. Bad signs or just how it is?

[-]

kyletraz@reddit

It's definitely frustrating when you're trying to ramp up on complex systems and processes, and the documentation just isn't there – that missed deliverable feels exactly like the consequence of that gap. A strategy I've used in similar situations is to schedule short, recurring 'knowledge transfer' meetings with different team members, even if it's just 15-30 minutes, specifically to walk through a release process or the nuances of an internal tool. Frame it not just as you needing to learn, but as an opportunity for them to offload that tribal knowledge and begin sketching out the documentation that everyone will benefit from. This not only helps you get up to speed but also models the behavior of building shared understanding, which is a key part of senior leadership in an undocumented environment. How do you plan to tackle formalizing some of that tribal knowledge once you've extracted it?

Reply

[-]

Idea-Aggressive@reddit

Did you start writing documentation? If you haven’t, you are no different from the lens you criticise. Stop moaning

Reply

[-]

Izkata@reddit

> I have probably only had a combined 60 minutes of time with him over teams. It sounds like you're looking for 1-on-1 time so you can have a conversation, but not everything needs to be done like this. Sometimes you just need to be pointed in the right direction, a quick single question and single response. So aside from the generic "ask more questions", here's one specific thing: Try getting used to asynchronous questions, put everything together into one message you can send to the other dev, that you can wait for them to get to. It's entirely possible they have a few minutes here or there between meetings or whatever where they can respond, but isn't enough to get on call and actually talk to each other.

Reply

[-]

HiSimpy@reddit

This is a real ops smell, not just "senior ambiguity." Ambiguity is fine; hidden process isn't. If release criteria and tool behavior are tribal, misses are inevitable. The best fix I've seen: document while onboarding and tie each failed handoff to a missing artifact so the same miss cannot repeat.

Reply

[-]

futuresman179@reddit

Sounds about right. Main thing is communication. Are you informing your manager and team of your status, what’s blocking you, etc? Also with some folks a little push is required, just directly invite the person you need to a meeting, most people are more likely to respond to that than a slack message.

Reply

[-]

BobTheBarbarian@reddit

Build the documentation as you go - it’s a huge value add that most will appreciate, will make your job easier, and it will give you a excuses for follow up questions poking once people start to notice

Reply

[-]

Fluffatron_UK@reddit

There's absolutely no excuse not to do this now with access to AI assistants like copilot. This is one job that agents genuinely excel at, turning a boring documentation task into a 5 minutes generate and proof read.

Reply

[-]

joseconsuervo@reddit

I was going to suggest this as well. Help the future hires to struggle less in this position

Reply

[-]

captpiggard@reddit

And if you are sending slack messages: https://nohello.net/en/

Reply

[-]

Educational_Slip3695@reddit

the third line really changes the vibe

Reply

[-]

futuresman179@reddit

Also if you have AI approval at your job this is one thing it excels at. Throw it repos, docs, etc and have it trace processes and explain how systems work.

Reply

[-]

alabianc@reddit

It’s pretty common. It will go a long way to be the guy to document things. It will help the company, helps you learn as you document and it will make you look good too

Reply

[-]

PressureHumble3604@reddit

Of course there are plenty of people gaslighting you into believing is standard and normal, even to the extent of saying that it should be like this as a senior. This is what is wrong with the industry and why it produces more and more codeslop every year. AI could be a lifeboat but I think it will be used as an iceberg

Reply

[-]

biledemon85@reddit

Reading all this is making me so grateful for who i work with. > Yes of course document your changes > If you don't have tests i'm not going to approve the PR > Here's a bunch of helpful documentation and context I have on this exact problem. > Oh i'm sorry the README was out of date, I just merged an update that should make it smooth to onboard > Here's the release process document for this product, follow this and you'll be fine. All of the above is completely normal where I am, but that seems like that's not what it's like in a lot of places :/

Reply

[-]

futuresman179@reddit

Unfortunately we live in a capitalist and individualistic society. This is the exact antithesis to what documentation, onboarding, etc provides. Of course we all wish these things weren’t the case but it is and it’s either sink or swim.

Reply

[-]

PressureHumble3604@reddit

I agree with individualistic but not capitalistic. now capitals make you write documentation and onboarding for ai agents, so they were useful after all.

Reply

[-]

dablya@reddit

Generally, I would argue, as a senior, you should have a good feel for when you need your hand held. This should reduce the risk of you missing the mark on delivering on first few assignments. I consider myself senior, and I have no problem saying “I’m going to need you to hold my hand through this” especially if I get the sense the process is more based on tribal knowledge than docs. I also have no problem saying “I know we went over this last time, but I need you with me on this at least one more time”. I’m comfortable with this because I have experience from the other side and know I see people as more senior when they’re comfortable asking more questions than having them guess and be wrong.

Reply

[-]

WanderingSimpleFish@reddit

Seems standard. I had similar but had the head of HR abruptly leave in my first week. Then the project I was meant to be on was rug pulled. I left after 2 months.

Reply

[-]

severoon@reddit

Senior just means you identify problems and solve them instead of looking to someone who is senior. On point 1, document your onboarding. Be radically transparent on what you learned, when, and how, as well as the negative consequences. Wherever there are bad consequences, there's a problem. Solve it. On the process issue…who cares? No place implemented a textbook dev process (or, at least, shouldn't). Dev processes exist to evaluate efficient communication so everyone has the same dictionary. But if people don't like following a part of the process and there's no drawback to dropping it, then who cares? So look for negative impact, pros and cons. Fix the cons, improve the pros. I think most managers don't value new eng perspective enough. It's your chance to get the outside view of what you're doing well and what you're not, don't let that slip away. Mine it for all it's worth.

Reply

[-]

dudesweetman@reddit

It sounds like they have been dealing with a high workload. This is why they hired you. A good thing to do is writing mardown docs if tribal knowlegde anf make a PR to a docs folder in relevant repos. Be the change you want to happen. This is why you are here.

Reply

[-]

Thin_Mousse4149@reddit

Be the change the company needs. Document things you’re finding and share with the team as you learn stuff. They’ll appreciate it and they’ll probably discover inconsistencies in the way they all think about these processes and procedures. Makes your ignorance a benefit rather than a burden.

Reply

[-]

Dokrzz_@reddit

Yeah I did this at my org, creating documentation and now I run knowledge transfer sessions for new joiners lmao

Reply

[-]

Internal_Pride1853@reddit

This is exactly my experience in my new job. So frustrating and demotivating. I found out the best thing is to schedule a call.

Reply

[-]

akeniscool@reddit

Reality is a mix of both. The more senior you are, the more you are expected to create clarity from ambiguity. Regardless, you have the opportunity to improve both. That is what your new colleagues are waiting for. Don't wait for your coworkers to tell you what you might need to know. Find what you want or need to know, then create a meeting with an agenda. Create the documentation you wished existed. I've always encouraged new team members to create or update stale documentation as they onboard. If you get ignored or deal with pushback, then the problem is more with company culture than senior responsibility.

Reply

[-]

colonel_bob@reddit

> If you get ignored or deal with pushback, then the problem is more with company culture than senior responsibility Thanks for this; I'm 3 months into a new senior role and a lot of the people outside of my immediate team have been downright rude and/or unresponsive to the point that it's impacting my willingness to ask for the context that I need to do my job

Reply

[-]

akeniscool@reddit

If you need it for your job, stay proactive. But make sure you're communicating effectively also. Sometimes what seems like rudeness or unresponsiveness is actually a result of them being uncertain of what you need or what comes next. For example, you text me "Hey let's get lunch!" Cool, uh, when? Now? Next week? Am I supposed to plan this? Why do you want lunch? Is it important? Be clear with your ask, the context, and the priority. "Hey, we haven't had lunch in a while. Thought it'd be nice to catch up just for fun. Are you free tomorrow or Thursday? You pick the place, I'm buying!" Pro tip: find the person you feel is good at communication and collaboration, and ask them how they'd approach what you need. They can help both in general communication tips as well as any nuance with the actual people in your org.

Reply

[-]

colonel_bob@reddit

I'm going to assume you meant well, but the issues I posted about go well beyond basic lunch coordination snafus

Reply

[-]

akeniscool@reddit

It was just an example for a lesson that maybe isn't applicable to you. It's generic help without knowing the specifics of your situation, that will also be read by others who it might be applicable to.

Reply

[-]

decko_kaj_fura_crno@reddit

Seems like you want a new guy to establish some of core company proccesses like writing/editing documentation of the stuff he just put his hands on. I'm sorry but this sounds so silly. The most experienced and most involved people in agency should do that. In what world new guy knows anything about anything well enough to write documentation...Dude doesn't even know which questions to ask and thats perfectly normal in agency with no proccesses because everything is question there. Seniority has nothing to do with it, we are not magicians or mind readers. We are technical people.

Reply

[-]

akeniscool@reddit

I didn't say OP should establish core company processes or backfill an entire documentation catalog. "Be the change you want to see in the world" is the vibe I'm going for. A reminder to OP and everyone here that you have the power and ability to contribute knowledge, even if it's only a sliver you learned today.

Reply

[-]

Romeo3t@reddit

I kind of agree with both sides. I'm not sure where this notion comes from that the new guy should be the one leading the charge on important company processes but its a bit toxic and does not make for a good first few months. I don't think its too bad to expect the new guy to ask good questions and improve documentation where they can, but I think maybe people forget how overwhelming being new to an environment can be? As the new guy I: * Barely know what questions to ask, I'm devoid of so much knowledge I only know vague outlines of things from past experience, but I can't know what I don't know and if I don't know what I don't know I can't ask intelligent questions on it. * I'm not read in on the processes or culture and therefore trying to lead the charge on something could be a massive waste of time while I run into a bunch of deadends due to various (undocumented) reasons. * Am usually under a metric shitton of stuff to do between onboarding, reading, attempting to learn and spin up on my projects. * I'm trying to establish my political capital. I don't want to rock the boat with people I don't know or throw anyone under the bus. First impressions matter. But I also agree with OP that...reality is kinda messy. Human beings are far from perfect and most environments you do kind of have to have mitigations for these to be successful. I've never met a non-fanng company that was actually good at onboarding and guiding new people.

Reply

[-]

Odd-Investigator-870@reddit

Go read about Dark Scrum, and accept that any manager or job description that says they "do Agile" is both incompetant and effectively lying.

Reply

[-]

AHardCockToSuck@reddit

Welcome to the club

Reply

[-]

CowboyBoats@reddit

Username relevant :(

Reply

[-]

temp_vaporous@reddit (OP)

Lol oh boy. Time to grow a thick skin and power through it I guess.

Reply

[-]

liquidpele@reddit

This is a fantastic reply to that person's username lmao

Reply

[-]

ReformedBlackPerson@reddit

Put on the big boy pants. If you need help/explanations just schedule a meeting with the senior dev. If you think documentation is lacking then take notes as you go through the code trenches and build the docs. A senior should be the “doer of change” that a company needs.

Reply

[-]

ReaverKS@reddit

Oof. As an engineering manager the number of responses that this is normal really hurts. Of course I’d expect a senior to be able to handle some ambiguity but at the same time 60 minutes of pairing over 3 weeks is nothing. I encourage devs on our team to pair with new devs at least 3 times a week. I personally sit down with new devs and explain the release process, how we use Jira, etc. Anything that’s basic housekeeping kind of stuff I explain multiple times.

Reply

[-]

sweating_teflon@reddit

> tribal knowledge Unfortunately very very frequent. Documentation, tests, automation often take second and third seat to feature delivery. Code first, ask questions later, etc. > all the same person Manager && Team lead is frequent, can be totally fine depending on personal toxicity / niceness. But having no one else to turn to in case of conflict can quickly become a problem. Scrum master is not a job, it's a role that anybody on team should do. It's just being the MC at meetings. The whole thing smells like concentration of power, which isn't a good sign. Thread lightly. > on-boarding buddy LOL this rarely works but at the org understands it's something they should do. Many places don't even make knowledge transfer an explicit thing and just expect new hires to learn by ... osmosis? Ask questions, politely insist on getting answers. Physically pair up / shadow with other members of the team. Juniors often are a good source of info, they remember the struggle and enjoy the consideration from seniors. Being a Fortune 100 company changes nothing. Every dept has its own culture and cycles - people come, people leave. Be wary of those who stay for the wrong reasons.

Reply

[-]

kruvii@reddit

Different companies have different processes. Some people mesh with a more lax environment, other people go insane.

Reply

[-]

_bobby_salsa_@reddit

Welcome to the suck.

Reply

[-]

jonoherrington@reddit

The tribal knowledge is bad, but the bigger tell for me is one person acting as manager, team lead, and scrum master while also hand-assigning work. That usually means the team is optimized for short term ticket flow, not for building shared understanding. In a setup like that, weak onboarding is not an accident. It is a side effect of the operating model. So yes, as a senior you’re expected to create clarity from ambiguity. But if the system keeps routing all context through one person, you’re not dealing with normal senior ambiguity. You’re dealing with a decision bottleneck. I’d watch one thing over the next month ... when you ask for context, does the team get more open and legible ... or does everything still have to go back through that one person? That tells you whether this is just messy onboarding or a culture problem. That's something.

Reply

[-]

DeterminedQuokka@reddit

So none of this is good but it’s not abnormal. I think the best advice here is to find additional supports. If it’s kind of a mess and there is no documentation the one other senior on the team is likely underwater make friends with some more junior engineers. Chances are only like 10% of your questions need that guy specifically. When I started at my current job it took my boss a month to “find” me an onboarding buddy. And I’m pretty sure the one I got was because they complained to him I didn’t have one. And that person worked 2 days a week. My primary answers came from a junior engineer who also started a few months earlier so knew all the setup stuff and a midlevel engineer who had been around and knew who to talk to. 6 months later I flipped the relationships and now I mentor the junior. And the midlevel is on a different team now so we coordinate project between the teams together.

Reply

[-]

writebadcode@reddit

Learn to use GitHub search really well and make a habit of going to the code first if you want to understand something. If they’re using Jira and you’re allowed to connect to the atlassian MCP I’d highly recommend that. I’ve reconstructed a ton of tribal knowledge by having cursor cross reference GitHub, Jira, and confluence. YMMV if they’re using different tools, but it’s been working great for me.

Reply

[-]

wrex1816@reddit

It doesn't necessarily have to mean immediate disaster but I've met this scenario in two different teams: 1. The team knew they needed to better structure and become a more mature team. The manager outright told me that was why they were hiring, for someone to be the leader in that regard. Ended up being a very nice team to work for. Everyone was motivated but they just needed expertise in some areas. 2. I joined a team who felt they already knew everything. All ideas or suggestions were shut down immediately. Asking for help was like you had shown them signs of weakness. Massive egos and even more massive levels of insecurity on that team. I guess it depends where this job falls in the spectrum between those two.

Reply

[-]

koorob@reddit

if things weren’t so fucked up they wouldn’t need you.

Reply

[-]

Intrepid-Stand-8540@reddit

I've never experienced it not being exactly like this.

Reply

[-]

Saki-Sun@reddit

DevOps !== Dev

Reply

[-]

decko_kaj_fura_crno@reddit

That is my experience with any Agency i've worked for. Few of them were considered to be top agencies in their industry.

Reply

[-]

bytesbits@reddit

Let's be honest here if there was documentation it would either be out of date or nobody would bother to read it.

Reply

[-]

PressureHumble3604@reddit

I agree with individualistic but not capitalistic. now capitals make you write documentation and onboarding for ai agents, so they were useful after all.

Reply

[-]

CorrectPeanut5@reddit

It can happen at any shop, but in my experience it seems to happen more with DevOps over pure Dev positions. I think some of it is the nature of the workflow. My take would be to make yourself be the guy who's going to fix that. This is something that's an opportunity. Everything you learn becomes an opportunity to push a README.md into the repo with step by step idiot proof steps any junior could follow. Evangelize the idea with your manager and once you get a foothold push to make real documentation be part of the definition of done. Someone asks why you're taking a bunch of time to do stuff you you can point to work product. It's also a good use of LLMs to help create the docs. Just make sure to read them carefully and edit them to make sure they aren't slop.

Reply

[-]

thr0waway12324@reddit

First senior gig? This is absolutely normal. Honestly as a junior I had the same experience. It’s pretty common because the company doesn’t give enough leeway for devs to “help” each other. So it becomes this sorts perpetual burnout cluster fuck where everyone just tries to do what they can. Nobody is able to draw a line between documentation and dollars so it’s skipped. Tests? What are those? Are customers churning due to low quality? Probably. But since we can’t (won’t) prove it then we won’t invest in fixing it. Onboarding? Lol figure it out or you’re fired. We hired a senior not a junior. Maybe we should replace you with a cheaper junior. Or someone overseas. Oh ok now you’re starting to fall in line and understand how things work. Good! Now complete these tickets by the end of the sprint. See you in standup tomorrow. You better have some progress or a damn good reason for not having enough progress. Good luck! ^ SWE in a nutshell

Reply

[-]

BlazingThunder30@reddit

Some of these points are things I'd expect a DevOps engineer to fix. Not in their first weeks, mind you. Prod keeps going down losing money and time? Proper testing and CI. Customer churn because of bugs? Proper observability. All in Ops wheelhouse, at least partially. But not in their first weeks. I'd expect a company who hire a DevOps engineer to understand this. Then again, a senior engineer should have the capacity to explain to management why the investment has to be made and how it'll pay off. You'd expect a company to listen to a senior engineer, even if they're new they've been around and seen things.

Reply

[-]

morswinb@reddit

Common yes. Good no. You hire an expensive dev. That's like +50k investment with all the interviews, recruiter cuts, husslee etc. Then at the last stage you won't spend 10% more to make sure he gets onboarded with no issues?

Reply

[-]

temp_vaporous@reddit (OP)

Yep first time senior. Was junior for 2 years and mid level for 4. Definitely some growing pains and mindset adjustments but I'm getting a lot of good perspective from these replies. I'm confident I'll grow into it and figure it out, and if I don't it certainly won't be for lack of effort.

Reply

[-]

thr0waway12324@reddit

Oh I left out the best part! Hope you like on call! You now those tests you didn’t write because you had to hit a deadline? Yeahhh now there’s an outage. So we’re going to take more of your time to address the issue now, after the fact! So you see we never need tests or quality control because we will just call you anytime we want to come fix it when it breaks!! Win win! ☺️

Reply

[-]

PersianMG@reddit

Being Senior means you have to find and work towards solution. If the documentation sucks and there is a knowledge Silo, you say in stand-up "Hi team, I am completely unable to process with X because there is no documentation. Dev Y are you able to pair with me for 2 hours today until I learn the process, and I will also begin documenting this for the next person". If at that point people refuse to help, you escalate to managers and then that is on them. Ultimately, be vocal, document your asks, and document the learnings. Also do this in a nice & friendly manner obviously. You're new here so you want to approach things delicately and not rock the boat immediately so to speak unless you have a better idea of how people like to work.

Reply

[-]

Ok_Fault_5684@reddit

Does anyone else look at these posts just to make sure it's not you/your company? 👀

Reply

[-]

mRWafflesFTW@reddit

You should read the First 90 days. It's a generic business book but I think it's applicable here.

Reply

[-]

Devboe@reddit

Your post describes the company I work at to a T. I’d say it’s a pretty normal experience based on the other comments. Hopefully you have access to AI tooling and can ask it to explain the unknowns to you.

Reply

[-]

Bricktop72@reddit

You're a senior dev. You aren't just fixing code but you should also be fixing the team.

Reply

[-]

morswinb@reddit

1) is common, outdated doc is worse than no doc. Better to have somehow readable code and simple stack. 2) also common and kind of bad. You want more than one stakeholder. Nobody to meditate if stuff does not go according to plan. And stuff never does. 3) yea this sucks. They should have given you a few weeks to catch up and introduce you to their stack. Your buddy might not care, be overworked, or checked out. Unfortunately a large number of companies are like that. Also it's the less nice to work companies that need to look for people, good companies retain their employees or have referrals. Especially on Senior level.

Reply

[-]

hippydipster@reddit

That all sounds very normal.

Reply

[-]

BayouBait@reddit

Welcome to the real world.

Reply

[-]

PressureHumble3604@reddit

This is sadly common but shouldn't be, not your fault. I am very curious to know company or industry

Reply

[-]

rhd_live@reddit

* Breaking Bad meme * “I am the documentation”

Reply

[-]

No_Pin_1150@reddit

sounds exactly like my job.. except I did not get 60 minutes with any dev.. I was invited to ask questions if I have any.. I just started 3 months ago.. very sink or swim place

Reply

[-]

zambizzi@reddit

That’s pretty normal. You’re expected to ask a lot of questions and seek out the people you need, to get what you need.

Reply

[-]

xdevnullx@reddit

...but not too many questions.

Reply

[-]

tehfrod@reddit

This has more red flags than the United Nations. No, not every company is like that. But right now, you have to do the gut check of whether 1) you're ok with it, 2) you're willing to stay long enough to build enough capital to change it, or 3) start looking for something better.

Reply

[-]

GoodishCoder@reddit

This is pretty standard, just be proactive. If you don't know the release process, just ask someone when you're ready to release something. If you don't know what you don't know, ask questions when it blocks you.

Reply

[-]

mpanase@reddit

>he often sidesteps our PO and directly assigns specific tickets to specific people the PO should not be assigning tickets at all. Seems like the problem is that he sometimes allows the PO to do it >I have probably only had a combined 60 minutes of time with him over teams that's not ok. Nowhere near enough flag this up and make sure a daily meeting is set up I usually schedule a daily 1h meeting, plus some ad-hoc ones with specific topics. We can always skip one if we want agree, but the time needs to be put aside for onboarding you >Now I understand that as a senior no one should be holding my hand Don't say that. You deserve a proper onboarding, a proper chance to succeed >This culminated in me trying my best to complete my first deliverable but missing the mark Consistently flag every single time you are not being onboarded and it's affecting you productivity or morale If you are not being onboarded, **the lead** needs to know Remember that **the other senior is your colleague**. Don't be aggressive with him. That's a job for the lead and for the manager.

Reply

[-]

No-Economics-8239@reddit

What paradisiacal oasis of civility established your baseline expectations? Chaos has been the much more common bedfellow over my career than order and stability. Lurching from one crisis to the next is more the extreme, but change has been a constant. Change introduces instability and confusion and is part of the chrun that causes documentation to fall behind and get deprioritized other more immediate goals like keeping the ship afloat and figuring out the course to chart or trying to understand the course you are actually upon. Leadership tends to be more a luxury. Effective teams that are clear in their motivations and goals and play well together are very much the exception. Bureaucracy and politics are much more the norm where multiple groups are competing for scarce resources or recognition or their own selfish ends. The higher the ladder you ascend, the more your responsibility shifts to trying to distill some order from chaos and building partners and allies and relationships and understanding and navigating the social strata so you can pick and choose who to support, help establish and actualize goals, and otherwise communicate how you are providing value above and beyond actually providing value. Because perception tends to more the more real and immediate goal over reality. Your soft skills become as critical over your technical ones. You need to not only understand but also to be able to communicate successfully. It's not enough to just be correct if you don't have the trust or reputation or ability to make that clear to the decision makers who need to act upon it. And knowing *who* you need to convince and knowing enough about them so you know *how* to convince them is all your responsibility as well. Rather than red flags, what I see is a target rich environment that is rife with opportunities for improvement. Actively listen to what is going on and learn the lay of the land and the various priorities, then roll up your sleeves and work to improve things.

Reply

[-]

skidmark_zuckerberg@reddit

My current job (which has turned out to be a good job) was like this with the tribal knowledge when I started. The problem wasn’t doing the actual work, it was all of the tribal knowledge that hardly anyone shared unless prompted to, i.e me asking or just throwing up a PR and letting someone tell me if something is wrong - trial by fire basically. But over time I learned enough to start documenting things which helps a ton, and it’s low hanging fruit. Documentation is pretty straightforward and everyone can appreciate it. Anytime I have needed to create something, be it a project, tool, etc — I document it throughly. Mostly so I can remember but also because it enables faster onboarding for future developers. Documentation and code comments would’ve saved me a lot of time hunting down the right person who would know

Reply

[-]

hatsandcats@reddit

Yep it’s the Wild West right now. Figure out who has power and start making yourself useful to them. Don’t do anything other than what they want and make yourself easy to work with.

Reply

[-]

BickeringCube@reddit

If you find yourself complaining about lack of documentation that is a big flashing neon sign indicating you should create the documentation.

Reply

[-]

lapinjuntti@reddit

Ask, ask, ask. That is the cost of not having documentation. And write documentation as you discover things.

Reply

[-]

Mast3rCylinder@reddit

Yes you should figure things on your own through research and write questions so you can ask other engineers. All the 3 points you mentioned i had when I started my current position. My buddy also didn't know much and couldn't answer my questions. Today you have AI to help you research so it's even easier, buy yes overall you should do a lot of stuff on your own.

Reply

[-]

ImSoCul@reddit

It's expected to varying degrees. Some shops have pretty good documentation and processes, some have nothing. My team leans pretty heavily into documentation and if anything we have too many to be able to find the right one. Guess what you're hired to do as a senior dev? I joined a new job as a cake baker and the cakes are unbaked is this normal?

Reply

Reply to Post

80 Comments