5 ms·

Programming is like some kinds of work. It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of

Programming is like some kinds of work. It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of parallels with creating a new manufacturing facility that manufactures a new kind of thing using new materials and techniques. The primary parallel is that a new facility requires a lot of discovery. Whereas if operating an existing facility constantly required a lot of discovery that disrupted operations it is likely the business team would pivot to something more lucrative. Sadly most developers work in companies that have a manufacturing management system, which is inappropriate for managing development work, primarily because of pressure+timeline patterns typically applied via silo on silo kingdom building.

paulcole 3y ago
[flagged]
- happytoexplain 3y ago
  Again, a very exaggerated/sarcastic version of the quoted sentence. It's impossible to engage if you don't have realistically worded questions.
- gnulinux 3y ago
  Yes, this keeps coming up and people respond rather reasonably but people insist on not understanding. In software if something is similar to "cleaning out clogged sewer pipes for the 999,999th time" then it has to be possible to automate it. If I have a task to clean up my code, I'll automate it then it'll take <1 sec to do it. When people say "software is hard" this is not some sociological argument, it literally is a mathematical argument and the reaction should be either acceptance or automating it. If I cannot automate something I need to sit down and think about it the same I think about "Columbus setting out for the New World" or "building the Sistine Chapel" or whatever, i.e. as deeply as my neurological faculties allow me. For "it's just kluding APIs bro" kind of arguments, I invite you to look at no-code and low-code products and report us how well they work. Is it easy to "kludge together APIs" in this fashion and does it produce viable products? Why? Why not? If it's so easy that it's close to being automated, why can't we have a UI like Photoshop to create API consumer apps? What cannot be automated has to be exhaustively thought by someone.
- replyifuagree 3y ago
  One thing to watch out for is confusing IT work for dev work. I see this a lot with business folks. An example of IT work is installing MS Office on a laptop by hand. An example of dev work is integrating VBA into excel so that office users can automate excel using VBA.
  - paulcole 3y ago
    But yeah thats kinda my point. Integrating VBA into excel isn’t the Manhattan Project. Unless it’s your first job you can probably break the project down into steps and give a decent estimate of time on each.
    - replyifuagree 3y ago
      Integrating VBA into excel was an interesting one as the excel team refused to just pull it in as a dynamic dependency but wanted it embedded straight into the deployment to avoid the DLL hell that was common on the windows platform. In addition going from having no automation via something like VBA to having automation required some pretty complex work. As for the Manhattan Project, you might want to think on the difference between the words complexity and difficulty. And then you might consider that when working with nuclear material to create the world's first nuclear bomb, you would want to keep the complexity as low as possible, sheerly out of self preservation.
      - paulcole 3y ago
        Neat!
    - pixl97 3y ago
      Yep, this sounds like the kind of project you make a guess, write up, and it works in that amount of time on your machine. Then you push it out into the field and you get flooded with calls on it not working. Turns out it only works in your version of Excel on Windows without some particular set of patches installed. Manhattan Project was easy, they didn't have to worry about any backwards/multi-platform compatibility.

paulcole 3y ago

[flagged]

happytoexplain 3y ago
Again, a very exaggerated/sarcastic version of the quoted sentence. It's impossible to engage if you don't have realistically worded questions.
gnulinux 3y ago
Yes, this keeps coming up and people respond rather reasonably but people insist on not understanding. In software if something is similar to "cleaning out clogged sewer pipes for the 999,999th time" then it has to be possible to automate it. If I have a task to clean up my code, I'll automate it then it'll take <1 sec to do it. When people say "software is hard" this is not some sociological argument, it literally is a mathematical argument and the reaction should be either acceptance or automating it. If I cannot automate something I need to sit down and think about it the same I think about "Columbus setting out for the New World" or "building the Sistine Chapel" or whatever, i.e. as deeply as my neurological faculties allow me. For "it's just kluding APIs bro" kind of arguments, I invite you to look at no-code and low-code products and report us how well they work. Is it easy to "kludge together APIs" in this fashion and does it produce viable products? Why? Why not? If it's so easy that it's close to being automated, why can't we have a UI like Photoshop to create API consumer apps? What cannot be automated has to be exhaustively thought by someone.
replyifuagree 3y ago
One thing to watch out for is confusing IT work for dev work. I see this a lot with business folks. An example of IT work is installing MS Office on a laptop by hand. An example of dev work is integrating VBA into excel so that office users can automate excel using VBA.
- paulcole 3y ago
  But yeah thats kinda my point. Integrating VBA into excel isn’t the Manhattan Project. Unless it’s your first job you can probably break the project down into steps and give a decent estimate of time on each.
  - replyifuagree 3y ago
    Integrating VBA into excel was an interesting one as the excel team refused to just pull it in as a dynamic dependency but wanted it embedded straight into the deployment to avoid the DLL hell that was common on the windows platform. In addition going from having no automation via something like VBA to having automation required some pretty complex work. As for the Manhattan Project, you might want to think on the difference between the words complexity and difficulty. And then you might consider that when working with nuclear material to create the world's first nuclear bomb, you would want to keep the complexity as low as possible, sheerly out of self preservation.
    - paulcole 3y ago
      Neat!
  - pixl97 3y ago
    Yep, this sounds like the kind of project you make a guess, write up, and it works in that amount of time on your machine. Then you push it out into the field and you get flooded with calls on it not working. Turns out it only works in your version of Excel on Windows without some particular set of patches installed. Manhattan Project was easy, they didn't have to worry about any backwards/multi-platform compatibility.