4 ms·

Here is a point I made at that blog...One very small piece of this puzzle I haven’t read here…I work for a global investment bank and here we manage risk. Payin

• ecuzzillo 20y ago
  I wouldn't say you're screwed. I'd say you just need to get another equivalently high-powered person to sub in. It'd take them a while to load the code into their head, but so does any replacement programmer. And, if you do know how to get Eric, getting just one more is probably not that hard.
  • jullrich1 20y ago
    ecuzzillo, your point is valid but in the environment of a large company, hiring can take months, there is a huge administrative expense associated with the hiring process and the top 1% is still the top 1%...hard to find even if you had already found the first Eric.
    • ecuzzillo 20y ago
      In the environment of a normal large company, the giant administrative expense of hiring people (and in general the suckiness of being in a big company) is a far bigger problem than trying to find a good programmer.
• Elfan 20y ago
  I think that ties into what the author said about the advantage of mediocre teams for long term projects. Its sometimes better to having something kludgy and understandable than an elegant hack that no one else will understand.
  • andrewcooke 20y ago
    You're presenting a false dichotomy. You don't get smaller code by making it incomprehensible. It gets smaller because it's cleaner and clearer. Think of the problem in terms of compression. You can compress via syntax or by semantics. In the first case you end up with gzip and an unreadable compact mess. In the second you end up with a better, more elegant program, expressed via core, largely orthogonal concepts. For some reason you seem to think that a good programmer works like gzip. That's simply wrong.
• greendestiny 20y ago
  Of course the other side of that is the fairly common situation where someone in the team of 5 is doing 5x the work for 1x salary, and management has no idea until months (if ever) after they leave...