and has 0 comments
Growing up I always had this fantasy of writing a journal. My sense of privacy - being sure someone would read and judge it - stopped me from pursuing that, as well as the simple fact that I didn't need a journal, I just saw it as a cool thing I should do. Little did I know that in my older years I would want some sort of record of my forgotten youth and find none. Yet the idea persisted.

I started an actual journal as soon as I had a computer and I understood the concept of encryption. It didn't really work, either. It was full of self serving bullshit and it described a person that I really wasn't. One could (and should) read between the lines in order to understand the smug and ignorant state of mind of the author. Later still, I started to write a book, something called The Good Programmer or something of that sort. Phaw! Even if I could have gotten past my chronic impostor syndrome, being a good programmer is nice, but not my goal in life. If it were, I would have made other life choices. And again, it was full of self serving bullshit.

You may detect a pattern here and it might inform your reading this blog post. Anyway, its point is to generalize my experience as a programmer, as fast and as clean as possible. Hope it helps.

Every time I write software - that I care about and have influence over its technical quality - I tend to generalize things: reuse components, refactor duplicate code and so on. In other words, find similar problems and solve them with the same tool. It is not Golden Hammering problems away, that's a different thing altogether, since it is I who is shaping the tool. So how about doing that for my life? I should care about it and have influence over its quality.

First time I started writing code I was actually writing it on paper. I didn't have a computer, but I had just read this beginner's book and I was hooked. The code wouldn't have worked in a million years, but it was the thought that counted: I played around with it. Later on I got a computer and I started using the programs, understanding how it works, not different from getting a smartphone and learning how to phone people. Yet, after a while I found issues that I wanted to solve or games that I wanted to play but didn't have, then I made them myself: I found a problem and solved it. But writing code is not just about the end result. As soon as I explored what other people were doing, I started trying to emulate and improve what they did. I played around with compression and artificial intelligence, for example. And I was a teen in a world of no Internet. I went to the British Council and borrowed actual books, then tried the concepts there a lot.

It was years before I would become a professional programmer, and that is mostly because the hiring process (in any country) is plain stupid. The best HR department in the world is just looking for people that have already done what is required, so that they do it at the current company as well. But that's not what a developer wants. Software is both science and art. The science is a bit of knowledge and a lot of discipline, but the rest, a very large chunk, is just intuition and exploration and imagination. People who want to do the same thing over and over again are not good developers; instead they are probably people that just want to make a buck with which to live their "real" life. For me, real life has been writing code - and I still think I am being paid for putting up with the people I work for and work with, rather that for doing what I love.

Professional work is completely different from the learning period. In it you usually don't have a say on what you work on and the problems that software is supposed to solve are at best something you are indifferent to and at worst something you wouldn't understand (as in will not, even if you could). Yet, the same basic principles apply. First, you are required to write good code. By this your employers mean something that works as they intended, but for you it is still something that you feel pride in having written, something that is readable enough so you understand it a few weeks later when you have to add stuff or repair something. You are expected to "keep up to date", by which they understand you would keep studying in your spare time so that you do work that they don't know they need done, but for you it is still playing around with things. Think about it! You are expected to keep playing around! As for the part where you see what other people do and you get to emulate or improve on that... you have a bunch of colleagues working on the same stuff that you can talk to and compare notes and code review with. Add to this the strong community of software developers that are everywhere on the Internet.

Bottom line: Just keep doing three things and you're good. First play around with stuff. Then find a problem to solve (or someone to provide it for you) and write code for it. Finally, check what other people do and gain inspiration to create or improve your or their work. Oh, did I say finally? This is a while loop, for as long as you are having fun. Hey, what do you know? This does scale. Doesn't it sound like a good plan, even if you are not a software dev?

Comments

Be the first to post a comment

Post a comment