|
There were two major milestones for me. One was taking my first college CS course. Just being forced to work in depth with indirection and write algorithms set me up to make all sorts of things, even though I did not go on to get the degree. The other was to realize, after a few years, that code isn't an edifice - that is, you don't progress through it linearly to a solution, as tends to be the case in school assignments. To solve a production-grade kind of problem, you start by making an incorrect solution that you understand well - the proverbial "start with a hello world". And then you iterate over that to generalize and make it produce more correct answers. The bugs reflect a lack of understanding of the system, and architecture strategies tend to result from knowing that nobody can understand the entire system, thus you design in some constraints and safeguards to enable more complex ideas to build on smaller ones without that understanding. This process also meant learning to reject "blogpost-driven development", which was a common genre back in the 2000's of people doing some career-making by making a blog about some cute idea they had about best practices. Naive me, I tried testing out every one of them, and eventually, through painstaking reduction, learned that mostly, you have to invent the best practices according to the problem domain. If you can get a direct answer by not writing code, that's a really, really good idea, hence I try to usher more of my work onto paper or into a spreadsheet now. |