4 ms·

I suspect there's an additional factor incidental to the "skills and talent" issue- the ability of employees to care. I would wager that there are few engineer

I suspect there's an additional factor incidental to the "skills and talent" issue- the ability of employees to care. I would wager that there are few engineers who are really, truly passionate about Oracle or Salesforce, but for some reason people still get excited about Google, Facebook, or the next Uber-for-dogs startup. This means that the latter category get an entirely different kind of value from the skills of their engineers. If you're a good programmer, you can optimize for various different things- getting something done quickly, writing pretty code, making the boss happy, following every last implied detail of spec, or, importantly, making the software as useful as possible. What you need is for an engineer to be able to think, "well, bossman won't necessarily like it and it will take another ten minutes, but I should write this in this specific way because I predict it will prevent some problems if this code gets reused in certain contexts." There are innumerable small things engineers can do solve problems that might happen, but no salary can incentivize them to do this (or even to look for the opportunities to do so) since there's effectively no way to tell if they're doing it- engineers who don't care will likely be optimizing for making their bosses happy, so engineers who do care will even often seem worse according to any effectiveness metric the company employs. And if your employees don't care, you quickly accumulate technical debt that weighs down the company, even if everyone is happy and productive. I don't particularly think there's a solution to this. A sad fact about industrial economies is that a whole lot of boring things that no one cares about need to get done. Even most of the applications that are exciting now will be boring in the future (someday, internet search will be an old-hat, commoditized field everyone takes for granted, and Google will fall.) Maybe someday company lifecycles will just be considered a fact of nature, and everyone will simply expect the next Microsoft to roll over and expire when its flagship product becomes irrelevant; it might make things more sane.

braveo 10y ago
I don't necessarily agree with software people solving problems that might happen unless they have a lot of experience in the domain. Do the simple thing and if you're wrong then you have less work to throw away.
- tonyedgecombe 10y ago
  I'm not sure it's about adding unneeded features, rather stuff like not ignoring returned error codes or failing to write a unit test for something that needs it.
- maxander 10y ago
  Experience with the domain doesn't need to have much to do with it- most of what I mean by "problems that might happen" are just pure software maintenance issues. Perhaps your new function gets a value that you know can't possibly be null; you don't need to write a check for null, then, since it will still always work. But a good software developer might feel untidy leaving unchecked data into code that might be later reused by null-value-using colleagues, and will take the two seconds to write the check. Furthermore, if he doesn't write the check and this turns out to be wrong, "just throw it away" isn't an immediate option; finding and fixing the error caused could take orders of magnitude more time.
mathattack 10y ago
Caring (alternatively called engagement) is huge. Employees who care are curious enough to dig beyond their day job. And learn about their customers. And are willing to push back on authority when they know that they're right. The systems at very large public companies drive this behavior out of employees. (They value standardization and defending the existing business too much)
- dasil003 10y ago
  Agreed. However the issue is quite a bit more subtle because the larger the company the harder it is for employees to have the big picture on a purely logistical level. So it's not necessarily true that employees pushing back are right. That's not to say existing management structures are optimal. A big part of what the latest breed of tech giants has done is really optimize the culture to be able to get the best out of large teams of engineers, who themselves are force multipliers via code. The computers are essentially like perfectly obedient slave labor. In the old days you always needed a lot of man power, so the biggest organizations were all about rigid command and control structures and policies that would enable a large organization to function. Sometimes these organizations were defacto distributed systems with multi-month latencies (eg. The British Empire). Under that environment it's just not viable for individuals to question procedures on a regular basis or the whole thing breaks down. What companies like Facebook have done is come up with an organizational architecture that can use the perfect labor of computers to break through to a level of impact that could not be achieved by a human-powered organizations. There's probably still an upper limit to efficiency, but it's orders of magnitude higher given the right engineering leverage and culture.
  - mathattack 10y ago
    Agreed. However the issue is quite a bit more subtle because the larger the company the harder it is for employees to have the big picture on a purely logistical level. So it's not necessarily true that employees pushing back are right. Yes - I've seen this too. The bigger the company, the longer you have to be there to understand all the far flung parts.
  - orasis 10y ago
solatic 10y ago
Never say that something can't be measured (at least if it can be observed in the real world...). If engagement manifests as pushback, then measure pushback. If employees are only working according to spec, then product ownership is effectively centralized with management - instead, increase engineering ownership, back it up by budgeting time for engineering to work on their 20% ideas for the platform, and stackrank the results if needed (big if) by giving bonuses to the most engaged engineers and considering terminating the engineers who won't engage (considering being the operative word here, many perfectly OK reasons why an engineer won't engage which aren't grounds for pushing him out of the team), which would open up spots on the team for engineers who might engage. It's really kind of sad reading HN comments on how "oh it must be the fault of all those crappy engineers." We've all met those people who couldn't FizzBuzz their way out of a paper bag, but among the rest, most suffer from poor management. The solution to poor management is not running after mythical rock stars, it's better management.

braveo 10y ago

I don't necessarily agree with software people solving problems that might happen unless they have a lot of experience in the domain. Do the simple thing and if you're wrong then you have less work to throw away.

tonyedgecombe 10y ago
I'm not sure it's about adding unneeded features, rather stuff like not ignoring returned error codes or failing to write a unit test for something that needs it.
maxander 10y ago
Experience with the domain doesn't need to have much to do with it- most of what I mean by "problems that might happen" are just pure software maintenance issues. Perhaps your new function gets a value that you know can't possibly be null; you don't need to write a check for null, then, since it will still always work. But a good software developer might feel untidy leaving unchecked data into code that might be later reused by null-value-using colleagues, and will take the two seconds to write the check. Furthermore, if he doesn't write the check and this turns out to be wrong, "just throw it away" isn't an immediate option; finding and fixing the error caused could take orders of magnitude more time.

mathattack 10y ago

Caring (alternatively called engagement) is huge. Employees who care are curious enough to dig beyond their day job. And learn about their customers. And are willing to push back on authority when they know that they're right. The systems at very large public companies drive this behavior out of employees. (They value standardization and defending the existing business too much)

dasil003 10y ago
Agreed. However the issue is quite a bit more subtle because the larger the company the harder it is for employees to have the big picture on a purely logistical level. So it's not necessarily true that employees pushing back are right. That's not to say existing management structures are optimal. A big part of what the latest breed of tech giants has done is really optimize the culture to be able to get the best out of large teams of engineers, who themselves are force multipliers via code. The computers are essentially like perfectly obedient slave labor. In the old days you always needed a lot of man power, so the biggest organizations were all about rigid command and control structures and policies that would enable a large organization to function. Sometimes these organizations were defacto distributed systems with multi-month latencies (eg. The British Empire). Under that environment it's just not viable for individuals to question procedures on a regular basis or the whole thing breaks down. What companies like Facebook have done is come up with an organizational architecture that can use the perfect labor of computers to break through to a level of impact that could not be achieved by a human-powered organizations. There's probably still an upper limit to efficiency, but it's orders of magnitude higher given the right engineering leverage and culture.
- mathattack 10y ago
  Agreed. However the issue is quite a bit more subtle because the larger the company the harder it is for employees to have the big picture on a purely logistical level. So it's not necessarily true that employees pushing back are right. Yes - I've seen this too. The bigger the company, the longer you have to be there to understand all the far flung parts.
- orasis 10y ago

solatic 10y ago

Never say that something can't be measured (at least if it can be observed in the real world...). If engagement manifests as pushback, then measure pushback. If employees are only working according to spec, then product ownership is effectively centralized with management - instead, increase engineering ownership, back it up by budgeting time for engineering to work on their 20% ideas for the platform, and stackrank the results if needed (big if) by giving bonuses to the most engaged engineers and considering terminating the engineers who won't engage (considering being the operative word here, many perfectly OK reasons why an engineer won't engage which aren't grounds for pushing him out of the team), which would open up spots on the team for engineers who might engage. It's really kind of sad reading HN comments on how "oh it must be the fault of all those crappy engineers." We've all met those people who couldn't FizzBuzz their way out of a paper bag, but among the rest, most suffer from poor management. The solution to poor management is not running after mythical rock stars, it's better management.