Client: drops a few devs in the standup
Everyone: wtf who are these people what what are they going to do?
Client: could you (me) help them get up and running and answer any questions they have.

New dev: where is the host file located?

Me (in my head): wait what you dont know? Wtf you have 'senior' dev in your fucking email signature. Go and fucking google

Me: c:/system32/drivers/etc/hosts.

Fuck my life right now.

A follow-up to a previous rant: https://devrant.com/rants/2296700/...

... and how the senior dev recently took it up a notch.

To recap: Back then the senior dev in our two-man project prepared tasks for me so thoroughly they became typing monkey jobs. He described what to do and how to do it in minute detail in the JIRA tasks.

I talked to him back then how this is too detailed. I also talked to our boss, who agreed to nudge mr. senior in the right direction and to make it clear he expects teamwork.

Fast forward to a couple of days ago. An existing feature will get extended greatly, needing some rework in our backend project. Senior and me had a phone call about what to do and some unclear details in the feature spec. I was already frustrated with the call because he kept saying "No, don't ask that! That actually makes sense, let's just do it as the spec says" and "Don't refactor! We didn't request a budget for that from our customer". Like wtf, really? You don't consider refactoring part of our job? You don't think actually understanding the task improves the implementation? Dude...

We agreed this is a task for one person and I'd do it. It took me the rest of the day to wrap my head around the task and the corresponding existing code. It had some warts, like weird inheritance hierarchies and control flow jumping up and down said hierarchy, but nothing too bad. I made a mental note to still refactor this, just as much as necessary to make my task easier. However... the following day, I got an email from mr. senior. "I refactored the code after all, in preparation for your task". My eyebrows raised.

Firstly, he had made the inheritance hierarchy *worse*. Classic mistake: Misusing inheritance for code reuse. More control flow jumping up and down like rabid bunnies. Pressed on that matter, he replied "it's actually not that bad". Yeah, good work! Your refactoring didn't make things worse! That's an achievement worthy of being engraved on your tombstone. And didn't he say "no refactoring"? Apparently rules are unfortunate things that happen to other people.

But secondly, he prepared classes and methods for me to implement. No kidding. Half-implemented methods with "// TODO: Feature x code goes here" and shit. Like, am I a toddler to you? Do you really think "if you don't let me do things myself I feel terribly frustrated and undervalued" is best answered with giving me LESS things to do myself? And what happened to our boss' instruction to split the task so each of us can work on his parts?

So, this was a couple of days ago. Since then, I've been sitting in my chair doing next to nothing. My brain has just... shut down. I'm reading the spec, thinking "that would require a new REST endpoint", and then nothing happens. I'm looking at the integration test stubs ("// TODO: REST call goes here") and my mind just stays blank, like a fresh unpainted canvas. I've lost all my drive.

I don't even know what to do. Should I assign the task back to him and tell him to go fuck himself? Should I write my boss I'm suddenly retarded? Could I call in sick for a year or so? I dunno... I can barely think straight. What should I do and how?

In reply to this:
https://devrant.com/rants/260590/...

As a senior dev for over 13 years, I will break you point by point in the most realistic way, so you don't get in troubles for following internet boring paternal advices.

1) False. Being go-ahead, pro active and prone to learn is a good thing in most places.
This doesn't mean being an entitled asshole, but standing for yourself (don't get put down and used to do shit for others, or it will become the routine) and show good learning and exploration skills will definitely put you under a good light.
2)False. 2 things to check:
a) if the guy over you is an entitled asshole who thinkg you're going to steal his job and will try to sabotage you or not answer acting annoyed, or if it's a cool guy.
Choose wisely your questions and put them all togheter. Don't be that guy that fires questions in crumbles, one every 2 minutes.
Put them togheter and try to work out the obvious and what can be done through google or chatgpt by yourself. Then collect the hard ones for the experienced guy and ask them all at once. He's been put over you to help you.

3) Idiotic. NO.
Working code = good code. It's always been like this.
If you follow this idiotic advice you will annoy everyone.
The thing about renaming variables and crap it's called a standard. Most company will have a document with one if there is a need to follow it.
What remains are common programming conventions that everyone mostly follows.

Else you'll end up getting crazy at all the rules and small conventions and will start to do messy hot spaghetti code filled with syntactic sugar that no one likes, included yourself.

4)LMAO.
This mostly never happens (seniors send to juniors) in real life.
But it happens on the other side (junior code gets reviewed).
He must either be a crap programmer or stopped learning years ago(?)

5) This is absolutely true.
Programming is not a forgiving job if you're not honest.
Covering up mess in programming is mostly impossible, expecially when git and all that stuff with your name on it came out.
Be honest, admit your faults, ask if not sure.
Code is code, if it's wrong it won't work magically and sooner or later it will fire back.

6)Somewhat true, but it all depends on the deadline you're given and the complexity of the logic to be implemented.
If very complex you have to divide an conquer (usually)

7)LMAO, this one might be true for multi billionaire companies with thousand of employees.
Normal companies rarely do that because it's a waste of time. They pass knowledge by word or with concise documentation that later gets explained by seniors or TL's to the devs.
Try following this and as a junior:
1) you will have written shit docs and wasted time
2) you will come up to the devs at the deadline with half of the code done and them saying wtf who told you to do that

8) See? What an oxymoron ahahah
Look at point 3 of this guy than re-read this.
This alone should prove you that I'm right for everything else.

9) Half true.
Watch your ass. You need to understand what you're going to put yourself into.
If it's some unknown deep sea shit, with no documentations whatsoever you will end up with a sore ass and pulling your hair finding crumbles of code that make that unknown thing work.
Believe me and not him.
I have been there. To say one, I've been doing some high level project for using powerful RFID reading antennas for doing large warehouse inventory with high speed (instead of counting manually or scanning pieces, the put rfid tags inside the boxes and pass a scanner between shelves, reading all the inventory).
I had to deal with all the RFID protocol, the math behind radio waves (yes, knowing it will let you configure them more efficently and avoid conflicts), know a whole new SDK from them I've never used again (useless knowledge = time wasted and no resume worthy material for your next job) and so on.
It was a grueling, hair pulling, horrible experience that brought me nothing in return execpt the skill of accepting and embracing the pain of such experiences.

And I can go on with other stories. Horror Stories.
If it's something that is doable but it's complex, hard or just interesting, go for it. Expecially if the tech involved is something marketable.

10) Yes, and you can't stop learning, expecially now that AI will start to cover more and more of our work.