2 ms·
To add to this a bit, one thing that I haven’t noticed anyone talk about is that to a huge degree, programmers are supposed to manage themselves. It may not see
by Bukhmanizer 6y ago
To add to this a bit, one thing that I haven’t noticed anyone talk about is that to a huge degree, programmers are supposed to manage themselves. It may not seem like it to those who have worked in tech for a while, but as someone who is in a different field where it’s not the norm (Academia), it makes a big difference in efficiency.
In my corner of academia, programming is almost always seen as grunt work and delegates to undergrads and junior grad students. Of course students aren’t trusted to actually manage the project so usually mid-level scientists or post-grads are assigned to oversee and manage them. The managers usually have no idea how to program or what it entails, nor do they have any interest in the project. At most they’ll want to use the software after its finished. If agile/waterfall programming annoys anyone, just be thankful you have a methodology for software development at all. Since literally everyone is senior to the programmer, but nobody else knows how to program, everyone just justifies their time by suggesting new features. Since no one knows how long anything should take, all new features are accepted into spec at anytime. Eventually, the project starts to run long, and since nobody knows why, management responds by adding more layers of management. Finally, the programmer either quits or graduates and the grant for the project runs out. The final product usually either has no resemblance to the proposal or only works on sample data. If it’s a website, no one bothers maintaining the server. If it’s a package, all dependencies go out of date within a year of release. The PI, or a PI down the hall gets a new grant to do basically the same project again, and the cycle repeats itself.