3 ms·

Personally I like the idea of iterative development. That means, I will code knowing beforehand my first version will be crap. Because no matter how much thoug

Personally I like the idea of iterative development. That means, I will code knowing beforehand my first version will be crap. Because no matter how much thought I put into it, there's always a myriad of variables that get overlooked in a first version. And once I done it, I get to know most of those variables. But to avoid programming an amorphous blob of bad code, I take software architecture very seriously. If I split controllers, services, repositories properly, then I know I will be sitting on tip of a solid base without worrying about not writing a perfect first version.

Etheryte 4y ago
This is also why I think being good at refactoring is a secret superpower. So long as you keep moving roughly in the right direction and knoll things as you go, you can always iron out the kinks in the end.
- jrochkind1 4y ago
  "knoll"? I am not familiar with that word used that way and am not finding a definition online. Is that slang from somewhere?
  - piva00 4y ago
    If you search "knolling" you might have an easier time. It's a process of arranging things for photography but could mean more generally "arranging things neatly".
    - Etheryte 4y ago
      As far as I know, the term was originally used to mean roughly "always be arranging like objects in parallel or 90-degree angles" [0] [1]. The idea is to keep your workplace tidy as you work, meaning that you keep your tools and working pieces organized as you go. Taking pictures of knolled workspaces etc is a more recent addition from the social media generation if I'm not mistaken. [0] https://archive.curbed.com/2016/7/18/12215158/always-be-knolling-tom-sachs-knoll https://archive.curbed.com/2016/7/18/12215158/always-be-knol... [1] https://en.wikipedia.org/wiki/Tom_Sachs#Knolling https://en.wikipedia.org/wiki/Tom_Sachs#Knolling
  - maicro 4y ago
    https://www.youtube.com/watch?v=s-CTkbHnpNQ https://www.youtube.com/watch?v=s-CTkbHnpNQ is a good introduction to the idea, but basically, "clean up and organize, with things aligned with the table and each other". Side note, I also recommend the main "Ten Bullets" video by Tom Sachs (of which the link above is for bullet 8, "Always Be Knolling"); it feels a little over-zealous and pretentious at times, but there's something about it that makes me want to go back and watch it every couple years for inspiration...
lobstrosity420 4y ago
This is a big issue when the org you are at doesn't give you space to refactor and rework your system. Because the value added of refactoring is opaque to business goals (why are you spending time on something that was already working fine?) it can be soul crushing to know your first (crappy) try at something is the one that counts and there are no do overs.
- frostwarrior 4y ago
  Thing is, trying to create a perfect first version actually takes more time and mental energy than having a defined good base, creating a first draft and testing it. Here are some tips from personal experience: 1) Program with refactoring in mind beforehand. Things like SOLID, Hexagonal Architecture or even MVC help make refactoring easier. 2) Practice a bit with SOLID principles in your language. Once you get the gist the first time, every project after that is just copy and paste. Upload that base project to a personal git repository if you like. 3) If your project doesn't have to be lightning fast then prioritize legibility over superb efficient algorithms. For example, directly operating and mutating an array may demand less CPU cycles than mapping and parsing an array into controllers and descriptive functions. But unless you can wrap that in an accessible way, it will make further development hell. 4) Software engineering is weird. Unlike other engineering fields, our requirements and constraints change all the time, and the product is never meant to be static. The more flexible a program is to develop and refactor, the more it will maintain its quality over time. Even a perfect and fast program will crumble over time. The "I don't have time for good code" is a mental trap and a sign of either nearsightedness, or letting oneself be dragged by anxiety. It's our job to at least make notice when development is badly managed. Leaving that aside, I assure you that once you have a good boilerplate project, every program built on top of that will be fast and flexible. And any bugfixing will be straightforward.
  - lobstrosity420 4y ago
    Thank you for the tips! SOLID has indeed been an excellent tool in dealing with this. Unfortunately, there are a few issues at my current day job that make even your principles a band aid. 1) We have a "project board" composed of non technically inclined managers who set deadlines independently, this has resulted in an environment where everything is for yesterday. Once something works, I'm already late for the next thing. 2) My teammates are not really well versed in SOLID principles, so my good boilerplate project I've set up at the beginning of the product cycle has already been mangled (I wish I had time for mentoring). Indeed, it is our duty to raise these issues but if you are powerless to change the org structure it is best to let go (and update your CV). I'm just venting a bit here I hope you don't mind :)

Etheryte 4y ago

This is also why I think being good at refactoring is a secret superpower. So long as you keep moving roughly in the right direction and knoll things as you go, you can always iron out the kinks in the end.

jrochkind1 4y ago
"knoll"? I am not familiar with that word used that way and am not finding a definition online. Is that slang from somewhere?
- piva00 4y ago
  If you search "knolling" you might have an easier time. It's a process of arranging things for photography but could mean more generally "arranging things neatly".
  - Etheryte 4y ago
    As far as I know, the term was originally used to mean roughly "always be arranging like objects in parallel or 90-degree angles" [0] [1]. The idea is to keep your workplace tidy as you work, meaning that you keep your tools and working pieces organized as you go. Taking pictures of knolled workspaces etc is a more recent addition from the social media generation if I'm not mistaken. [0] https://archive.curbed.com/2016/7/18/12215158/always-be-knolling-tom-sachs-knoll https://archive.curbed.com/2016/7/18/12215158/always-be-knol... [1] https://en.wikipedia.org/wiki/Tom_Sachs#Knolling https://en.wikipedia.org/wiki/Tom_Sachs#Knolling
- maicro 4y ago
  https://www.youtube.com/watch?v=s-CTkbHnpNQ https://www.youtube.com/watch?v=s-CTkbHnpNQ is a good introduction to the idea, but basically, "clean up and organize, with things aligned with the table and each other". Side note, I also recommend the main "Ten Bullets" video by Tom Sachs (of which the link above is for bullet 8, "Always Be Knolling"); it feels a little over-zealous and pretentious at times, but there's something about it that makes me want to go back and watch it every couple years for inspiration...

lobstrosity420 4y ago

This is a big issue when the org you are at doesn't give you space to refactor and rework your system. Because the value added of refactoring is opaque to business goals (why are you spending time on something that was already working fine?) it can be soul crushing to know your first (crappy) try at something is the one that counts and there are no do overs.

frostwarrior 4y ago
Thing is, trying to create a perfect first version actually takes more time and mental energy than having a defined good base, creating a first draft and testing it. Here are some tips from personal experience: 1) Program with refactoring in mind beforehand. Things like SOLID, Hexagonal Architecture or even MVC help make refactoring easier. 2) Practice a bit with SOLID principles in your language. Once you get the gist the first time, every project after that is just copy and paste. Upload that base project to a personal git repository if you like. 3) If your project doesn't have to be lightning fast then prioritize legibility over superb efficient algorithms. For example, directly operating and mutating an array may demand less CPU cycles than mapping and parsing an array into controllers and descriptive functions. But unless you can wrap that in an accessible way, it will make further development hell. 4) Software engineering is weird. Unlike other engineering fields, our requirements and constraints change all the time, and the product is never meant to be static. The more flexible a program is to develop and refactor, the more it will maintain its quality over time. Even a perfect and fast program will crumble over time. The "I don't have time for good code" is a mental trap and a sign of either nearsightedness, or letting oneself be dragged by anxiety. It's our job to at least make notice when development is badly managed. Leaving that aside, I assure you that once you have a good boilerplate project, every program built on top of that will be fast and flexible. And any bugfixing will be straightforward.
- lobstrosity420 4y ago
  Thank you for the tips! SOLID has indeed been an excellent tool in dealing with this. Unfortunately, there are a few issues at my current day job that make even your principles a band aid. 1) We have a "project board" composed of non technically inclined managers who set deadlines independently, this has resulted in an environment where everything is for yesterday. Once something works, I'm already late for the next thing. 2) My teammates are not really well versed in SOLID principles, so my good boilerplate project I've set up at the beginning of the product cycle has already been mangled (I wish I had time for mentoring). Indeed, it is our duty to raise these issues but if you are powerless to change the org structure it is best to let go (and update your CV). I'm just venting a bit here I hope you don't mind :)