4 ms·

> routinely treated with scorn for my approach Seriously? I feel for you. In my experience many companies do recognize tech debt now, and the value in fixing

by prerok 3y ago

> routinely treated with scorn for my approach Seriously? I feel for you. In my experience many companies do recognize tech debt now, and the value in fixing it or implementing it the right way, although that was not so much the case in early 2000s. That said, many times we do still have to argue for time to refactor vs adding new features. I think that the best software craftsman is the one that can quickly add features without accumulating tech debt and the best way to do that is to just fix/refactor the other stuff around the feature addition immediately. It seems like the OP's grandpa was that kind of person. Speaking for myself, I sometimes do take longer because I want to get it right, even if it does mean missing an internal deadline. It has to have the right "smell". I have learned that if we don't do that then, as cruft accumulates, 3am production incidents will be inevitable. So, do take this to heart: if others did not understand it, it does not matter. You have already benefited from your approach :)

ChrisMarshallNY 3y ago
Yeah, I'm not a subscriber to the "YOLO/MVP" school of software development, which basically makes me persona non grata in many tech crowds. When I write software, I use what I call "Constant Beta." Basically, my software is at a release level of Quality, from the very start. It may be incomplete (thus, unshippable), but what's there, is ready for its closeup (Mr. DeMille). Basically, before moving to the next feature, I make sure the one I'm working on, is complete. It may require coming back, after other parts of the program are done, but I always make sure that the API is clear, the documentation is done, and things like error handling and localization are in place, as early as possible. Surprisingly, I work very, very quickly, despite taking so much care. There's a number of reasons, which would require a series of blog posts, but the results speak for themselves.
- bacon_waffle 3y ago
  This sort of approach seems common in the Rust community, it's so much more professional/humane/sustainable/performant than any other corner of the industry that I've come across.

by prerok 3y ago

ChrisMarshallNY 3y ago

Yeah, I'm not a subscriber to the "YOLO/MVP" school of software development, which basically makes me persona non grata in many tech crowds. When I write software, I use what I call "Constant Beta." Basically, my software is at a release level of Quality, from the very start. It may be incomplete (thus, unshippable), but what's there, is ready for its closeup (Mr. DeMille). Basically, before moving to the next feature, I make sure the one I'm working on, is complete. It may require coming back, after other parts of the program are done, but I always make sure that the API is clear, the documentation is done, and things like error handling and localization are in place, as early as possible. Surprisingly, I work very, very quickly, despite taking so much care. There's a number of reasons, which would require a series of blog posts, but the results speak for themselves.

bacon_waffle 3y ago
This sort of approach seems common in the Rust community, it's so much more professional/humane/sustainable/performant than any other corner of the industry that I've come across.