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 - "manager logic"
-
Manager: You can’t define an async function without using await.
Dev: Yes you can.
Manager: Well you shouldn’t, there’s no point!
Dev: Yes there is. It can turn blocking synchronous logic into work performed concurrently. In this case the perform—
Manager: It’s called async *await*. Async *AWAIT*! Did you hear the two parts to that? You shouldn’t ever have one without the other. THEY GO TOGETHER. Worrying about concurrency is for people who use callbacks which just goes to show how out of date your skills are. I’m reading a book on javascript and there are so many advanced techniques out there that I haven’t even seen you use ONCE!
Dev: …
*I looked at the book he’s reading, it’s from the < ES6 era… no wonder he doesn’t see me using any of those archaic patterns/hacks/workarounds…*14 -
colleague in a planning meeting: so now it's Easter, which in Germany is public holidays on friday and monday
PM: i as a manager would find it great if there weren't any public holidays
yeah not surprised, but thank fuck you're not the one to decide that... some people are trying to have a life^^11 -
Manager logic: Adding "somehow" to the front of the JIRA title for the JIRA description is super clear and helpful.
Example:
Title: Chat screen doesn't work
Description: Somehow chat screen doesn't work7 -
Manager: I want the front ends to be more dumb, too much logic is happening on the frontend.
Me: both of the sites are just multi step forms, I’m confused about the complexity part.
Manager: yea but don’t we have a bunch of third party api calls?
Me: we have 4 and they are public facing apis.
Manager: yea, make a new api and move this api calls to the backend and I want both frontend teams to send the same shape payload.
Me: but…
Manager: oh and I don’t like how the business team does the a/b testing and splitting traffic, let’s move that to the backend as well.
Me: but… that a/b testing platform they use in ran by another team and they have a full set of features for business analytics…
Manager: yea let’s just replicate those features and move them to the backend.
Me: but it’s a product!
Manager: look! You are the best backend engineer we got! I know you can do this!
Me: I lead the frontend teams…
Manager: ….
Manger: good news we are giving you a promotion with raise you are now a senior engineer.
Me: I confused but happy… I think..9 -
Worst collaboration experience story?
I was not directly involved, it was a Delphi -> C# conversion of our customer returns application.
The dev manager was out to prove waterfall was the only development methodology that could make convert the monolith app to a lean, multi-tier, enterprise-worthy application.
Starting out with a team of 7 (3 devs, 2 dbas, team mgr, and the dev department mgr), they spent around 3 months designing, meetings, and more meetings. Armed with 50+ page specification Word document (not counting the countless Visio workflow diagrams and Microsoft Project timeline/ghantt charts), the team was ready to start coding.
The database design, workflow, and UI design (using Visio), was well done/thought out, but problems started on day one.
- Team mgr and Dev mgr split up the 3 devs, 1 dev wrote the database access library tier, 1 wrote the service tier, the other dev wrote the UI (I'll add this was the dev's first experience with WPF).
- Per the specification, all the layers wouldn't be integrated until all of them met the standards (unit tested, free from errors from VS's code analyzer, etc)
- By the time the devs where ready to code, the DBAs were already tasked with other projects, so the Returns app was prioritized to "when we get around to it"
Fast forward 6 months later, all the devs were 'done' coding, having very little/no communication with one another, then the integration. The service and database layers assumed different design patterns and different database relationships and the UI layer required functionality neither layers anticipated (ex. multi-users and the service maintaining some sort of state between them).
Those issues took about a month to work out, then the app began beta testing with real end users. App didn't make it 10 minutes before users gave up. Numerous UI logic errors, runtime errors, and overall app stability. Because the UI was so bad, the dev mgr brought in one of the web developers (she was pretty good at UI design). You might guess how useful someone is being dropped in on complex project , months after-the-fact and being told "Fix it!".
Couple of months of UI re-design and many other changes, the app was ready for beta testing.
In the mean time, the company hired a new customer service manager. When he saw the application, he rejected the app because he re-designed the entire returns process to be more efficient. The application UI was written to the exact step-by-step old returns process with little/no deviation.
With a tremendous amount of push-back (TL;DR), the dev mgr promised to change the app, but only after it was deployed into production (using "we can fix it later" excuse).
Still plagued with numerous bugs, the app was finally deployed. In attempts to save face, there was a company-wide party to celebrate the 'death' of the "old Delphi returns app" and the birth of the new. Cake, drinks, certificates of achievements for the devs, etc.
By the end of the project, the devs hated each other. Finger pointing, petty squabbles, out-right "FU!"s across the cube walls, etc. All the team members were re-assigned to other teams to separate them, leaving a single new hire to fix all the issues.5 -
it is really frustrating not to be able to actually maintain and improve the code you're working with. i'd be happy to completely dig in and live in the code and get it all - not so much fucked up - , or, totally spitballing here, do some research on how we could improve the functionality and performance in general (which is not "nice to have", but rather ongoing customer pain points), but I'm not allowed to, because management hates having maintainable code or even an adequate number of devs. it rather has me doing hippity hoppity between different projects to make sure nothing gets my full attention. -.-
the only thing i can do is to clean it up a bit during bug fixes, but even heavy polishing won't fix this giant pile of garbage that is called our code base.2 -
the amount of micromanagement enforced in our scrum routine is getting ridiculous... but the PM seems to be happy with this14