Natural talent in programming
August 11, 2020•674 words
I've been programming since I was about nine or ten. In that time I've amassed some amount of knowledge and skill. I've had eureka moments and I've also had moments where I've spent days chasing bugs across a vast mass of seemingly indecipherable code. I've had moments where I've just been doing a load of boring, mind-numbing programming. There have been moments in which I've thought up some pretty clever solutions. To go with these moments there have also been moments in which I've done incredibly clumsy things (though never with major consequence) and wasted a lot of time on such things. I've also had the most phenomenal amount of support (not directly with programming, but in my life) which has enabled me to have access to a computer and the time to spend programming which many people lack. I'm definitely a case born from a position of privilege.
There have been a lot of moments. Recently I've been trying to explain programming to other people (these are the sort of people who call it "coding" – I don't know why but that term really irritates me) only to get blank stares. I've also reviewed pull requests (code which other people submit to be included in a code base) for open source projects (software licensed in such a way that anyone can use it for any purpose for free). These have given me some insight into how people think. I've found conversations with other people about bugs they've been experiencing and "pair programming" to be illuminating and enlightening.
When watching people program the biggest differences I notice between myself and them are twofold. The first is about procrastination. Beginning any non-trivial programming task is difficult. There's a lot of planning and thought which has to go into any significant program. Programs are temporal beings – they change and evolve over time. Substantial thought needs to be given to how this can be designed for and with their possible evolution in mind (not around – designing "around" problems). This also means that some things are more important than others – if you need to maintain a consistent API then the public-facing API itself is going to initially be more important than the way in which the private API works. After all the contents of functions can easily be changed but changing the functions themselves causes a lot of pain.
I'm able to do this design a lot more quickly than them. It's not really that I'm able to do it better, although in some cases experience does make it so, it's that I can do it faster and more efficiently. Where less experienced individuals often find tasks overwhelmingly difficult and tricky I tend to be able to work things out and my intuition tends to be correct more frequently.
The second issue is when debugging code, which is sort of a special case of the above, I do it a lot better. The languages and tools I use aren't even particularly bad. I stay as far away from C and C++ as I can – they shouldn't be considered acceptable tools to build modern applications in in my opinion given their lack of safety checks and desire to push total responsibility for every last minutiae onto the programmer – but I do feel sorry for people who spend hours trying to reproduce impossible to reproduce memory bugs.
The main thing I've noticed when I watch other people (who are less experienced than me) is that I can empathise (and even sympathise) with them. I remember making similar mistakes and thinking (mistakenly) that they were caused by incorrect causes. This is something important to remember – people you think aren't "as good" as you (I by no means support such a categorisation of people, assessing their value based on their ability to deliver instructions to the industrial machine) are that way because they haven't had the time and fortune to be able to look into and learn programming.
Be nice to people. Don't create cultures in tech; we already have too many of those.