4 ms·

I spent a lot of time thinking about this over the years and I have a few key thoughts: The most important base-level skill seems to be the ability to hold the

by issa 5y ago

I spent a lot of time thinking about this over the years and I have a few key thoughts: The most important base-level skill seems to be the ability to hold the concept of what I call "signal flow" (and others would call "state") in your head. The two jobs I've done in my life that I've done for money AND for fun are programmer and recording studio engineer. They are essentially identical. Hear me out: When someone sings into a microphone, the signal travels through a cable, into a pre-amplifer, then an equalizer that cuts out the low end, then a compressor to limit the dynamic range, maybe you add some reverb and some delay. You need to be able to understand what is happening to the signal at every stage. For example, if you run the signal into a compressor BEFORE you cut out the low end frequencies with an equalizer, the results will be dramatically different. If you add delay (an echo) to the signal and THEN add reverb, it will sound different and you probably won't get the natural sound you are looking for. When I was training audio engineers, if they didn't QUICKLY grasp this concept, they were most likely going to struggle. Software is pretty much the same. You need to know what each function is doing, the state of each variable as you step through, etc. If someone without any programming experience has trouble following the value of X: X = 10 Y = 15 X = 5 X = Y+X X = ? Then they will struggle learning. More recently, software has become a question of having a wide range of shallow knowledge, and the ability to google really well. But I think the fundamentals are the same.

hirvi74 5y ago
I like your analogy, perhaps because I was a musician at one time lol. I always used to analogy of cooking. You have ingredients, and you want to bake a cake. Slapping all the ingredients in the bowl at once, won't make a cake. You need to know what to add, when to add, how much to add, how long to bake it, what temperature, and the order of it all. (good recipes are algorithms after all). Once the cake is made, do you have the tenacity to improve (troubleshoot) it? The cake is way too sweet!!! Can you figure out why? Was it too much sugar or too much icing? Was there sugar in the milk? Perhaps caramel would be better than sugar, etc.. It takes a certain style of of thinking. One that requires, like you said, knowledge of the "state" of things, but also it requires accounting for many possible outcomes of said states e.g. input sanitization and/or input validation. It's not a forest vs. the trees style of thinking, but the forest AND the trees. The deeper you go, the larger and denser the forest becomes.
emmanuel_1234 5y ago
This is exactly why I really like functional programming / OCaml. It feels like piping modules to let data flow through, which is an abstraction I seem to be most comfortable with. Unlike OOP, which is nothing like this and offer a much more "realistic" abstraction (e.g.: the typical Vehicle > Car analogy), that in my head crumbles a lot quicker when faced with programming problems.

by issa 5y ago

hirvi74 5y ago

I like your analogy, perhaps because I was a musician at one time lol. I always used to analogy of cooking. You have ingredients, and you want to bake a cake. Slapping all the ingredients in the bowl at once, won't make a cake. You need to know what to add, when to add, how much to add, how long to bake it, what temperature, and the order of it all. (good recipes are algorithms after all). Once the cake is made, do you have the tenacity to improve (troubleshoot) it? The cake is way too sweet!!! Can you figure out why? Was it too much sugar or too much icing? Was there sugar in the milk? Perhaps caramel would be better than sugar, etc.. It takes a certain style of of thinking. One that requires, like you said, knowledge of the "state" of things, but also it requires accounting for many possible outcomes of said states e.g. input sanitization and/or input validation. It's not a forest vs. the trees style of thinking, but the forest AND the trees. The deeper you go, the larger and denser the forest becomes.

emmanuel_1234 5y ago

This is exactly why I really like functional programming / OCaml. It feels like piping modules to let data flow through, which is an abstraction I seem to be most comfortable with. Unlike OOP, which is nothing like this and offer a much more "realistic" abstraction (e.g.: the typical Vehicle > Car analogy), that in my head crumbles a lot quicker when faced with programming problems.