5 ms·

I think not investing/knowing good tooling is another sink. Mainly setup and take down. For example, a program I recently learned about was “lerna”. If I had k

I think not investing/knowing good tooling is another sink. Mainly setup and take down. For example, a program I recently learned about was “lerna”. If I had know about it a few months ago, it would have been less painful to manage all of our libraries. Another good example is deploying to serverless backends. Without the serverless framework, this was otherwise painful. And once we find out about these tools, there’s a ramp up cost to integrate them into the existing workflows

js8 5y ago
I just thought about this and it seems to be a paradox. I can't shake a feeling (since I started my career working with methods of the past) that programmers in the past were more productive than programmers today, despite all the talk about wonderful new tools and libraries. Let's say I can make a product in a billion different ways. That means I have to make around, say, 30 decisions (log2 of that) how to go about it. Now let's say I am more limited, and I can only make it in a million different ways; that means only 20 decisions have to be made. More decisions mean more overhead - everybody in the team needs to learn them, accept them, etc. So in the past, people had limited variety of tools, and the way they could build SW products were more limited, but it actually was more productive because lot of the decisions didn't have to be made. That's the paradox, we think that more specialized tooling leads to higher productivity, but in creative professions, where the job is to make decisions, and physical labor is not the main constraint, this is the opposite.
- secondaryacct 5y ago
  Sure you're right, but doing a website in the 80s was ... nonsensical, so not needing a LESS-like preprocessor for CSS was possible. Or profilers were not as useful when the programs were printed on punch cards. The thing is we're orders of magnitude more productive if you look at what results we must achieve: if IBM wanted to publish news on a worldwide networks in the past they would have needed thousands of people and millions just to setup the infrastructure, let alone convincing people to buy terminals. Now an intern can do it in a few days because of all the successive layers of tools and software. What you describe doesnt need to happen if you are more dictatorial: get 2 languages allowed for productions (one ui, one logic), 1 more for back office (for statistics and reporting) and force everything in it. Do the same for libraries and dont do it by commitee, just say that s the stack, you can do go or groovy or rust elsewhere and done. Then people start discussing solving actual problems rather than war-of-the-stack every meeting.
- tomnipotent 5y ago
  > programmers in the past were more productive I'm not sure how we'd be able to define productivity in a meaningful way to compare. I feel like programmers create more value for business today than ever before, even if they're not necessarily writing the code creating that value.
  - pjerem 5y ago
    > I feel like programmers create more value for business today than ever before, even if they're not necessarily writing the code creating that value. This is true, but I don't see what the tooling or the productivity have to do with that. It's just that there is an always increasing demand for new programs.
  - rightbyte 5y ago
    Do we? Having a Cobol or Basic programmer writing a simple 500 line goto mess for a administrative task was probably way more usefull for businesses than today's "take it or leave it" approach with high level applications programming. Good luck asking for a specific ad hook feuture in those monster code bases as a lowly system user. The bar for "creating value" is way to high today and the simplicity is gone in favour of expensive complexity ofent for no good reason. Excel (from the user perspective) is probably the last man standing of the simple way.
    - tomnipotent 5y ago
      In what world did programmers stop writing hacky 500 line messes to automate random tasks? > The bar for "creating value" is way to high today It's actually really low, and usually just starts with doing work.
- pjerem 5y ago
  tbh, I truly think that GAFAMs are trying to be the only entities to control the "fundamentals" of computers science. This includes : - locking systems to stop people trying to understand how it all works - providing and actively promoting high level tooling and platforms to allow other business to do their jobs without needing to understand how a computer works. - hiring at any cost any engineer with the technical capacities to create real alternative technology (and to profit from his knowledge is just a good side effect of removing its free time) I know few companies (maybe zero ?) that have not any critical dependency on a GAFAM product, be it a framework, a platform, libraries, tools ... I'm truly fascinated (and worried) at how you can successfully run a software company with programmers who don't even understand (or remember, because, for most, we were taught) how a computer actually works. And by no means I'm criticizing those people, I'm totally in this group. It amazes me that some of my best productive coworkers never tried once in their life or have the curiosity to install some Linux distro. I'm not talking about loving it and keeping it, but just to have the curiosity.
  - selfhoster11 5y ago
    I feel it's very unjust that you got downvoted so much. Whether the "lift-off" away from low-level programming is intentional or not, the effects are definitely pronounced.
- danjac 5y ago
  It feels more like there's a 20 year cycle - enough time for old hands to retire or move up into management so the new batch can repeat the same mistakes but with different platforms and technologies without learning what went wrong before. So 15-20 years ago people were resume-padding their way to building a small internal dashboard web app with J2EE and EJBs, now the current lot of resume-padders are doing the same with k8s and GraphQL and serverless and whatnot.
- Lutger 5y ago
  I'm not sure what your concept of productivity is, but instead of indicating something about productivity, I think the increasing amount of decisions to make is actually about higher levels of complexity inherent in software development. All the simple programs have already been written, this means we can only go forward writing programs that are ever more complex to maintain the same amount of value to our stakeholders. And this increased complexity requires slightly different skills and activities than those we learned starting our careers. For in order not to break down from this complexity, we need much more powerful abstractions and ways to combine than before - more complex solutions are usually also more brittle. I think it's rather a feeling of loss of control than loss of productivity, caused by the accelerating pace of innovations. We're all kind of becoming more and more involved with architecting, configuring, installation, managing and operating rather than building (or rather, building software is changing shape), and the 'building' part is where developers naturally locate 'productivity'.
- selfhoster11 5y ago
  I think the problem is that we're trying to fit everything into software frameworks rather than just occasionally redo things in a simple way. Part of what I hate about Java programming is exactly the over-dependence on shitty use of Spring idiosyncracies everywhere.
notacoward 5y ago
I think this falls under "extraneous cognitive load" but I could be wrong.

js8 5y ago

I just thought about this and it seems to be a paradox. I can't shake a feeling (since I started my career working with methods of the past) that programmers in the past were more productive than programmers today, despite all the talk about wonderful new tools and libraries. Let's say I can make a product in a billion different ways. That means I have to make around, say, 30 decisions (log2 of that) how to go about it. Now let's say I am more limited, and I can only make it in a million different ways; that means only 20 decisions have to be made. More decisions mean more overhead - everybody in the team needs to learn them, accept them, etc. So in the past, people had limited variety of tools, and the way they could build SW products were more limited, but it actually was more productive because lot of the decisions didn't have to be made. That's the paradox, we think that more specialized tooling leads to higher productivity, but in creative professions, where the job is to make decisions, and physical labor is not the main constraint, this is the opposite.

secondaryacct 5y ago
Sure you're right, but doing a website in the 80s was ... nonsensical, so not needing a LESS-like preprocessor for CSS was possible. Or profilers were not as useful when the programs were printed on punch cards. The thing is we're orders of magnitude more productive if you look at what results we must achieve: if IBM wanted to publish news on a worldwide networks in the past they would have needed thousands of people and millions just to setup the infrastructure, let alone convincing people to buy terminals. Now an intern can do it in a few days because of all the successive layers of tools and software. What you describe doesnt need to happen if you are more dictatorial: get 2 languages allowed for productions (one ui, one logic), 1 more for back office (for statistics and reporting) and force everything in it. Do the same for libraries and dont do it by commitee, just say that s the stack, you can do go or groovy or rust elsewhere and done. Then people start discussing solving actual problems rather than war-of-the-stack every meeting.
tomnipotent 5y ago
> programmers in the past were more productive I'm not sure how we'd be able to define productivity in a meaningful way to compare. I feel like programmers create more value for business today than ever before, even if they're not necessarily writing the code creating that value.
- pjerem 5y ago
  > I feel like programmers create more value for business today than ever before, even if they're not necessarily writing the code creating that value. This is true, but I don't see what the tooling or the productivity have to do with that. It's just that there is an always increasing demand for new programs.
- rightbyte 5y ago
  Do we? Having a Cobol or Basic programmer writing a simple 500 line goto mess for a administrative task was probably way more usefull for businesses than today's "take it or leave it" approach with high level applications programming. Good luck asking for a specific ad hook feuture in those monster code bases as a lowly system user. The bar for "creating value" is way to high today and the simplicity is gone in favour of expensive complexity ofent for no good reason. Excel (from the user perspective) is probably the last man standing of the simple way.
  - tomnipotent 5y ago
    In what world did programmers stop writing hacky 500 line messes to automate random tasks? > The bar for "creating value" is way to high today It's actually really low, and usually just starts with doing work.
pjerem 5y ago
tbh, I truly think that GAFAMs are trying to be the only entities to control the "fundamentals" of computers science. This includes : - locking systems to stop people trying to understand how it all works - providing and actively promoting high level tooling and platforms to allow other business to do their jobs without needing to understand how a computer works. - hiring at any cost any engineer with the technical capacities to create real alternative technology (and to profit from his knowledge is just a good side effect of removing its free time) I know few companies (maybe zero ?) that have not any critical dependency on a GAFAM product, be it a framework, a platform, libraries, tools ... I'm truly fascinated (and worried) at how you can successfully run a software company with programmers who don't even understand (or remember, because, for most, we were taught) how a computer actually works. And by no means I'm criticizing those people, I'm totally in this group. It amazes me that some of my best productive coworkers never tried once in their life or have the curiosity to install some Linux distro. I'm not talking about loving it and keeping it, but just to have the curiosity.
- selfhoster11 5y ago
  I feel it's very unjust that you got downvoted so much. Whether the "lift-off" away from low-level programming is intentional or not, the effects are definitely pronounced.
danjac 5y ago
It feels more like there's a 20 year cycle - enough time for old hands to retire or move up into management so the new batch can repeat the same mistakes but with different platforms and technologies without learning what went wrong before. So 15-20 years ago people were resume-padding their way to building a small internal dashboard web app with J2EE and EJBs, now the current lot of resume-padders are doing the same with k8s and GraphQL and serverless and whatnot.
Lutger 5y ago
I'm not sure what your concept of productivity is, but instead of indicating something about productivity, I think the increasing amount of decisions to make is actually about higher levels of complexity inherent in software development. All the simple programs have already been written, this means we can only go forward writing programs that are ever more complex to maintain the same amount of value to our stakeholders. And this increased complexity requires slightly different skills and activities than those we learned starting our careers. For in order not to break down from this complexity, we need much more powerful abstractions and ways to combine than before - more complex solutions are usually also more brittle. I think it's rather a feeling of loss of control than loss of productivity, caused by the accelerating pace of innovations. We're all kind of becoming more and more involved with architecting, configuring, installation, managing and operating rather than building (or rather, building software is changing shape), and the 'building' part is where developers naturally locate 'productivity'.
selfhoster11 5y ago
I think the problem is that we're trying to fit everything into software frameworks rather than just occasionally redo things in a simple way. Part of what I hate about Java programming is exactly the over-dependence on shitty use of Spring idiosyncracies everywhere.

notacoward 5y ago

I think this falls under "extraneous cognitive load" but I could be wrong.