Series "How to become a programmer: stories of our mentors "
- How to become a programmer: Ivan Takarlikov’s story
- How to become a programmer: Ilya Konovalov’s story
- How to become a programmer: Stas Mehonoshin’s story
I learnt about programming from the kids books like ‘And I Was in a Computer City’ and ‘Professor Fortran's Encyclopedia’. I could read or write at that time, but there weren’t too many computers around. So when my dad got hold of ZX Spectrum and a monitor for it (with a bad color transfer, so most of the 16 colors were the hues of red), I started trying to do some programming. I usually just rewrote the programs from my school computer science textbook. There were also some games (you could buy tapes with games in the Polytechnic Museum), which, on the one hand, weren’t as cool as Dendy’s games, but, on the other hand, I was the only one who had Spectrum and everybody else had Dendy. So I started programming some stuff in BASIC by myself. Usually by trial and error, using the examples from the textbook.
And then I got my first computer. There I found all sorts of batch files and QBasic. That seemed pretty natural to me to make use of all those things. I intrinsically objected the graphic user interface, as I was able to do everything in a console or in a Volkov commander. There was a moment, when I had an extracurricular activity with Macs and LogoWorlds (russian Logo coding environment – translator’s note). There I was analyzing the wheel motion pattern of the exploded car.
In the seventh grade the coding got quite real and we started using the algorithmic E language. My schoolmates began writing some stuff in C and I continued to use BASIC. By the end of our studies we got to use the very same BASIC in class and my friend and I made a game which was really popular among our classmates.
And the next was the institute, where in the first year we had Pascal (I wrote the code in it simply by translating it from BASIC) and Java. I was learning Perl by myself with O’Reilly Camel Book and official manuals. By the third year C was called for and I already had some knowledge about it as I used it a little before. I was just reading some different stuff about it. One morning I decided to discover what a socket is and how to use it, so I just took a book about Java, read it for 10 minutes and that was enough. In the meantime there was an internship and we had to find some place to work as trainees. I was invited to some office at my institute and got some tasks. The one of them was to take 150 CDs with lots of pictures and draw up a table with the info where each of them was. I contemplated for a while, wrote a script in Perl in a couple of days, then I was inserting and removing CDs for one more day and in the end made some decent list of files. I guess that was my first money earned with programming. I was even invited to continue working there after my internship was over, but I refused.
During all my studies I multiple times declined the offers from my groupmates to earn some money for the help with the school tasks. It was boring for me to do something instead of them for payment. It was more interesting to show them that they were able to do that themselves. If something doesn’t work, it’s challenging to try to find out why. After that I can explain it to others. When it’s done it’s not interesting anymore.
It’s usually the same for me at work. I’m given some thrilling and puzzling task, let loose on it and enthusiastically examine. If there are no such problems, I help others. Sometimes with advice, sometimes with some common knowledge or my own expertise. Mentorship for me is not only a possibility to do the same, but also have more contacts.
If you have no clue or aren’t really sure how to do something, just give it a shot. Every time I find myself thinking about how any piece of code works, I just create a basic example in /tmp. I have fun with it until I’m satisfied with the result. Maybe I’ll show it to someone else in the future, so I can feel certain about the idea.
If something goes wrong, just google it. If I compile anything and have a error that I can’t understand on the spot, I just copy it into the search box and all of a sudden the answer (or at least an initial prompt) is on the first results page.
Acquire a habit to read in English. Manuals in English should be manuals for you, not the texts in a foreign language.
I have dozens of ideas and unfinished projects. If I have some free time, I work on them. Or maybe I start working on some others, which I’m more excited with at the time. Furthermore, I try not to use anything that I already know, but something I’ve read about but haven’t tried yet. Thereafter I tried to write in Lisp lately and have some plans with Go, Rust, Smalltalk and Eve. And Haskell once again.
Working Effectively with Legacy Code is compulsory. It’s on my desk right now. It’s not necessary to read it over, but you should use it as a reference. If I should say something about specific languages and tools... I always recommend Git Magic. About C you can read Kernighan and Ritchie (it’s on my desk at work). There’s also great book Sed Grymoire about sed. The rest (such things as the site with POSIX standards or Make manuals) is easy to google.
No idea. I usually receive some newsletters from the 8thlight blog, but it’s not crucial. The same goes for Coding Horror (Jeff Atwood) and Martin Fowler. I think the most useful source for me is The Daily WTF.
Then start with our free guide to the world of web development. You will find tons of useful advices and materials to learn inside the book.Get the book