5 ms·

Businesses always claim to value developer productivity, but this is rarely accurate. Usually it’s the stellar opposite of productive despite what they claimed

Businesses always claim to value developer productivity, but this is rarely accurate. Usually it’s the stellar opposite of productive despite what they claimed during hiring. Honestly, if they really let me take the gloves off I could easily replace 4-8 other developers. I am not saying that due to arrogance or some delusion. I just value other qualities than most other developers. Usually it’s not that I am fast or anything impressive but that the company is a drowning self-licking ice cream cone. Things get much faster when you get rid of all the framework bullshit, unnecessary process, and focus purely on business requirements and smallest possible delivery. Most of the bullshit (the stuff really slowing you down) that’s in place isn’t there because the business wants it, but because the developers want it. These are things you realize when managing a side project because your time is important to you and the person you answer to is yourself. What’s super frustrating is how awesome that always sounds in an interview and how much the hiring team really appreciates those concerns and that level of honesty. Then once you get the job it’s just the same old slow safety mitten insanity as everywhere else.

news_to_me 8y ago
> Most of the bullshit (the stuff really slowing you down) that’s in place isn’t there because the business wants it, but because the developers want it. Do you have examples of this? It sounds contrary to my experience.
- throwawaymlc 8y ago
  I've often seen developers invent elaborate JIRA workflows and pre-checkin validation workflows that slow development to a glacial pace. Also, JIRA / other ticketing workflows can take on a life of their own - at some point, many developers seem to realize that it's easier to describe defects and potential fixes, spend time categorizing, prioritizing, assigning tickets for doing things than it is to ever actually do them.
- austincheney 8y ago
  Here are some examples: * spaces versus tabs and then rejecting a code commit because of white space or other draconian rules not related to any business justification. * Whether or not a code update performs actions in certain ways, such as specified methods over other methods, without a valid business justification. Normally this appears to be some manner of code style rule. * Rejecting code that uses functions or makes use of lexical scope instead of OOP. * Rejecting code that doesn't make use of the framework even when that particular existing code file doesn't make use of the framework. * Rejecting code that bypasses the framework even though it is a new effort in new files, thus no regression, and has supporting tests. * Rejecting code because the diff is intimidating. * really long build cycles so that a developer can use their favorite framework or tool * A minor tiny module that requires a million dependencies sets off a warning or conflict in your code at build time and requires you to dive under the hood even though the problem is exposed from some horrid dependency. --- If I thought about this more I am sure I could come up with a bunch more. The business never comes to you and mandates you use a popular new JavaScript framework or that the test environment tests for code style and white space. The business doesn't care about this unnecessary stupidity especially if it makes other business requirements, such as security or accessibility, more challenging. The business cares about reducing expenses, retaining users, not getting sued, and generating revenue. You can justify the stupidity with all manner of technical reasons, but in the end does it allow you to perform simple updates in minutes or days? As a developer you are an expense to the business and not a driver of revenue. If you have to justify your limited productivity with a bunch of technical nonsense you are a financial liability.
- xkcd-sucks 8y ago
  At the company I'm with, there is a 6 person team developing a nodejs app that started out as somebody's learning project / MVP through innumerable pivots (the original developers are gone). The codebase has had no significant deletioms over its five year history, only additions in the "3d chess" sense. It is a generic API server and dropbox-clone file uploader client. It requires on call attention because it blows up every time so etching unexpected happens. Meanwhile, the code that does things the business actually sells is written and maintained by one person, and it works pretty well. There have been several significant rewrites / refactors and little process beyond "the campsite rule" and "get stuff (not shit) done"
jaabe 8y ago
I think we teach developers wrong. I recently attended a devops workshop for one of our government agencies, to share knowledge like we do in the public sector, and their setup was quite impressive. At least it was, until it turned out that they had spent 8 people and two years making their toolchain and business processes work. Why would you do that? We’re not Netflix, we’re a country of 5 million. It’s at times like that I like to remind myself of how simple the stackoverflow setup was (still is?), but it also makes you wonder what made it happen. I mean, my municipality could manually deploy and operate hundreds of solutions for a hundred years and still have spent less time than 8 people building and implementing a devops toolchain over a period of two years. Heh. On the bright side, it seems to work well for them now that they have it. A lot of other people have spent the same resources and failed.
- jacobolus 8y ago
  I am not understanding what this means: > my municipality could manually deploy and operate hundreds of solutions for a hundred years and still have spent less time than 8 people building and implementing a devops toolchain over a period of two years.
  - copperx 8y ago
    Likewise, I have no idea what this means: > We’re not Netflix, we’re a country of 5 million.
    - rudigergerm 8y ago
      I think he means that unlike Netflix, they don't serve a market of 150M+ subscribers
    - 0x38B 8y ago
      From a cursory look at his comment history, he's located in Denmark[1] and works in the public sector[2]. 1: https://news.ycombinator.com/item?id=19412779 https://news.ycombinator.com/item?id=19412779 2: https://news.ycombinator.com/item?id=19419308 https://news.ycombinator.com/item?id=19419308
nickdandakis 8y ago
autstincheney, it sounds like you should quit your enterprise (big tech co?) job and work for an early-stage startup.
- austincheney 8y ago
  That does sound exciting.
throwawaymlc 8y ago
I reached this conclusion embarrassingly recently, after a few attempts at increasing productivity rapidly that were not well-received by coworkers. Having thought about it more, it makes sense. Businesses are generally not paying developers by the hour, so why would they care about productivity when they can just pressure people to work extra hours, pretend it's a one-off crunch, make vague promises of future remuneration, or bring onboard inexpensive junior developers to work through their low-productivity processes?
FatDrunknStupid 8y ago
We (100+) were once told NEVER to refactor because the audit people couldn't understand the diffs. The horror.
james_s_tayler 8y ago
Also the same is true for the opposite case where a framework would really speed things up but instead you have to wade through special snowflake implementation marshland leaving your own little trail of destruction for your localized tornado of changes. Safety mitten insanity abounds.
- austincheney 8y ago
  I encounter this argument a lot from JavaScript developers and often it is due to an irrational fear of the technology[1]. Coupled with limited experience the argument becomes its own internal justification where you MUST use the pet framework, because if you don't everything else will become an alternate framework. If your experience is solely limited to configuring particular frameworks this argument makes sense just if you are a hammer everything looks like a nail. The core motivation, in most cases, is to lower risk and re-calibrate for complexity. There are several problems with this line of thinking. First of all, web technologies are very stable at this point. The risks are not in the standard technologies or so much their implementation. This means the risks are actually all in the developer's implementation and the business. As for business risk the solution is to define policy so that requirements are properly formulated and the code result is properly tested. Secondly, complexity is wildly misunderstood. Complexity has nothing to do with easy versus challenging. Complexity is simply putting things together. Simplicity is the progression towards singularity. A solution that calls for a single ugly 5000 line function is three times more simple than a solution that calls for 3 clean and tiny 10 line functions. Once you understand that much of the stupidity is the result of a lack of confidence you are in a much better place to deliver a solution without the stupidity that slows people down. You have to be honest with yourself and accept that code is only available to achieve automation and is always a liability. Once you accept it and own it you immediately alter your goals to the following: 1. Write less code. The best way to lower your liability is to have less stuff to be liable for. This includes the totality of the coded production from your code, to all the abstractions that you configure, and all the dependencies you bring in. 2. Be better at finding imperfections in the product and not the code. One way to do this is to make failure more clear so that you can account for it before shipping the code off to anybody else. I tell web developers to save their HTML with the file extension XHTML and always conform to WCAG 2.0 AA compliance, because then failure is immediate and you really see it with clarity. I also tell them to not use addEventListener because then they are limited to a single handler per event and if they cannot properly manage their code it will fail and that failure is immediately clear. I also tell them to look closer at the standard DOM methods which are generally faster than other conventions by 50x-16000x unless you are search for elements by attribute name/value which is about 16x slower than using a similar query selector. 3. Spend more time up front writing automation so less time is spent doing manual work. It is nice when the documentation is always up to date because it is dynamically generated from the code. 4. Provide complete test automation but not test coverage. Ensure there are tests for every business requirement, configuration, and collection of competing configurations. Prove the application does all it claims, but don't test for anything else. Testing when done wrong wastes your time. To save time ensure you have very many tests, the results are clearly communicated, and they execute as quickly as possible. After all of that and the code performs correctly it becomes far less effort to extend and to push back on stupidity from poorly considered business requirements, because you know your work is always close to perfect. You know this because you have accepted all the related liabilities and addressed them as directly as possible. [1] https://github.com/prettydiff/wisdom/blob/master/Delusional_Developers.md https://github.com/prettydiff/wisdom/blob/master/Delusional_...

news_to_me 8y ago

> Most of the bullshit (the stuff really slowing you down) that’s in place isn’t there because the business wants it, but because the developers want it. Do you have examples of this? It sounds contrary to my experience.

throwawaymlc 8y ago
I've often seen developers invent elaborate JIRA workflows and pre-checkin validation workflows that slow development to a glacial pace. Also, JIRA / other ticketing workflows can take on a life of their own - at some point, many developers seem to realize that it's easier to describe defects and potential fixes, spend time categorizing, prioritizing, assigning tickets for doing things than it is to ever actually do them.
austincheney 8y ago
Here are some examples: * spaces versus tabs and then rejecting a code commit because of white space or other draconian rules not related to any business justification. * Whether or not a code update performs actions in certain ways, such as specified methods over other methods, without a valid business justification. Normally this appears to be some manner of code style rule. * Rejecting code that uses functions or makes use of lexical scope instead of OOP. * Rejecting code that doesn't make use of the framework even when that particular existing code file doesn't make use of the framework. * Rejecting code that bypasses the framework even though it is a new effort in new files, thus no regression, and has supporting tests. * Rejecting code because the diff is intimidating. * really long build cycles so that a developer can use their favorite framework or tool * A minor tiny module that requires a million dependencies sets off a warning or conflict in your code at build time and requires you to dive under the hood even though the problem is exposed from some horrid dependency. --- If I thought about this more I am sure I could come up with a bunch more. The business never comes to you and mandates you use a popular new JavaScript framework or that the test environment tests for code style and white space. The business doesn't care about this unnecessary stupidity especially if it makes other business requirements, such as security or accessibility, more challenging. The business cares about reducing expenses, retaining users, not getting sued, and generating revenue. You can justify the stupidity with all manner of technical reasons, but in the end does it allow you to perform simple updates in minutes or days? As a developer you are an expense to the business and not a driver of revenue. If you have to justify your limited productivity with a bunch of technical nonsense you are a financial liability.
xkcd-sucks 8y ago
At the company I'm with, there is a 6 person team developing a nodejs app that started out as somebody's learning project / MVP through innumerable pivots (the original developers are gone). The codebase has had no significant deletioms over its five year history, only additions in the "3d chess" sense. It is a generic API server and dropbox-clone file uploader client. It requires on call attention because it blows up every time so etching unexpected happens. Meanwhile, the code that does things the business actually sells is written and maintained by one person, and it works pretty well. There have been several significant rewrites / refactors and little process beyond "the campsite rule" and "get stuff (not shit) done"

jaabe 8y ago

I think we teach developers wrong. I recently attended a devops workshop for one of our government agencies, to share knowledge like we do in the public sector, and their setup was quite impressive. At least it was, until it turned out that they had spent 8 people and two years making their toolchain and business processes work. Why would you do that? We’re not Netflix, we’re a country of 5 million. It’s at times like that I like to remind myself of how simple the stackoverflow setup was (still is?), but it also makes you wonder what made it happen. I mean, my municipality could manually deploy and operate hundreds of solutions for a hundred years and still have spent less time than 8 people building and implementing a devops toolchain over a period of two years. Heh. On the bright side, it seems to work well for them now that they have it. A lot of other people have spent the same resources and failed.

jacobolus 8y ago
I am not understanding what this means: > my municipality could manually deploy and operate hundreds of solutions for a hundred years and still have spent less time than 8 people building and implementing a devops toolchain over a period of two years.
- copperx 8y ago
  Likewise, I have no idea what this means: > We’re not Netflix, we’re a country of 5 million.
  - rudigergerm 8y ago
    I think he means that unlike Netflix, they don't serve a market of 150M+ subscribers
  - 0x38B 8y ago
    From a cursory look at his comment history, he's located in Denmark[1] and works in the public sector[2]. 1: https://news.ycombinator.com/item?id=19412779 https://news.ycombinator.com/item?id=19412779 2: https://news.ycombinator.com/item?id=19419308 https://news.ycombinator.com/item?id=19419308

nickdandakis 8y ago

autstincheney, it sounds like you should quit your enterprise (big tech co?) job and work for an early-stage startup.

austincheney 8y ago
That does sound exciting.

throwawaymlc 8y ago

I reached this conclusion embarrassingly recently, after a few attempts at increasing productivity rapidly that were not well-received by coworkers. Having thought about it more, it makes sense. Businesses are generally not paying developers by the hour, so why would they care about productivity when they can just pressure people to work extra hours, pretend it's a one-off crunch, make vague promises of future remuneration, or bring onboard inexpensive junior developers to work through their low-productivity processes?

FatDrunknStupid 8y ago

We (100+) were once told NEVER to refactor because the audit people couldn't understand the diffs. The horror.

james_s_tayler 8y ago

Also the same is true for the opposite case where a framework would really speed things up but instead you have to wade through special snowflake implementation marshland leaving your own little trail of destruction for your localized tornado of changes. Safety mitten insanity abounds.

austincheney 8y ago
I encounter this argument a lot from JavaScript developers and often it is due to an irrational fear of the technology[1]. Coupled with limited experience the argument becomes its own internal justification where you MUST use the pet framework, because if you don't everything else will become an alternate framework. If your experience is solely limited to configuring particular frameworks this argument makes sense just if you are a hammer everything looks like a nail. The core motivation, in most cases, is to lower risk and re-calibrate for complexity. There are several problems with this line of thinking. First of all, web technologies are very stable at this point. The risks are not in the standard technologies or so much their implementation. This means the risks are actually all in the developer's implementation and the business. As for business risk the solution is to define policy so that requirements are properly formulated and the code result is properly tested. Secondly, complexity is wildly misunderstood. Complexity has nothing to do with easy versus challenging. Complexity is simply putting things together. Simplicity is the progression towards singularity. A solution that calls for a single ugly 5000 line function is three times more simple than a solution that calls for 3 clean and tiny 10 line functions. Once you understand that much of the stupidity is the result of a lack of confidence you are in a much better place to deliver a solution without the stupidity that slows people down. You have to be honest with yourself and accept that code is only available to achieve automation and is always a liability. Once you accept it and own it you immediately alter your goals to the following: 1. Write less code. The best way to lower your liability is to have less stuff to be liable for. This includes the totality of the coded production from your code, to all the abstractions that you configure, and all the dependencies you bring in. 2. Be better at finding imperfections in the product and not the code. One way to do this is to make failure more clear so that you can account for it before shipping the code off to anybody else. I tell web developers to save their HTML with the file extension XHTML and always conform to WCAG 2.0 AA compliance, because then failure is immediate and you really see it with clarity. I also tell them to not use addEventListener because then they are limited to a single handler per event and if they cannot properly manage their code it will fail and that failure is immediately clear. I also tell them to look closer at the standard DOM methods which are generally faster than other conventions by 50x-16000x unless you are search for elements by attribute name/value which is about 16x slower than using a similar query selector. 3. Spend more time up front writing automation so less time is spent doing manual work. It is nice when the documentation is always up to date because it is dynamically generated from the code. 4. Provide complete test automation but not test coverage. Ensure there are tests for every business requirement, configuration, and collection of competing configurations. Prove the application does all it claims, but don't test for anything else. Testing when done wrong wastes your time. To save time ensure you have very many tests, the results are clearly communicated, and they execute as quickly as possible. After all of that and the code performs correctly it becomes far less effort to extend and to push back on stupidity from poorly considered business requirements, because you know your work is always close to perfect. You know this because you have accepted all the related liabilities and addressed them as directly as possible. [1] https://github.com/prettydiff/wisdom/blob/master/Delusional_Developers.md https://github.com/prettydiff/wisdom/blob/master/Delusional_...