3 ms·
When I got the call to fix this dilemma literally a couple of weeks before release, the simple act of cleaning up the source control server, and purging these u
by EliRivers 9y ago
When I got the call to fix this dilemma literally a couple of weeks before release, the simple act of cleaning up the source control server, and purging these unneeded cache files from source control, fixed this audio issue that was plaguing them for months and had costed the company tons of money and time.
This sort of thing drives me insane (or at least used to; my current colleagues, from junior to senior, are all actually pretty good). This is something that everyone knows, just by looking at it, is a bad thing. Everyone who saw this must have known it wasn't a great idea, even if they didn't know why. Even without being able to elucidate why, everyone (should) get the feeling that having these things in the repository is asking for trouble; I'd expect a junior to have at least a bad feeling about it, and a senior to be able to specify what kind of problems it could cause. I don't know about the exact circumstances, of course, but it's even surprising that nobody found this problem while they were investigating. I've certainly gone as far as "are we definitely using the exact same binary files on the different systems?" when chasing odd problems that only manifest on some installations and not others, so what went so wrong that nobody got that far in their debugging?
So unless the company in question had by chance a room full of people with this particular massive blind spot, people saw this happening and they knew it was a bad idea and they didn't do anything about it. Culture failure. I don't know why. Maybe they were afraid to mention bad things because pointing out possible problems is seen as not being a team player. Maybe they were just so sick of it all they didn't care anymore. Maybe there were a couple of forcefully strong people in charge of the repository who saw any question as a personal attack and people were just sick of dealing with the egotistical prima donnas. Maybe the process for doing anything about it was laughable painful and went through someone who would shoot it down on the grounds that we're so busy firefighting things that are broken and you want to waste time tinkering with something that looks fine to me?
If Allar is reading, could you say a few words about this? How many times do you get called in to fix something that could have been averted with a decent programming culture, even if the specific technical chops weren't there? We've all seen teams with good culture deliver software that they really didn't know how to build when they started through good culture, and we've all seen teams of people who all know what they're doing deliver a flaming wreck because the culture was a disaster. How often are you called in to deal with something that the existing team really couldn't have foreseen without some particular piece of specific knowledge or experience, and how often is it something that they could have dealt with months ago if they had just been allowed and guided to work sensibly and professionally?
- Allar 9y agoLiterally no engineers were allocated to the issue and majority of the project. 20% of the time I work on novel unforseeable issues. R&D and future tech stuff. 80% of the time its culture, professionalism, and generally "are you fucking serious" issues. I've dealt with literally every situation you've described however. Just because this particular reason was that there were no engineers, you could swap in any other situation and still have a true story.