5 ms·

Type 1 is the most common type of programmer I've seen, and they are the reason everything is complex and fragile. Most programmnig jobs force you to spend mos

by hsn915 4y ago

Type 1 is the most common type of programmer I've seen, and they are the reason everything is complex and fragile. Most programmnig jobs force you to spend most of your time editing config files and trying to figure out why when you tried to use the library to do X it doesn't work properly! And then it turns out that you "just" have to configure Y and Z in particular ways, and you also need to make sure K is setup correctly at time T.

masfuerte 4y ago
I thought everything is complex and fragile because the Type 2 people are shoring up towers of nonsense with ever more automated tooling.
- hsn915 4y ago
  I'll give you an example. Here's the official Ubuntu documentation about how to install WordPress on your Ubuntu server. https://ubuntu.com/tutorials/install-and-configure-wordpress#2-install-dependencies https://ubuntu.com/tutorials/install-and-configure-wordpress... I want to focus on steps 2 through 6 They are all about configuring the system/envnironment. There are some tools that automate some of that. For example, you have to install about 10 packages. The installation of each package is mostly automated, except when it breaks for random reasons, but aside from that, even if it was perfect, you still have to know which packages to install and type out the commands to install them. Type 1 in the OP is the type that thinks this is very simple and is not a problem that needs solving. Step 4 in the guide has you edit config files in specific locations and execute some commands in a specific order. Again, each step, on its own, would sound "simple" to the type 1 programmer in the OP. Step 5 would have you configure a database. Again large parts of the process are automated .. but .. The whole process is complicated because at each step along the way someone thought the task is simple and their job is done and they just move ball down the field: it's not their responsibility anymore. A type 2 engineer in my book would try to design the system so that they _avoid_ the need for all this cruft.
  - bombolo 4y ago
    > A type 2 engineer in my book would try to design the system so that they _avoid_ the need for all this cruft. So a go developer that reimplements all of that in go, using rewritten buggy libraries?
    - disgruntledphd2 4y ago
      Nah, you'd write some kind of metapackage called something cutesy like lamp that had a TUI that took you through it.
    - hsn915 4y ago
      You can't fix the problem of too many layers of abstraction with another layer of abstraction.
andix 4y ago
Developers should be forced to write more documentation. Because if you create easy to use software, not a lot of documentation is needed. If you create difficult solutions, you need to create a lot of documentation. And there is nothing that people hate more, than writing documentation :).
- pixl97 4y ago
  We're acting like the programmers want to create the complicated software, but really its the sales team showing up to project management saying "We signed a million dollar deal because our product does X"... then the PM panicking telling the programers that the application needs to do X by next week.
  - andix 4y ago
    I’ve seen a lot of programmers/architects who created way to complicated solutions. Distributed microservice applications, nosql, and so on. New technologies that seem cool and useful, but make stuff much more complicated then it needs to be. Without real benefits. „But we can scale from 500k to 50 million users now“, which usually doesn’t happen. But what does happen is, that the system gets too complicated and too hard to extend or fix bugs.
    - sopooneo 4y ago
      I struggle mightily with this in managing projects. My instinct is to use solid boring tech, and maximize chance of delivering on time. But I've found that: 1.) No one writes blog posts about using old boring stuff and meeting expectations. And such blog posts can contribute to recruiting and even, indirectly, sales, by helping your company get general press for being "on the cutting edge." 2.) You can potentially get better overall results even if the new tech has more gotchas and unknowns, because certain developers will knock themselves out to deliver on time and prove you were right in trusting them with the platform/language decisions. But you have to pick very wisely on this and keep in mind such devs may immediately lever their experience on the new tech to get a new job and leave you with a team of juniors that wander lost without their guru.
sopooneo 4y ago
My experience has been the same. Many (maybe not most for me) early programmers seem to think their job is to provide for the option of success. Full stop. "Well that would be on them," is often the retort when asked about possible user errors or failure to follow directions. It can be a hard pill to swallow to realize that we may have reduce the best possible outcome of our work, in favor of the best likely outcome.

by hsn915 4y ago

masfuerte 4y ago

I thought everything is complex and fragile because the Type 2 people are shoring up towers of nonsense with ever more automated tooling.

hsn915 4y ago
I'll give you an example. Here's the official Ubuntu documentation about how to install WordPress on your Ubuntu server. https://ubuntu.com/tutorials/install-and-configure-wordpress#2-install-dependencies https://ubuntu.com/tutorials/install-and-configure-wordpress... I want to focus on steps 2 through 6 They are all about configuring the system/envnironment. There are some tools that automate some of that. For example, you have to install about 10 packages. The installation of each package is mostly automated, except when it breaks for random reasons, but aside from that, even if it was perfect, you still have to know which packages to install and type out the commands to install them. Type 1 in the OP is the type that thinks this is very simple and is not a problem that needs solving. Step 4 in the guide has you edit config files in specific locations and execute some commands in a specific order. Again, each step, on its own, would sound "simple" to the type 1 programmer in the OP. Step 5 would have you configure a database. Again large parts of the process are automated .. but .. The whole process is complicated because at each step along the way someone thought the task is simple and their job is done and they just move ball down the field: it's not their responsibility anymore. A type 2 engineer in my book would try to design the system so that they _avoid_ the need for all this cruft.
- bombolo 4y ago
  > A type 2 engineer in my book would try to design the system so that they _avoid_ the need for all this cruft. So a go developer that reimplements all of that in go, using rewritten buggy libraries?
  - disgruntledphd2 4y ago
    Nah, you'd write some kind of metapackage called something cutesy like lamp that had a TUI that took you through it.
  - hsn915 4y ago
    You can't fix the problem of too many layers of abstraction with another layer of abstraction.

andix 4y ago

Developers should be forced to write more documentation. Because if you create easy to use software, not a lot of documentation is needed. If you create difficult solutions, you need to create a lot of documentation. And there is nothing that people hate more, than writing documentation :).

pixl97 4y ago
We're acting like the programmers want to create the complicated software, but really its the sales team showing up to project management saying "We signed a million dollar deal because our product does X"... then the PM panicking telling the programers that the application needs to do X by next week.
- andix 4y ago
  I’ve seen a lot of programmers/architects who created way to complicated solutions. Distributed microservice applications, nosql, and so on. New technologies that seem cool and useful, but make stuff much more complicated then it needs to be. Without real benefits. „But we can scale from 500k to 50 million users now“, which usually doesn’t happen. But what does happen is, that the system gets too complicated and too hard to extend or fix bugs.
  - sopooneo 4y ago
    I struggle mightily with this in managing projects. My instinct is to use solid boring tech, and maximize chance of delivering on time. But I've found that: 1.) No one writes blog posts about using old boring stuff and meeting expectations. And such blog posts can contribute to recruiting and even, indirectly, sales, by helping your company get general press for being "on the cutting edge." 2.) You can potentially get better overall results even if the new tech has more gotchas and unknowns, because certain developers will knock themselves out to deliver on time and prove you were right in trusting them with the platform/language decisions. But you have to pick very wisely on this and keep in mind such devs may immediately lever their experience on the new tech to get a new job and leave you with a team of juniors that wander lost without their guru.

sopooneo 4y ago

My experience has been the same. Many (maybe not most for me) early programmers seem to think their job is to provide for the option of success. Full stop. "Well that would be on them," is often the retort when asked about possible user errors or failure to follow directions. It can be a hard pill to swallow to realize that we may have reduce the best possible outcome of our work, in favor of the best likely outcome.