| The typical SE path I'm familiar with looks like: 1. Write _anything_ that works. Dependencies, code quality don't matter. Code is idiosyncratic but can be understood by a reviewer. 2. Apply abstractions _everywhere_. Re-implement data structures and algorithms (maybe unknowingly). Code is now very hard to understand. 3. Figure out one is completely unable to update or even maintain code written 6 months ago. Rewritten code suddenly becomes clearer, one begins to think about programming as an craft and not just hacking things on a keyboard until you get the desired result. Dependencies, judicious comments, code quality and a sane terseness become important. The journey starts here. Personally, step 1 was very short as I learned to program on the job. I was responsible for code, and so I needed to get it together quick. A language like Python makes 2 very easy, and 3 came very quickly too since, as I mentioned, I was responsible for the code (one man team). I have met people who work at large institutions who are stuck at 1. Others with degrees in CS who are stuck at 2. Some just "get it" and go straight to 3. But typically, the real journey starts when you need to go on with work but your prior self is preventing you from being efficient. You need to get rid of that prior self's work to move on. |