3 ms·

I agree as I build some terrible applications in .Net MVC, which is a decent framework. I think you have to build shit software not to build shit software. Fir

by avgDev 7y ago

I agree as I build some terrible applications in .Net MVC, which is a decent framework. I think you have to build shit software not to build shit software. First, professional web app I developed 3 years ago is still being build upon now. Even though it is pure garbage and I hate touching it, because I "made it work". As I gained experience and got burned because I did something a certain way I slowly but surely looked for alternative approaches. Now 3 years later, I'm building an app with layered architecture, proper separation of concerns, dependency injection. Plus, before I start hammering code away, I think about what is the number 1 priority for a piece of code, am I gonna use it once and forget it? Will I use it all the time? Then, proceed accordingly.

ct520 7y ago
" am I gonna use it once and forget it? " Always comes back to bite me in the a$$. Also taking over projects that were built this way always a pain. Now and days I just refuse to do the work if they pushing to cut corners.All in all I say my quality of life and the sense of being proud of work has increased.
- avgDev 7y ago
  I do agree with you. Now that I think of it I rarely write "use it once and forget it", because as you said it will come back to bite.
- benbristow 7y ago
  "am I gonna use it once and forget it?" Isn't the saying, YAGNI (You're not gonna need it)?
  - Izkata 7y ago
    YAGNI is meant for a "this could maybe be useful" scope-creep feature, that seems simple to add but doesn't have a reason to exist. (Aside, flip the contraction to get the acronym - "you aren't gonna need it")
JohnBooty 7y ago
I think about what is the number 1 priority for a piece of code, am I gonna use it once and forget it? Will I use it all the time? I've gone in the opposite direction in my career. Overbuilding the initial version of something for a bunch of anticipated (rather than actual use/failure scenarios) is something I now work very hard to avoid. The key IMHO is really being nimble enough to extract and/or refactor and/or refine as soon as it is needed. Not before, not after. "Overly robust" code is actually a huge problem sometimes. All that unused code is in there, giving the appearance of being robust, but is not actually battle-tested....

by avgDev 7y ago

ct520 7y ago

" am I gonna use it once and forget it? " Always comes back to bite me in the a$$. Also taking over projects that were built this way always a pain. Now and days I just refuse to do the work if they pushing to cut corners.All in all I say my quality of life and the sense of being proud of work has increased.

avgDev 7y ago
I do agree with you. Now that I think of it I rarely write "use it once and forget it", because as you said it will come back to bite.
benbristow 7y ago
"am I gonna use it once and forget it?" Isn't the saying, YAGNI (You're not gonna need it)?
- Izkata 7y ago
  YAGNI is meant for a "this could maybe be useful" scope-creep feature, that seems simple to add but doesn't have a reason to exist. (Aside, flip the contraction to get the acronym - "you aren't gonna need it")

JohnBooty 7y ago

I think about what is the number 1 priority for a piece of code, am I gonna use it once and forget it? Will I use it all the time? I've gone in the opposite direction in my career. Overbuilding the initial version of something for a bunch of anticipated (rather than actual use/failure scenarios) is something I now work very hard to avoid. The key IMHO is really being nimble enough to extract and/or refactor and/or refine as soon as it is needed. Not before, not after. "Overly robust" code is actually a huge problem sometimes. All that unused code is in there, giving the appearance of being robust, but is not actually battle-tested....