6 ms·

Nice start, OP (especially with unclear specs, my personal pet peeve), but you've only hit upon the tip of the iceberg. Just a few other things I call "work pr

by edw519 12y ago

Nice start, OP (especially with unclear specs, my personal pet peeve), but you've only hit upon the tip of the iceberg. Just a few other things I call "work prevention" that make good developers appear to be slow: - unclear specs - context switching - peer review (both giving & receiving) - code review - status meetings - waiting for others to show up at meetings - others not prepared for meetings (no agenda, etc.) - unnecessary but enforced standards (stupid, pointless) - programs locked by other devs (get in line) - pre-existing technical debt (must be fixed before amended) - framework can't handle it - works but won't scale - can't recreate bug - platform issue (server, DBMS, etc.) - environmental issues (test server out of date) - waiting for server resources (testing) - waiting for regression tester - waiting for user acceptance testing - specs changing during user acceptance testing - uncontrolled deployment "freezes" (month-end, release schedule) - noisy office - meetings when emails would have sufficed - phone calls when emails would have sufficed - text messages when emails would have sufficed - continually changing priorities - delays in offshore communications - lack of training (technology) - lack of training (business subject matter) - too much training (HR bullshit) - not enough donuts

humanrebar 12y ago
- nonexistent or substandard tools ...including old compilers and otherwise a lack of support for the compilers, debuggers, editors, analyzers, profilers, etc. that will enable a developer to focus on business problems instead of technology stack problems.
- ultimape 12y ago
  After a long enough period of time, this can solidify as the more frustrated developers leave and all you have left are developers who are happy slogging through inefficient processes. Anthropology of corporate cultures is fascinating: http://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner http://www.daedtech.com/how-developers-stop-learning-rise-of...
humanrebar 12y ago
- waiting for regression tester Or worse, a lack of regression testing requiring substantial software archaeology in order to be confident enough to make a change to legacy code. Similarly: - substandard documentation
logfromblammo 12y ago
- reinventing the wheel because a perfectly serviceable existing solution cannot be licensed I can't stand hearing that there's no room in the budget to pay a flat $500 to license a 3rd-party grid control (for example) only to have a $90k/yr salaried developer spend 20 or more hours recreating barely a tenth of its features. It's even worse when the license is free (as in speech), but it still can't be used, because the code hasn't been blessed by the security department, or because management simply has a prejudicial bias against the terms of the LGPL.
- valarauca1 12y ago
  Or management that continues to blindly believe everything that is free on the internet is absolutely worthless in terms of quality and support. And forces you to clone already existing freeware tools -_-
- stouset 12y ago
  On the flip side, as one of those guys in the security department, it aggravates me to no end when developers can't understand why we won't allow them to open up direct production database access to some unheard-of SaaS startup that's been in existence for a total of a month.
  - logfromblammo 12y ago
    While you present a reasonable example of why certain things have to be cleared before implementing them, most of the time you are used as an excuse to issue a knee-jerk denial of some suggestion, without even bothering to consult with you first. And people at other companies are not necessarily as competent or diligent as you are about doing your job. Usually, the argument goes like this: - We cannot use X until it has been cleared by legal and/or security. - Legal and/or security do not have the resources available to clear X for our use within a time span that would allow X to be useful. - As a result, we won't even ask them to try. - Therefore, screw you, nerd. Alternately: - We don't have room in the budget to license X. - The budget won't change until after the end of the project. - We can't justify altering the budget to accommodate licensing X unless it would be useful for an ongoing project. - You won't be allowed to comment on upcoming projects until after the budget is fixed. - Therefore, screw you, nerd. Or in the worst case: - Here is a detailed proposal to use invented-elsewhere thing X in our product Y, with gobs of research and references, and oodles of possible pros and cons. - We don't understand what you are talking about. - So we're going to fixate on some tiny, mostly-irrelevant detail, and then blather about it until you go away. - Therefore, screw you, nerd.
deleted 12y ago
[deleted]
UK-AL 12y ago
If a feature isn't tested, or proved useful to a user is it really progress?
thinkmassive 12y ago
- underpowered hardware At my previous job I requested an upgrade from a 3 year-old laptop. Initially they approved it, but before ordering one they reversed and denied my request. The justification was they'd spent too much outfitting new hires and it was no longer in the budget, despite my request coming long before the interview process started for the new hires. To make it worse, the new hires were entry level and I had the second longest tenure at the company (~90 people). Now I work somewhere that happily provides every technical employee with the latest maxed out hardware. The difference in amount of work accomplished is staggering.
- atom-morgan 12y ago
  > The difference in amount of work accomplished is staggering. It's a shame this isn't more obvious. I was recently given an old laptop at work as well. So old, that it took 7+ seconds from the time I clicked "Inspect Element" in Chrome for the window to open. It was weeks before a purchase for RAM was made.
- Zikes 12y ago
  I'm doing development work on a 5 year old laptop with 4GB of RAM. I constantly have performance issues, so I put in a request to bring me up to 8GB of RAM at a cost of $73. My manager says "is it really worth it if you're getting a new machine in four months?" Well, I guess that just depends on how productive you expect me to be over the next quarter.
  - dmd 12y ago
    Can someone with more business knowledge than me explain this? Like... you'll pay a developer $100 an hour, but then you ask them to spend an hour in a meeting to justify the purchase of a $50 widget that will save them an hour a day for the next year. There must be some twisted logic at work, but I don't see it.
    - smhinsey 12y ago
      I've been in situations where it basically boils down to hierarchy and reinforcement of the status quo. I once had a request for a new laptop refused because it would've meant mine was newer than the president/owner's machine and that wasn't tolerable to the corporate ego.
mijustin 12y ago
Thanks! I agree, there's a handful of these issues I'd planned on talking about in future posts; but your list adds a bunch more I hadn't thought of. Lack of training is a tricky one, isn't it? If you give the wrong kind of training, or too much, or too little, it's easy to miss the mark.
tempVariable 12y ago
Ed, Can you elaborate on peer review and code review ? I have worked with and without these steps and can quantify the hours required and the quality shift in having these steps. Do you think that these two can be disconnected from the development workflow with acceptable consequences? Or is it that there might be other standards or development measures which are no being met, such that there IS a need for review ?

by edw519 12y ago

humanrebar 12y ago

- nonexistent or substandard tools ...including old compilers and otherwise a lack of support for the compilers, debuggers, editors, analyzers, profilers, etc. that will enable a developer to focus on business problems instead of technology stack problems.

ultimape 12y ago
After a long enough period of time, this can solidify as the more frustrated developers leave and all you have left are developers who are happy slogging through inefficient processes. Anthropology of corporate cultures is fascinating: http://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner http://www.daedtech.com/how-developers-stop-learning-rise-of...

humanrebar 12y ago

- waiting for regression tester Or worse, a lack of regression testing requiring substantial software archaeology in order to be confident enough to make a change to legacy code. Similarly: - substandard documentation

logfromblammo 12y ago

- reinventing the wheel because a perfectly serviceable existing solution cannot be licensed I can't stand hearing that there's no room in the budget to pay a flat $500 to license a 3rd-party grid control (for example) only to have a $90k/yr salaried developer spend 20 or more hours recreating barely a tenth of its features. It's even worse when the license is free (as in speech), but it still can't be used, because the code hasn't been blessed by the security department, or because management simply has a prejudicial bias against the terms of the LGPL.

valarauca1 12y ago
Or management that continues to blindly believe everything that is free on the internet is absolutely worthless in terms of quality and support. And forces you to clone already existing freeware tools -_-
stouset 12y ago
On the flip side, as one of those guys in the security department, it aggravates me to no end when developers can't understand why we won't allow them to open up direct production database access to some unheard-of SaaS startup that's been in existence for a total of a month.
- logfromblammo 12y ago
  While you present a reasonable example of why certain things have to be cleared before implementing them, most of the time you are used as an excuse to issue a knee-jerk denial of some suggestion, without even bothering to consult with you first. And people at other companies are not necessarily as competent or diligent as you are about doing your job. Usually, the argument goes like this: - We cannot use X until it has been cleared by legal and/or security. - Legal and/or security do not have the resources available to clear X for our use within a time span that would allow X to be useful. - As a result, we won't even ask them to try. - Therefore, screw you, nerd. Alternately: - We don't have room in the budget to license X. - The budget won't change until after the end of the project. - We can't justify altering the budget to accommodate licensing X unless it would be useful for an ongoing project. - You won't be allowed to comment on upcoming projects until after the budget is fixed. - Therefore, screw you, nerd. Or in the worst case: - Here is a detailed proposal to use invented-elsewhere thing X in our product Y, with gobs of research and references, and oodles of possible pros and cons. - We don't understand what you are talking about. - So we're going to fixate on some tiny, mostly-irrelevant detail, and then blather about it until you go away. - Therefore, screw you, nerd.

deleted 12y ago

[deleted]

UK-AL 12y ago

If a feature isn't tested, or proved useful to a user is it really progress?

thinkmassive 12y ago

- underpowered hardware At my previous job I requested an upgrade from a 3 year-old laptop. Initially they approved it, but before ordering one they reversed and denied my request. The justification was they'd spent too much outfitting new hires and it was no longer in the budget, despite my request coming long before the interview process started for the new hires. To make it worse, the new hires were entry level and I had the second longest tenure at the company (~90 people). Now I work somewhere that happily provides every technical employee with the latest maxed out hardware. The difference in amount of work accomplished is staggering.

atom-morgan 12y ago
> The difference in amount of work accomplished is staggering. It's a shame this isn't more obvious. I was recently given an old laptop at work as well. So old, that it took 7+ seconds from the time I clicked "Inspect Element" in Chrome for the window to open. It was weeks before a purchase for RAM was made.
Zikes 12y ago
I'm doing development work on a 5 year old laptop with 4GB of RAM. I constantly have performance issues, so I put in a request to bring me up to 8GB of RAM at a cost of $73. My manager says "is it really worth it if you're getting a new machine in four months?" Well, I guess that just depends on how productive you expect me to be over the next quarter.
- dmd 12y ago
  Can someone with more business knowledge than me explain this? Like... you'll pay a developer $100 an hour, but then you ask them to spend an hour in a meeting to justify the purchase of a $50 widget that will save them an hour a day for the next year. There must be some twisted logic at work, but I don't see it.
  - smhinsey 12y ago
    I've been in situations where it basically boils down to hierarchy and reinforcement of the status quo. I once had a request for a new laptop refused because it would've meant mine was newer than the president/owner's machine and that wasn't tolerable to the corporate ego.

mijustin 12y ago

Thanks! I agree, there's a handful of these issues I'd planned on talking about in future posts; but your list adds a bunch more I hadn't thought of. Lack of training is a tricky one, isn't it? If you give the wrong kind of training, or too much, or too little, it's easy to miss the mark.

tempVariable 12y ago

Ed, Can you elaborate on peer review and code review ? I have worked with and without these steps and can quantify the hours required and the quality shift in having these steps. Do you think that these two can be disconnected from the development workflow with acceptable consequences? Or is it that there might be other standards or development measures which are no being met, such that there IS a need for review ?