We had an all hands on deck, world is ending bug one time. Like, basically the entire org got pulled onto it. In our product is a spreadsheet of activities, with dates and durations. Our customers can run a scheduling algorithm to adjust dates based off of durations and activity dependencies and relationships. This is super important. This broke. We have to make sure that activities don’t have circular dependencies, or otherwise scheduling will loop infinitely and fail. So, we basically dfs looking for a loop before scheduling, and fail it with a not really helpful error message. That loop checkimg got updated so it could properly provide helpful info in the error message. This change caused most real world schedules to have false positives for loops when checked, ergo, no ability to schedule. I found the cause of the problem but not the dependency structure that caused the issue, and ultimately decided it would be faster, cleaner, and overall better to rewrite the feature myself than to fix the original. So, I wrote the most beautiful damn depth first search of my life! Learned about the bug monday morning, had the fix good to go tuesday night, so that qa could test wednesday thursday for the hotfix merge deadline friday. Two days isn’t a lot to cover testing it, but I figure with every tester in the org pretty much available to pound on it itd be good enough. While I was working on the rewrite, other devs and qa were hunting down all the details of what happened to cause the bug, data structure wise, and coming up with good test cases. So, by the time it was ready, they knew what happened and had a much more thorough test plan. Well, it came down from on high that the fix would go into the next major release, not a hotfix, so it didn’t actually go out for 3 weeks after the monday the bug came in. Sigh. Well, I had fun writing it, and I consider it the cleanest, most beautiful and elegant code I’ve ever written. It used a stack of stacks! When I’m feeling shitty and useless at work, I go back and look at it tbh.
Wait, you didn’t have meetings about the button first?
Don’t forget refinement where you describe your plan to add the “height: 80pt” rule (literally what the client wants), and then poker planning where you say it will be 1 point and the lead dev says 3 points and the other dev asks what is a point anyway leading to a time consuming discussion, and then the task gets scheduled for not next sprint but the sprint after, and then you do it and push your code, make a pull request, then during code review it is suggested you use tailwind instead but your project isn’t using tailwind because it’s some legacy PHP monster started by a junior who was just learning PHP, so now there’s a POC to consider using tailwind meanwhile the lead dev (who has a background in QA) designs a reusable “height engine” which uses rabbitmq to alert all worker nodes (there’s only one) about any changes to the height rules in mongodb. The height engine doesn’t include units so you have to hardcode if the client is expecting rem or pt. The product owner asks you in sprint review why this ended up taking a week when you said 1 point initially and the team agreed on 3. A team decision is made that all future CSS rule changes require a POC prior to implementation.
It’s okay, breathe, the project manager isn’t in the room with us now
Those meetings come after you make the change where they tell you they actually expected the button would get smaller.
Oh, they did. But the guy doing actual work with the button was on the meetings about scrollbar
I am aghast at how difficult interviews are compared to literally every aspect of most jobs I’ve had.
The main thing I hate about inflated expectations in job postings and interviews is I keep expecting to do interesting and challenging work. And the jobs keep being like “make a powerpoint and summarize your results to someone that does not know what a number is”.
deleted by creator
deleted by creator
A lot of the time it’s just an ego trip for the interviewer to show off how clever they are and to gloat over the interviewee when they can’t figure out some really hard problem. This actually fits perfectly with the company having a toxic working environment. When you see these kinds of questions in interviews it’s usually an indication that these aren’t the kinds of people you’d want to be working with.
I code maybe 2 times a year at my job. Every other time I am doing some sort of paperwork to verify features work, or I am using fucking excel. It’s incredibly dull.
I feel you. I spent 48 hours this week streaming shows, waiting for a possible call to some in. I’m sure that’s some people’s dream job, but it drives me nuts that I have to be on site for no reason. I like the feeling I get from actually working and the sense of accomplishment it gives you
I love working from home. I game all day. But man I miss my service industry jobs for how much satisfaction they could give but the trade off is high levels of stress.
Make the user search for this button depth-first
Sometimes the customer throws out insane shit you have to talk them down from though. https://m.youtube.com/watch?v=BKorP55Aqvg
As wise people
saidwrote:
Don’t talk them down, but also don’t follow insane shit
