|
|
|
|
|
|
by Tommabeeng
5250 days ago
|
|
|
"Improving the productivity of a software team is hard. It involves understanding the business, the team, the history, the obstacles blocking progress. It is a complex, context-sensitive problem." TRUE. Hiring more devs won't solve the complexity problem unless you happen to lasso a few certain devs with the right experience, perspective and willingness that can identify the true core of a problem and solve it fully and with expedience. Sadly many ("smart", "rock star") devs I've seen are content with shortcut, local maxima solutions that only buy a little bit of time before the team starts hurting again. I don't know why this is. Maybe b/c it's more fun (or feels safer) to code and produce behavior than to do the vigilant things required to stave off complexity. But this is a suicide run -- you feel the wind in your hair b/c you're hacking, coding, etc. but you're actually just running back and forth exhausting yourself and not pushing the line forward as fast as you hope. Don't let this evoke The Tortoise and the Hare fable. The team that does development right will be less like a tortoise and more like an elephant. Ground speed somewhere in between the tortoise and the hare, wise, and pushing the line at the greatest speed. |
|
|
General intelligence is a necessary condition, but far (very, very far) from a sufficient one for being a good programmer. Most of the inept developers I've met have been smart. Intelligence wasn't the problem.
This is why I hate Java and C++. Because it's impossible to evaluate code for quality in these languages at 200-500 LoC (while you can easily do this in Python or Scala) you can't hire based on code samples. So you have to hire based on general intelligence + interviewing skill and you end up with about 15% of your team being outright duds (worse yet, intellectually brilliant and persuasive duds because they passed your hiring process, but still bad programmers and dismal architects) even if you're extremely selective.