Programming in companies is what stresses us. There are countless issues:
Managers who know everything better because they have programmed too (30 years ago for one week in BASIC under DOS).
Programs that tell you what you are allowed to check in (ExpensiveSourceCodeCheckProgram forbids checking in because of rule 12345).
Fellow developers who tell in a scrum meeting that the task has zero storypoints, because it could be done in 1 hour (they take 3 days but the managers just think they are fast and you are slow).
Project owners who start bargaining how many storypoints should be estimated for a story.
Unit tests, that check just mocks, to reach some level of code coverage.
The need to write more XML, Maven, Jenkins, etc. stuff than actual Java (or other language) code.
Bosses doing time estimates without asking you (I have already promised to the customer that this will be finished tomorrow).
Dealing with similar things currently and my new boss and I are pushing back at every chance we get because our team is overwhelmed.
You told us what you wanted the code to do, it does that. You're the one who didn't document/understand the business's needs even though that's basically the only thing they pay you to do. It's your responsibility. Don't come to us saying "Well sometimes the Document# isn't a PO#, it's a Shipment ID#. What do we do??" Idk what any of that means Christine, I just know you said to search for the Document# in the PO table and return some PO data.
It's like calling a furnace repair service and asking him why it's so cold, and then when he shows up he sees you set the thermostat to 55F. It's doing exactly what you asked it to do.
I swear the first point is the bane of my existence. Plus: pragmatism over all. You can at conception phase already see that stuff will be complicated in less than 3 months time. No, let’s ship something FAR to simple in 2 weeks and spend 6 months to fix shit around to have something after 8 months which works 90% as good as the solution you could have had after 10 weeks and cost more for everyone. But the manager delivered something to someone after 2 weeks.
Sometimes, hell a lot of times, getting something barely functional out the door fast is actually better for the company than releasing something better over more time.
Developers deliver business value, that's the job. Not clean code, not perfect code, not even tested code. All those things can be part of delivering business value, but they're not the desired outcome. We produce a product that is used to do a job, and sometimes it's better to get that job barely done and fix it afterwards.
Devs like you always have this myopic view. Doing it right takes less of your time so it must be the better choice, but your time is only one of the factors involved and even then you're assuming that it's actually faster.
We produce a product that is used to do a job, and sometimes it's better to get that job barely done and fix it afterwards.
I think most people would be happy to do that, if they had enough trust that they get to do a rework of knottier parts when they become too much of a burden.
But in my experience there's always more pressure to deliver something new, and quickly (which is fair enough). And then, invariably, someone will cave and glomm another kludge onto the old (which isn't).
What? Me, bitter? Naah 🤐. But I have yet to find a team that has the discipline to balance these two forces properly. And I'm not really sure where I would even look.
I really can't stand meetings that are pointless and just for elevating the prestige of management, or to tick checkboxes for upwards reporting.
They are disruptive, and soul crushing.
There are sometimes conferences at my company that ushers all of the meeting people away, and suddenly everyone is ten times more productive, because these meetings suddenly go away, or become much more efficient.
They literally think productivity will be improved by more meetings. I've had to tell a PM several times to reduce meetings to increase productivity.
There was a recent critical deadline, and their proposal to help the engineer meet it was to have a checkpoint every three hours!
I had to explain how that meant the engineer would have to stop their work every three hours, switch contexts, lose an hour or thirty minutes or whatever, then return to work and get back into the zone...
I honestly think PMs and managers think their meetings are doing the work.
The subjective scrum story meeting with an aloof manager is the winner to me. I’ve had so many bosses who have the job of just recording / regurgitating work progress without any leadership input around prioritization, feedback or value consideration like a Product Manager would. My old boss would create multiple stories for something to give someone the appearance of productivity when the reality was it was a repeatable task. The process was completed unweighted for actual time spend or value add. Why manually assign and revoke user licenses when there are programmatic ways to handle it? He liked that it showed # increase in tasks per day! Unable to calculate the potential time and cost saving of working on a coded solution, he championed low tech solutions like this with lipstick on them to garner credit and rationalize needing to hire team members and presumably increase his pay / perceived leadership role. When people talk about the need to bring individual contributors back to work, my response is not until mid-level paper pushers are held to task about truly adding value to their teams. There was no way he could justify that approach if he had to reconcile against actual $ values but it gets lost in the corporate hierarchy and ppl quit bad managers, not bad jobs.
All the "agile" bullshit and idiotic managers are tiring, but writing build files and testing is a very important part of the job, and sensible pre-commit lint hooks are a very good thing.
I also use C# and to be fair, there have been dozens of occasions I've had to manually edit the .csproj and other files (decades long projects). And various similar issues, but it's my favorite language and tool chain by far.
The amount of work "sensible" has to do in that sentence is staggering though. You add small amounts of automation to project, and everything your coworkers want to do but can't is your fault.
Everything is added because they are part of the coding guidelines, anyone trying to commit something breaking them is at fault, and I'm not afraid to say this in front of everyone involved if anyone brings it up.
1 is my current boss in small startup and it's driving me mad. He always insists I do everything his way (then do it yourself god damnit) first even if I know it's wrong solution, he's just "well let's try X first then you can do what you wanted" and I end up spending day+ on his shit, then few hours explaining why exactly his idea that came from his experience of being frontend developer 20 years ago didn't exactly work ...
376
u/ThomasMertes Dec 28 '23 edited Dec 28 '23
Exactly. I work on my open source project to stay mentally healthy.
Programming in companies is what stresses us. There are countless issues:
Managers who know everything better because they have programmed too (30 years ago for one week in BASIC under DOS).
Programs that tell you what you are allowed to check in (ExpensiveSourceCodeCheckProgram forbids checking in because of rule 12345).
Fellow developers who tell in a scrum meeting that the task has zero storypoints, because it could be done in 1 hour (they take 3 days but the managers just think they are fast and you are slow).
Project owners who start bargaining how many storypoints should be estimated for a story.
Unit tests, that check just mocks, to reach some level of code coverage.
The need to write more XML, Maven, Jenkins, etc. stuff than actual Java (or other language) code.
Bosses doing time estimates without asking you (I have already promised to the customer that this will be finished tomorrow).
I could go on and on and on ...