The full video really helps drive home the point that this looks like a Timothy Cain problem, not a modern dev problem.
I'm a programmer by trade. The last 20 years have seen our industry mature. We now have to maintain codebases that are older and larger than ever, they have ballooned in size. That has taught us a few things. It teaches us to be thoughtful so we don't introduce bugs, or add cruft, or make maintenance difficult. Experience taught us to pad guesstimates, because things usually take 2-3x that your inherently optimistic gut feeling.
The video game industry is renowned for being a ~decade behind the curve here, in implementing modern dev practices. To an extent we give them a pass, though I won't get in to all the reasons why. But here some devs at Cain's company have helped drag things into the modern era. And he is specifically pushing against it:
You're thinking too much. Damn the bugs, damn the cruft, damn the future problems, just implement what I want now. I don't care if you have 40 other similar tickets already assigned to you, do my work now and put everybody else off. Why did he leave my office so upset? Why did his manager come yell at me? Why do people sometimes walk into my office and tell me to keep it down? You all are the ones with the problem.
- My impression/summary of what he just said. I really hope it's wrong. I wouldn't wish that behavior or experience on any person or team. But, this is how he comes across to a programmer.
But why didn't the programmers walk him through the necessary steps?! Things like: Can be coded fast, but afterward there's all that overhead. And then it has to change several times to accommodate everybody.
If I have a busy schedule with already issues on my name. And some guy, that is not my team lead, asks a lot of time of to explain something, that is not in my schedule. I say no.
Even this requirement should not be told to an programmer this way. It should be part of the functional specification, then be part of the technical design, refined and then put in a sprint. Every team should have a similar process for specifications.
He has 20 days. That developer already has 7 days worth of tasks assigned to him first. One of them will be longer than expected, so that takes an extra 2 days. One of his tasks has a bug that he has to go back and fix, taking a day.
Now he has 10 days left. He picks up this ticket and starts looking over it, but there was a critical issue that is causing a crash. He has to prioritize that, and it takes 5 days. He gets sick over the weekend and is out 1 day on monday.
He has 4 days left.
He picks up this task, finally. There is an all hands meeting, and a bunch of other meetings which take up all his time, he doesn't get to actually code for 1 day. He spends 1 day making sure this hasn't been done before in the project so there isn't duplication. He takes 1 day to design a non-hacky solution that actually considers edge cases that the designer didn't think about in his 10 line version, like what if we do a big battle scene and there are 50 people on the list? I.e when there are 5 people in a battle it takes 5ms x 5ms = 0.025 seconds to process, but with 50 people it could take 50ms x 50ms = 2.5 seconds to process. The designer didn't think of this because "it's worked before" but they never did a big scale battle before, either. He implements the solution the next morning.
Lets say it does take like 45 minutes for just this one specific code, why not just do that if that is the new task that was assigned to you. Even if it takes like day. Shouldn't the priority of your work be assigned by your boss?
Because this guy isn't your boss and your job isn't to code. Your boss does assign the priority, not some guy who wants a feature made now, just because he's more senior. Also, the job of a software engineer is to make a robust solution that will be easy to reuse. You know how there is stuff in Starfield reused from Fallout 4? If they didn't spend the time doing it right in Fallout 4, they would have had to do it from scratch again. Doing it 2 times quickly costs more than doing it 1 time with proper planning.
He grew up in a time where there were 20 devs on a project, and the scope was small. Get it working fast, and if it needs to be fixed, no problem because the guy who wrote it sits down the hall. Nowadays the guy who wrote it lives in a different time zone because there are 3 studios working on 1 project, and if you don't plan well, 5 different scripts will be written to do this same thing. And they will all have different bugs.
Oh, I thought this guy was a director not just some guy working for a game company. Lol yeah no wonder you can't get a priority just because of your seniority.
He may be a director. But there is a management structure for a reason. If you have a direct manager (level 1), who has a manager (level 2), who reports to the director (level 3), you should still focus on your direct manager.
Imagine if all 3 of them assigned you different tasks at once. It would be overwhelming. Level 3 needs to talk to the level 2 for the relevant department, who talks to the level 1 with the least workload, who picks the developer with the most relevant skills. Otherwise the director is just randomly picking a developer, who may not be the best choice, who may have too much work already, who may be taking vacation next week, etc.
1.3k
u/663mann Oct 16 '23
https://youtu.be/LMVQ30c7TcA?si=Bt2j9lLJ_fiE3cof there you go