4 ms·

Article mentions a tweet which narrows in on a prime culprit: https://twitter.com/copyconstruct/status/1456129831821709315 https://twitter.com/copyconstruct/sta

by muglug 5y ago

Article mentions a tweet which narrows in on a prime culprit: https://twitter.com/copyconstruct/status/1456129831821709315 https://twitter.com/copyconstruct/status/1456129831821709315 > a lot of what most “developer influencers” say is fairly aspirational. Their own companies don’t necessarily do things as smoothly as they preach to others. There's a pride element there: developers don't want to admit that they work in less-than-stellar conditions. Some developer talks also double as recruiting events, and you're going to turn people off when you mention that the test suite takes a day to run and requires the use of a fax machine.

djbusby 5y ago
Easy to automate with Hylafax (2002), probably some SaaS API (2022) (there are at least a dozen Fax/SaaS things now)
ryandrake 5y ago
One of the things I've learned the hard way is you're never going to attain aspirational software purity in a corporate, commercial software environment. I used to say naive things like "Software should compile cleanly with every warning enabled, produce no lint warnings, have zero memory leaks, and zero crashes." But the only place that is true is in my own personal hobby projects that I am under no pressure to release and therefore have years to sand and polish with love and care. I moved out of software dev (into more product/projecty roles) largely because I just couldn't bear to release software into the wild that I knew was flawed, just because of the stupid deadline. Ironically, now I help make/enforce the deadlines so there's the whole duality of man thing...
- galaxyLogic 5y ago
  I've had a similar experience, but I keep on producing less than perfect code even for my hobby projects. What we think of as "high quality code" usually boils down to maintainability. We like code that is easy to understand because it is easy to maintain and evolve further. But maintainability is not an end in itself. The software also has to do what it is intended to do. That is way more important than how the code looks, in my (current) view. Therefore I write some pretty sloppy code. The reason not to write "perfect code" is also that lot of code gets thrown away at some point. Then all the effort that went into polishing it was wasted.
  - dxdm 5y ago
    I've seen more sloppy code being kept and built upon, than any code being thrown away. Once it is sloppy, it does not get easier to make code unsloppy as time goes by. Of course, "not sloppy" does not mean perfect; but it does mean understandable, testable, maintainable and extensible.
    - galaxyLogic 5y ago
      I agree on the importance of always striving to write not sloppy code. It is especially critical if you are building a system which must scale and must be maintained over a long time. Trying to avoid sloppy code is one of the things that can make programming a rewarding if challenging experience. > understandable, testable, maintainable and extensible. Those are all adjectives, just like "sloppy" is. So we must each make the decision as to how much effort we will invest in making code MORE understandable, MORE testable, MORE maintainable and MORE extensible. If the value of any of those properties is 0, then the code is definitely sloppy.
- hvidgaard 5y ago
  In a corporate environment I insist on treating warnings as errors. They are warnings for a reason and it will lead to hard to debug errors in a sufficiently large codebase/team. Enabling it after the fact is a chore, but once it working its not much extra work. Linting I only use for adding/correcting a file header, order or methods or other things that it can fix automatically.
- muglug 5y ago
  > you're never going to attain aspirational software purity in a corporate, commercial software environment Fun problem a few days ago: a slight design flaw allows a class of bug that a typechecker can't currently catch. Fixing the design flaw involves updating 25,000 lines across a few thousand files. Only 6 of the 25,000 lines demonstrated the bug (~1 in 4,000). If we wait two months we can build a tool to catch the errors (and many others like it) without updating the code. The design flaw stays, but its impact is nullified.

by muglug 5y ago

djbusby 5y ago

Easy to automate with Hylafax (2002), probably some SaaS API (2022) (there are at least a dozen Fax/SaaS things now)

ryandrake 5y ago

One of the things I've learned the hard way is you're never going to attain aspirational software purity in a corporate, commercial software environment. I used to say naive things like "Software should compile cleanly with every warning enabled, produce no lint warnings, have zero memory leaks, and zero crashes." But the only place that is true is in my own personal hobby projects that I am under no pressure to release and therefore have years to sand and polish with love and care. I moved out of software dev (into more product/projecty roles) largely because I just couldn't bear to release software into the wild that I knew was flawed, just because of the stupid deadline. Ironically, now I help make/enforce the deadlines so there's the whole duality of man thing...

galaxyLogic 5y ago
I've had a similar experience, but I keep on producing less than perfect code even for my hobby projects. What we think of as "high quality code" usually boils down to maintainability. We like code that is easy to understand because it is easy to maintain and evolve further. But maintainability is not an end in itself. The software also has to do what it is intended to do. That is way more important than how the code looks, in my (current) view. Therefore I write some pretty sloppy code. The reason not to write "perfect code" is also that lot of code gets thrown away at some point. Then all the effort that went into polishing it was wasted.
- dxdm 5y ago
  I've seen more sloppy code being kept and built upon, than any code being thrown away. Once it is sloppy, it does not get easier to make code unsloppy as time goes by. Of course, "not sloppy" does not mean perfect; but it does mean understandable, testable, maintainable and extensible.
  - galaxyLogic 5y ago
    I agree on the importance of always striving to write not sloppy code. It is especially critical if you are building a system which must scale and must be maintained over a long time. Trying to avoid sloppy code is one of the things that can make programming a rewarding if challenging experience. > understandable, testable, maintainable and extensible. Those are all adjectives, just like "sloppy" is. So we must each make the decision as to how much effort we will invest in making code MORE understandable, MORE testable, MORE maintainable and MORE extensible. If the value of any of those properties is 0, then the code is definitely sloppy.
hvidgaard 5y ago
In a corporate environment I insist on treating warnings as errors. They are warnings for a reason and it will lead to hard to debug errors in a sufficiently large codebase/team. Enabling it after the fact is a chore, but once it working its not much extra work. Linting I only use for adding/correcting a file header, order or methods or other things that it can fix automatically.
muglug 5y ago
> you're never going to attain aspirational software purity in a corporate, commercial software environment Fun problem a few days ago: a slight design flaw allows a class of bug that a typechecker can't currently catch. Fixing the design flaw involves updating 25,000 lines across a few thousand files. Only 6 of the 25,000 lines demonstrated the bug (~1 in 4,000). If we wait two months we can build a tool to catch the errors (and many others like it) without updating the code. The design flaw stays, but its impact is nullified.