Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "impossible deadline experience"
-
Fucking boss trying to "inspire" us by talking about famous people like elon musk, steve jobs etc.
Well newsflash dumb boss, they are not employees, they are fucking bosses too!
Atleast, consider paying us for overtime before trying to make us rebuild entire project in an impossible deadline.
And yeah, hiring someone who has experience in that framework would be helpful too.7 -
"Impossible deadline experience?"
When product owners promise delivery dates.
One day, I came back from a two weeks holiday, relaxed. I noticed a teammate missing. "Yes, he took the week off". Sure, why not.
We were working under a bastardized enterprisey version of Scrum (didn't we all at some point?). So we didn't just have a product owner, we had three and an additional "Head of PO". Because enterprises can't live without hierarchies or something. Barely an hour after I came into office, she entered the room and came straight to me. "Your coworker was almost done implementing feature X. You need to finish it immediately. No worries, though, coworker said the rest is a piece of cake".
It wasn't. There was *a lot* left to do, the JIRA task wasn't entirely clear, and the existing code for the feature was so-so (obviously WIP code). I estimated two weeks for the implementation, plus some time to clarify the requirements. When telling "Head of PO" she lost her shit. Screaming things like "this feature is due the end of this week" and "I signed this with my blood!". Well, I didn't, and I made it clear that I hadn't been consulted on this, thus I would not accept any blame in case we missed the deadline.
So I gave my best that week, getting pestered by "Head of PO" all the time. "Is it done yet?", "why does it take so long?" and "your coworker would've been done by now!". Yeah fuck you, too. Not only was I not relaxed any more, I was even more stressed than before my holiday! Thanks, you stupid bitch.
Well, her arbitrary deadline came and the feature wasn't ready. And what happened was... exactly nothing. The following week my coworker returned, who gave me an apologetic smile. "I told her the feature was nowhere finished. And even me, being familiar with the task, couldn't make it in time". We finished the feature together that week, and that was the end of it. So... "Head of PO" either didn't listen or lied to me. She then stressed me to the max right from the day I came back from my holiday. And in the end it didn't even matter.
Again, thanks you stupid bitch, for creating a toxic work environment. Should you ever read this, I'm happy I quit and I hope you miss every single deadline for the rest of your life. Screw you.8 -
Impossible deadline experience?
A few, but this one is more recent (and not mine, yet)
Company has plans to build a x hundred thousand square feet facility (x = 300, 500, 800 depending on the day and the VP telling the story)
1. Land is purchased, but no infrastructure exists (its in a somewhat rural area, no water or sewage capable of supporting such a large facility)
2. No direct architectural plans (just a few random ideas about layout, floor plans, parking etc)
3. Already having software dev meetings in attempt to 'fix' all the current logistical software issues we have in the current warehouse and not knowing any of the details of the new facility.
One morning in our stand-up, the mgr says
Mgr: "Plans for the new warehouse are moving along. We hope to be in the new building by September."
Me: "September of 2022?"
<very puzzled look>
Mgr: "Um, no. Next year, 2021"
Me: "That's not going to happen."
Mgr: "I was just in a meeting with VP-Jack yesterday. He said everything is on schedule."
Me: "On schedule for what?"
<I lay out some of the known roadblocks from above, and new ones like the political mess we will very likely get into when the local zoning big shots get involved>
Mgr: "Oh, yea, those could be problems."
Me: "Swiiiiishhhhh"
Mgr: "What's that?"
Me: "That's the sound of a September 2021 date flying by."
Mgr: "Funny. Guess what? We've been tasked with designing the security system. Overhead RFID readers, tracking, badge scans, etc. Normally Dan's team takes care of facility security, but they are going to be busy for a few weeks for an audit. Better start reaching out to RFID vendors for quotes. Have a proposal ready in a couple of weeks."
Me: "Sure, why not."1 -
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.4