Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "wk157"
Now let me be clear and say I’m not against code review in general and I think it’s a critical part of the engineering process...
But picture this situation:
Q: “Why is this const?”
A: because it is invariant and more information for the compiler means it’s easier to forward constants etc.
Q: “why don’t you do it this other way that’s no better than what you did here?”
A: “stop wasting time”
Q: “I’m going to block submission of this emergency patch because of code formatting and then go home for the day”
Q: <asks about some other c++ semantic related to the change under review>
A: <explains basic c++ language topology while simultaneously wondering why this is the appropriate forum for it>
Q: “you should have designed this the way I would”
There are some great code reviewers on my team but there are just as many time wasters who’s comments seem more related to not knowing how c++ works and how compilers work than actual deficiencies in my code.
I’ve also tried to bring better readability to our codebase in ways that are so subtle they are almost style agnostic and that has been met with fierce resistance (our codebase is actually quite good but has no naming conventions or file conventions whatsoever and it’s nuts how frustrating it is)
I guess to put it more precisely my issue with code review starts when it becomes somebody else’s forum to prove they’re smart enough and hard working enough to be worth their salary rather than a forum for improving submissions and catching bugs. I have a big fucking issue with that.14
Boss: Hey man, can you do an extra couple of hours today to finish [...] up? I just talked to [person he knows is driving me home that day] and he said he would do them! Can I count on you?
Me: Hey, [person driving me home]. Are you really doing the extra hours the boss is asking for? I thought you didn't wanna stay longer today...
[person driving me home]: F*ck no! He hasn't asked me yet.1
Team quarterly capacity planning:
- Confluence document created with a big table (+100 rows) by product / business. Each row is something that needs to be worked on for the coming quarter.
- Row 1 could be an Epic with 15 tickets attached. Row 2 could be adding a single log to our analytics. No consistency.
- For each row, we create a separate confluence document with the "technical details". 75% of the time these remain blank. 1% of the time there is something useful, the rest its a slightly longer version of the description from the bigger document.
- Each row gets a high level estimate by the leads. 50% of the time without sufficient background info to actually do get it accurate.
- These are then copied into the teams excel spreadsheet, where it will calculate if we are over/under capacity.
- We will go backwards and forwards between confluence and excel until we are "close enough" to under capacity without being too much.
- Once done, we then need to copy them into the org/division's excel spreadsheet. This document is huge, has every team on it and massive 50pt text saying "Do not put a filter on this document".
- Jira tickets + Epics will now be created for each one, with all the data be copied over by hand, bit by bit, by product. Often missing something.
- Last week, at the end of this process for Q2 (2 weeks late), 6 of the leads were asked to attend a 30 minute meeting to discuss how to group the line items together because we had too many for the bigger excel spreadsheet.
- This morning I was told business weren't happy with one of our decisions to delay one line item. Although they were all top priority (P0), one of them was actually higher than that again (P-1?) and we need to work it back in.
... so back to step 1
- Mid way through Q2, a new document will be created for Q3. Work items that didn't make the cut will be manually copied from one to the other. 50/50 whether anything that didn't get done on time in Q2 will make its way to the Q3 doc.
- "Tech excellence" / "Tech debt" items (unit/UI tests, documentation, logging, performance, stability etc) will never be copied over. Because product doesn't understand them and assumes therefore that they are unimportant.
PS: I'd like to say this was a rare event for Q2, but no. Q4 and Q1 were so bad, we were made assurances from the director of engineering that he would fix this process for Q2. This is the new and improved process (I shit you not) that has resulted in nothing tangible.7
story points that equate to hours.
1 = 1 hour
2 = 1-2 hours
3 = 3-4 hours
5 = 6-8 hours
8 = Kill. Me.
13 = Now.3
New password cannot be one of your four previous passwords.
Password must conatin upper and lower case characters, at least two numbers and two special characters
Password cannot contain five or more consecutive letters of username.
Password cannot include any _illegal patterns_.
Locked out of your system? Drive over to HQ and ask the admins to reset your password in person.6
Time tracking. 😡🤮 If I’m salaried and only working on one project for one client, why the hell should I waste my time making weekly reports of how many hours I spent coding, reviewing pull requests, and sitting in (mostly pointless) meetings?5
The design process.
Call me old fashioned - but clean-code/clean-architecture/SOLID is not as important as simplicity and coherence.
I JUST NEED FUNCTION THAT DOES STUFF! But noooooo better overly design EVERYTHING!4
The performance is based on how much code you wrote that day.
Not mine though, i heard/read it from somewhere else.
But that’s fucked up, right?22
Whenever non-tech boss / client, dive into software engineering problem trying to micromanaging us, and ask how he could help to solve us hoping that the project could speed up in some way.
just stay the fuck away1
3 time sheets: One for the company I work for, one for the parent company staffing us to clients, one for the client.
All three have to be handed in at different times, have different rules, are on different systems and have to fit hourwise.
A waste of hours per week.
And add an offshore team that checks all 3 to this.
Also once in a while they complain about something in it. (Audits, reviews,etc.) Forward to boss, he has to argue with them.
Waste of so much time.3
The most obnoxious company process I've encountered so far is the nonexistent one.
This is what happened at my first professional job. PM and CTO quit after about a year, yet the top honchos were insistent of salvaging what was left of their "enterprise" software suite and putting us through a death march to try and continue development.
No plan, despite having a JIRA board filled with month-old backlog stories. No direction, because the CEO was now head of the project and wasn't in the office about 50% of the time, and our lead dev wasn't willing to take the reigns.
I wouldn't have minded trying a bunch of different things and having them fail. At least then we'd be doing something, you know? But instead we sat around, trying to squeeze any kind of goal from the higher ups, until I finally had enough and found a much better job.
It wasn't enough to convince me to give up software development. But boy, did it sure come close.
Most obnoxious company process: The newly introduced promotion process at my ex-employer.
Originally they had a run-of-the-mill process. You and your boss reviewed your performance independently, then spent an hour to compare results. If you agreed to have proven yourself, your boss did some remaining paperwork (iow he did his job) and done.
Under the guise of transparency, fairness and autonomy of employees this was changed to:
You had to find three coworkers willing to review you (favorably). You collected their feedback, processed that (strengths, "opportunities for improvement", etc) and presented it to your boss for review. These were the first two steps of four in total, of which I've forgotten the other details tbh. It became pretty ridiculous with you defining "progress indicators", your boss's boss involved in another review round and what not.
The true purpose was clear: Delaying promotions as long as possible, making the employees do all the work, and being able to just say "no" at any point. I don't know how intellectually superior managers and HR viewed themselves, because literally none of my coworkers bought this as an improvement.
But, yeah, that became the new process at a company too big to fail.1
My current job at the release & deploy mgmt team:
Basically this is the "theoretically sound flow":
* devs shit code and build stuff => if all tests in pipeline are green, it's eligible for promotion
* devs fill in desired version number build inside an excel sheet, we take this version number and deploy said version into a higher environment
* we deploy all the thingies and we just do ONE spec run for the entire environment
* we validate, and then go home
In the real world however:
* devs build shit and the tests are failed/unstable ===> disable test in the pipeline
* devs write down a version umber but since they disabled the tests they realize it's not working because they forgot thing XYZ, and want us to deploy another version of said application after code-freeze deadline
* deployments fail because said developers don't know jack shit about flyway database migrations, they always fail, we have to point them out where they'd go wrong, we even gave them the tooling to use to check such schema's, but they never use it
* a deploy fails, we send feedback, they request a NEW version, with the same bug still in it, because working with git is waaaaay too progressive
* We enable all the tests again (we basically regenerate all the pipeline jobs) And it turns out some devs have manually modified the pipelines, causing the build/deploy process to fail. We urged Mgmt to seal off the jenkins for devs since we're dealing with this fucking nonsense the whole time, but noooooo , devs are "smart persons that are supposed to have sense of responsibility"...yeah FUCK THAT
* Even after new versions received after deadline, the application still ain't green... What happens is basically doing it all over again the next day...
This is basically what happens when you:=
* have nos tandards and rules inr egards to conventions
* have very poor solution-ed work flow processes that have "grown organically"
* have management that is way too permissive in allowing breaking stuff and pleasing other "team leader" asscracks...
* have a very bad user/rights mgmt on LDAP side (which unfortunately we cannot do anything about it, because that is in the ownership of some dinosaur fossil that strangely enough is alive and walks around in here... If you ask/propose solutions that person goes into sulking mode. He (correctly) fears his only reason for existence (LDAP) will be gone if someone dares to touch it...
This is a government agency mind you!
More and more thinking daily that i really don't want to go to office and make a ton of money.
So the only motivation right now is..the money, which i find abhorrent.
And also more stuff, but now that i am writing this down makes me really really sad. I don't want to feel sad, so i stop being sad and feel awesome instead.1
Weekly status reports. BITCH, I'M TOO BUSY WORKING TO TELL YOU WHAT I DID THIS WEEK.
Mine are also almost always the same:
"fixed broken thing"
"worked on reports for broken thing"
"helped new teammates fix broken thing"
ISSUES REQUIRING ATTENTION:
"my connection is still shit, like i warned would happen before I moved"
"need workstation already connected to network to reduce connection problems"
These don't help the people who need to be micromanaged, and they just piss off those of us who don't.5
Logging literally everything from every service into one giant super log db for us to sift through.
It is expensive, it is stupid, and it is set to .info() level always forever no exceptions.3
You want to ask me if a button could change behavior?
Instead of asking me directly and have an answer in 5', let's have a meeting with 5 other persons who don't give a shit!
Let's have coffee! Hey, why not hold a meeting to choose where? Please take me outta here...
That's how you justify your job here: by polluting other people.
I don't know about obnoxious processes, but I do know about one single event that happens WAY more than it should, and that might be people from customer relations coming with "new awesome features that MUST be implemented asap"
oh boy the times I've pictured me shoving a scrum guide down their throats....3
Having no process at all;
Just randomly choose between texts, FB Messenger, WhatsApp, voice clips, and spread over random points in time..
If you do this to me: Yes. I hate you.
Mandatory change of password sucks.
Especially if you are using Windows.
Changing your password regularly can be good for security reasons. But I hate it that Windows keeps a log of all my previously used passwords and prevents me from using a former one. I mean, log the last three and then allow resuse. In our case, we need to change it every 180 days. So if I want to use a favorite "old" one, that it more than 1,5 years old ...11
A company I once worked for actually had an IT management reporting process called TPS reports. Completely non-ironically. I did ask if they were giving homage to “Office Space” and they were like, “Wut?”
And, yes, the report was obnoxious and a complete waste of everyone’s time.
In our company, "UAT".
We using staging environment and most of the data is either missing or corrupt. They don't refresh the data, saying it can impose some security issue.
How the hell are we supposed to complete UAT when there's no data that's in production!!!!1
the daily/weekly/monthly/yearly meeting where everybody absolutely agree on absolutely fucking everything and everybody shows only positive things.
After that, you go back to work and it's the opposite.3
Our approval process for creating new database tables is ridiculous. After your table has been created it goes through two other men, both of whom have been woking with SQL for centuries and could actually just create the damn thing themselves and leave me the fuck out of it! Our DBA isn’t really much of a DBA...7
I'm currently interviewing for other jobs, told my manager last week, was told by a company director that is a career limiting announcement.
Like, genuinely, fuck you. Grow up.
The worst they can do to me between now and when I'm gone is to take the interesting projets away from me and give them to someone else, but the only other person that can really do the things I do is my manager (CTO) who is busy as fuck, so anyone else is going to need my help, and oh hey suddenly I don't know the answer to their questions so what you going to do?4
Developers don’t have access to the test database so I had to put in a request for a dba to add two columns and it took over two hours for them to complete it.5
1) receive functional requirements
2) create functional specification, post it on forum (no jira)
3) create memo document, post it on forum (no jira)
4) create analysis document with actual code changes without seeing the code (wait for step 8), post it on forum (no jira)
5) receive review on analysis document, fix it and post (no jira, redmine etc from now till the end of rant)
6) after analysis is approved make a checkout request
7) source code manager checkouts files from svn and posts them on forum along with the files list
8) you make actual changes to the code, post changed sources on forum
9) source code manager makes a review to check that amendment commet is present in source code and is properly tagged, and every line of code chnged is properly tagged (you are not allowed to delete anything, not even one space, you need to comment it (and put an appropriate tag))
10) after you passed review you fill in standard compilation request form
11) you code is compiled and elf is put on testing stand
12) you fill in "actual behaviour" and "expected behaviour" columns near description of changed function in template of unit test plan document (yeah we have unit testing) and post it on forum
13) if testing ok changed sources and compiled elfs along with its versions (cksum) commited to svn (not by you, there is a source code manager for that)
14) if someone developed function in same source file as you "commited" he is warned by source code manager and fills checkout request form again
Needing to approve each and any brainfart open-source library. Having to manipulate transitive package dependencies to throw out dependencies with non-compliant license.