The most important skill (of a good programmer)

Being programmer(*) is hard.

Being a good programmer is, of course, even harder. Unlike countless other jobs where the daily work is a routine, and being good at your job is to be efficient at that routine, being programmer is all about constantly learning and doing new things. Being a good programmer is about being fast at learning, and doing new things well. The process might stay for a while, but the content of the job is constantly changing. (If you keep doing same content over and over again, you are doing it wrong)

Being a programmer is much more than just writing code. But as fancy as it might sound, being creative and constantly learning, your daily work is mostly like this: you write some code. You try to build and run it. It results in some errors you don’t know (or you don’t remember how to fix it). You search for that error message. You open first 5 pages which were returned. You try a solution there. If it works, you continue. Raise and repeat, until the end of time.

Sounds like you?

Yes, being a programmer, and writing code, is actually involving a lot of searching. Being a good programmer isn’t not have to search at all, but is to spend less time searching, so you can spend more time doing things that matter!

How? What are the tricks?

• Choose the keywords. The internet is huge, and the webs are endless. You don’t have time to go through all of them (And you technically CAN’T). Select the keywords which allow you to have the small, well filtered results are important. Too generic keywords which return millions of results are not good. Too distinct keywords which return no result are not good, neither. It’s an art to add one, or remove another word in your search.       This is also why setting up your development environment to English is important. You can, technically, run your development environment in your native language, that’s not wrong and nothing prevents you from doing that. However, that means it’s likely your error messages will be in that language, and while I don’t have any statistics on my hands, it’s safe to assume that the number of pages which talk about your error message is significantly less than the number of pages talk about that message, in English. So my friends – always use English as your development environment language. You can thank me later.
• An ability is quickly scan the search results to choose the best ones on your question is also important. Time is precious – in fact, your remaining seconds on this world are limited, and counting, so use them smartly. Knowing which websites usually bring the best answers for your question plays an important role on reducing the time you spend searching in your journey to find answers. This is why StackOverflow.com is such a invaluable resources: 99% of the time, an error message will lead you there, with an accepted answer. My friends, we all own a great debt to SO, because of the time it saved so we can be doing other stuffs than having to go through pages and pages.
• Finally, quickly scan the web page to see if you can find the answer here. And it’s important to give feedback to the good answer which helped you solve the problem – vote it up, leave a comment, just to say thank, or if you have found a better way. There are several reasons for doing that – first, it’s a good way to thank a stranger on internet who spent his/her precious time so you can save your. It’ll help the people who come after you know it’s a good answer and save their time. And finally it might help you in the future, when you search for it again – and you recognize this helped you last time. Trust me, this happens more often than you think!

Those skills are simple, right? But to master them is not an easy task that you can just do. Being good on Google takes time, and practices.

But it’s worth it, if you really, really want to be a good programmer.

Part two is up now: http://vimvq1987.com/2017/12/the-art-of-asking-questions/ 

(*): Programmer, coder, developer, software engineer, whatever. Name your job. One might argue that they indeed are not the same and try to distinct them. I don’t care. For me, they are all the same – a job where you write code to solve problems – build new features, fix bugs, add values, reduce costs, all solving problems!