1. 20
  1.  

  2. 4

    The advice in here is not bad. But, IMO, a mistake I see fellow developers do often is that they think every thing they write has to tak this entire approach. So rather than seeing their ability to write code grow, such that they can write a meaningful library the first time rather than not, they reset at each new peice of code to the “copy and paste”. That makes it really hard for them to reach escape velocity and write good code. The outline in here should be for an entire career. At this point, unless it’s something wildly new, I can write a good, reusable, library off the top of my head the first time around.

    1. 5

      Hi

      think every thing they write has to tak this entire approach.

      I tried to capture this dissonance. Each step contradicts the next. I tried to repeat the point “you won’t know what you need until you already need it” throughout the steps.

      The outline in here should be for an entire career.

      That was also my intent. Along with each step contradicting the next, each step was further along the lifecycle of a project. I admit I didn’t try to make this too clear.

      1. 2

        I must admit, to really have a good escape velocity you have to really take your time and think through your data structures. If your data structures suck, the code will come to a standstill sooner or later (or explode in bloat). In these cases, it even makes sense to rewrite the program (and copy-paste the useful utility functions), so it allows deleting code portions again that were introduced in the first place to circumvent weaknesses in the data structure. These hacks I often find to be the reason for bugs in the first place as well.

        1. 1

          Can you elaborate on what you mean exactly? The way I approach a problem is to write a clear, pure (not in the functional sense), API tha solves the problem. It hides all underlying data structures. For most things in a program, one can use the most inefficient data structure ever and it doesn’t really matter, so when it comes to really hot things I can generally refactor the inside of the API without effecting the API, to be more efficient. And in those worst cases, I have to tear down a few walls for efficiency. In otherwords, I find the actual choice of data structure mostly a non-question until some performance isuse has demonstrated it needs to be an issue.

          I’ve found the above very effective in every project I’ve worked on. Are you suggesting a different approach or does that align with what you’re saying as well?

          1. 1

            I’m mostly a C developer, so it all boils down to giving the user of a library easy and simple structs to work with and which are also interfaced via functions. The API is thus also part of the data structure, and both approaches (hiding or opening) the data structure to the user are good approaches in my view. Do what suits you best and most importantly: What suits the problem.

        2. 1

          At this point, unless it’s something wildly new, I can write a good, reusable, library off the top of my head the first time around.

          But should you do so for that script to load the barfoo data into the baz database one time before we build an interface to manually edit the data?

          I would say that cut and paste would work just fine for that use case and that a good reusable library is overkill.

          1. 2

            Cut and paste what? With th reusable components I have, I can generally just combine some existing components together pretty trivially to get the new behaviour. The case that I think you are referring to is much rarer, IME, than many people like to claim. Not never, but rare enough it’s not a reasonable default, IMO.