How to become a programmer, or the art of Googling well
okepi.wordpress.com
okepi.wordpress.com
"I'd come to understand that the answer was out there, somewhere." The answer is out there, but so is the wrong answer. Recognizing the right answer is the hard part.
I also must point out that the answer is out there if you know English. Knowing English is a strong privilege. Success rate plummets if you Google programming questions in a language other than English.
Damn. I wish I could show your comment to people like John Searle.
Actually it is funny, I only realized while reading this discussion that I always google my programming questions in English. It never occurred to me do google them in Dutch. I will try it today to see the results :)
The Dutch all speak English so well you can move there and never bother learning Dutch. And unlike the French, who will fake not understanding, they seem positively delighted to get a chance to use English. In fact, I've had other English people complain to me that it's often very hard to get them to speak Dutch to you once they know you're English. The only time I've ever heard anyone complain is one night out in Amsterdam where we met up with some Dutch people and one of them said "Oh no, are we speaking English tonight?"
Although I'm a bit surprised they'd have entire uni courses in a foreign language, but I guess it makes sense in programming precisely because it's such an advantage.
> "it's rather the exception than the norm"
> "Blood, toil, tears, and sweat are involved."
How does one learn to use idioms like a native?
Basically, delving into culture which contains common phrases, idioms and sayings scattered around. You hear/read them, understand meaning from context, and commit to memory so you can use it later on.
This is not really that different from how kids learn idioms too, isn't it?
By the way, a lot of idioms/saying are pretty similar in different countries. Their wording might be slightly off, but just by translating it in your mind you understand what it means.
Example: "Dark Horse" - One who was previously unknown and is now prominent. In Russian it is pretty much the same thing "Черная Лошадка" or if to translate it to English "Dark Horsey" ("horse" is used with affectionate diminutive suffix).
Source: Russian.
Nowadays, if you have access to the Internet, there's no excuse not to be proficient with English. I've noticed during my travel that youngsters with a bit of education (high school or better) in countries where movies/series aren't translated (because the market is just too small) have very good English level. France has an official language which means that content is vastly translated and this-is-bad(TM) - the we are slower at getting better at English.
That is so true. A lot of my compatriots seem to not realize that they are missing an incredible amount of information by disregarding English. And I often find myself angry at them when they try to argue that English is not that important and they don't need to know/learn it. So frustrating.
> France has an official language which means that content is vastly translated and this-is-bad(TM) - the we are slower at getting better at English.
Again, completely agree. I'm a huge proponent of subtitled media content and believe that that's what should be used when showing movies/tv shows on national networks (cable or sat can do whatever they want).
I should say Chance favors those with a prepared mind or Chance favors only favor people with prepared minds, perhaps minds is plural in Spanish an singular in English and this is reasoning? Can anyone confirm this reasoning or I am completely confuse?
Edited: Gooling I found people with heads are smarter, so here they use the plural. So why mind and not minds.
movies and tv help in general, but live group communication with native speakers teaches you a lot about idioms and nuances in languages.
mind you, it'll also teach you a lot of bad grammar, as a non native speaker i would've never thought of eg. 'should of / should have' .
Hopefully, it doesn't take a lot of english to be able to read programming question on stackoverflow. If you have difficulties reading english and you want to do programming, focusing on just that will help a lot. You don't really need to be able to speak or to listen which are harder (at least for me ).
Very true, but even further than that: There are very few clearly right or clearly wrong answers. There are actually very few wrong answers - but there is a stupendous amount of right answers that are bad answers. Especially: bad answers for you.
Recognizing a wrong answer is the easy part. Taking a dozen or so "right" answers and selecting and condensing them into the best answer that makes the most sense for your programming context is the hardest part.
It is astonishingly easy to accrue a tremendous amount of technical debt because you just chained up solution after solution into a grotesque mix of "works, but could explode any minute".
In my case, wanting to "do X thing in VB6" drove me to read heaps of text in English, and even if I couldn't make sense of everything I could kind of guess what they were saying from the context and some few words I recognised. Do this for a few years and you'll have decent comprehension skills in that language. I guess that's a pretty natural way to learn, rather than being drilled some abstract grammar rules.
You may be fortunate enough to have a native language that happens to share the writing system with English, but a lot of people don't. Actually, I think the majority of people don't.
For example, I'm much better at reading French than listening to it. The opposite is true of some other languages.
I'm currently trying to actively get rid of my accent. I've been asked a few times whether I'm actually British, and pretty much nobody can actually guess where I'm from.
I started pretty much the same way, trying to make sense of C++ and VB manuals when I was young and I think I have pretty good reading and writing skills now, although a native speaker can notice English is not my primary language.
Spoken English is still an obstacle for me, I moved to London a year ago, I got a pretty good pronunciation, but I still find it much harder to convey my thoughts, compared to writing them. And I'm trying hard to lose my Italian accent, luckily it's not as pronounced as the stereotypical one.
Though I have to admit I've never been a good speaker, not even in my native language.
Yeah, it's a lot harder to convey thoughts by speech in a foreign language, and I think it's because you have to make a conscious effort to find the right words or expressions. It's like getting data from RAM (foreign language) or from the L1 cache (native). It gets better though, with practice.
You can get through it, but it is slower, and looks "funny" to a "native".
In that spirit, as a native speaker: "...from the context and the few words I recognised." would work just fine.
That's english for you. When the peasants are revolting, its very different from when the food is revolting...
It makes sense to me, but I'm not a native speaker either so I don't know if there's an actual rule behind this.
http://www.oxforddictionaries.com/definition/english/some-fe...
But there are plenty of examples of phrases in English which are acceptable but which break grammar rules.
In short, you would say "a few words".
That is, while "some few" is ungainly, pausing and delivering it as though 'few' is reinforcing or clarifying 'some' (through a change in tone or similar) would sound a little archaic, perhaps, but completely natural.
My understanding is that less than 12 is a good definition of young enough. (Although, ironically in the context of this discussion, my google-fu is too weak this morning to find the reference that convinced me of this. :)
In any case, a distant 2 years of high-school German coupled with 6 months of effort last year (pretty nearly an hour a day) was not enough to give me the skill to even read a children's book in German. For some of us, learning a language is hard.
I don't agree here. First off, your two years of high school German, like my two years of high school Spanish, were likely a waste of time. I had the highest grade in class and couldn't speak a word of Spanish, although I could write simple sentences in present tense quite successfully.
I moved to a French speaking country when I was 23. Initially, like most Americans, I thought that learning languages was hard so why bother. After one year abroad I basically spoke 0 words of French. Once I decided to stay long-term I took a French class, it was once a week for two hours for about 7 months. I was teaching physics in French a few months later. Granted I wasn't fluent, but it was good enough and my students were incredibly patient. By the time my own French course started up again it was unnecessary, I was learning more than enough during the day so I quit.
The key part was that the French class was only in French from day one. You could not ask a question in any language other than French because the teacher couldn't understand you (in reality she simply feigned incomprehension). Amazingly, a good teacher can make you understand a language you don't speak by speaking to you in that language. For the life of me I don't understand why high schools in the US don't adopt this system.
Babies are great at learning languages and you have a massive advantage over them, you have the power of reason. You also have the massive disadvantage of people refusing to speak to you like a 2-year-old.
My advice, if you really want to learn German, is to spend the next 6 months speaking to someone in German for an hour everyday (there are some websites that let you do this remotely). Same time investment as before, but I'm guessing you didn't spend so much time last year actually speaking with someone. Babies don't learn to speak through books, they listen for a year and then start saying extremely simple things. Learning to read in German will do wonders for your vocabulary, but it won't allow you to have a conversation. As someone who is quite anti-social, I find this unfortunate, but the wiring required to speak another language gets put in much faster by speaking said language.
Also, don't bother learning how to speak in present tense, learn how to speak in the past and future. You want to be able to say what you did yesterday and what you are doing tomorrow. People ask you how your weekend was and what are you doing for vacation, they know what you are doing right now because you're talking to them. Surprisingly, I can't think of a language where it is harder to speak in the past or the future than in the present due to verb conjugations becoming largely trivial.
I want to emphasize that I was not an especially gifted student in my French class. We were all total beginners and by the end of the course most people were functionally speaking French.
But it still seems to me that countries where students learn foreign languages successfully at a high rate start those students before they're 12. My two years of high school was a waste, as you said yours was. But Germans (and Dutch, and Norwegians, etc.) have much better success in their schools, and they all start before the age 14 that's common for starting here in the US (though that's starting to change).
Recognizing the answer that will actually work and hold up under stress is a measure of the programmer.
A Go-cart & a Lamborghini are both "4-wheeled vehicles that will get you to the bottom of the hill"
In order to ensure the word you found in the dictionary is correct, you need to be good enough in the language. Often there will be homonymns in your native language, and you'll get the wrong word. For example you want to translate the bank of a river but end up with the place that keeps your money.
It's the same with answers you get from Google or Stack Overflow about programming. If you're not good enough to ensure they're correct, you'll be in trouble.
That's why you use a good dictionary that support phrases, and even give a context annotations[1]. That makes the advice a bit obsolete.
This is very true. Not just for technical/programming-questions but pretty much everything. Even simple wikipedia entries. There is a huge quality gap between the english Wikipedia and - for example - the german Wikipedia.
Like I said though, it wasn't just good times and passive aggressive complaining about first world problems while I read this. I can't even begin to fathom the miserable, pathetic, and generally small, unexamined existence that would lead one to believe that h(s)e is somehow the victim of deep injustice at the hands of those people with their prejudiced technical abilities and natural curiosity! How dare they not level the playing field just because she never bothered to explore the use of code outside the classroom; clearly everyone missed that she's the subjugated one, with a comfortable liberal arts education and regular internet access.
But still, we should all take a moment to recognize the plight of the comfortable, generally satisfactory lives of those among us struggling silently with the burden of "technical un-privilege."
Am I on the inside?
I'm sure it would have been easier to lean on the fact that I'm the son of two computer programmers, always had a computer (and various manuals) in the house, and started learning C when I was 10 - and to look at the plight of people who were less fortunate than me as a "first world problem", as education and employment are normally rarely described.
>But still, we should all take a moment to recognize the plight of the comfortable, generally satisfactory lives of those among us struggling silently with the burden of "technical un-privilege."
Because everybody who goes to college must come from comfortable, generally satisfactory lives - they all must have grown up with the internet, owned computers, went to good schools, and couldn't have come from crushing poverty or from the third world. They must have all been exactly like you, except lazy.
I must be misunderstanding your post, because it seems exceptionally cruel, in an cocky, stupid way.
It made me reconsider what "technical privilege" really means and why I think it's a valid thing. Exposure to computers and technology outside of the classroom is definitely becoming more common, but not the kind of hobbyist interest that this article talks about.
[1] http://www.npr.org/blogs/money/2014/10/21/357629765/when-wom...
I came to computers from electronics and for me, Data Structures and Algorithms was (to an extent, still is) black magic with Don Knuth the presiding head wizard. For me, compilers, filesystems and OS internals were all sort of deep dark places that I wasn't equipped to handle. On the other hand, banging out a shell script, spewing perl, or reciting python was just a matter of figuring out the right set of incantations ...not really hard. I learned html, css, js, a lot of python and was (/am) happy to just 'get-things-done' with these skills. I looked at people who could talk about BigO, concurrency, monads and the rest as the 'privileged' -- I could never be /that/ good. And yes, I thought all of this was relevant to software engineering (as opposed to science) and that I would never get there. Fortunately, I no longer think this. Thanks to all the resources available online these days, the limits, I know now, are not inherent nor are imposed by ability to understand, they are imposed simply by time for learning and practice. So, I am still learning and yes, in that sense, the art of googling well can make you a better programmer -- irrespective of what you know today.
I was able to pick up comp sci fundamentals from various awesome online tutorials and even just good old Wikipedia.
It's interesting to watch how they work and the kinds of outputs they produce. Quite a lot of the stuff works... mostly...
It's entirely untestable, not repeatable, undocumented and just stuck together with flaky glue code.
Sure, if you aiming to "make it work" you can do that. If you're aiming to do well... I suggest learning proper technique.
I have a Software Engineering degree (certified Engineer), so I already have a superiority complex anyway ;)
Code that's testable, repeatable, well-documented and elegant doesn't guarantee that an application will actually meet anyone's needs in a commercially sufficient manner.
The WordPress code base is frequently criticized, and the Facebook index.php code from 2007[1] will probably make some people cringe, but these are just two of many examples demonstrating that if you want to "do well", building applications that work and meet the needs of their users is initially a lot more important than "proper technique."
Testing and documentation make a difference in the long term. Unless your business model is "build a shiny tower and sell it before it crumbles", at some point, you'll have to fix the mess you made in the early days of the application.
I have talked with some developers about my observations and almost all of them had a similar anecdote to tell. Some of them included CS grads with a similar "good enough" mindset.
These anectodes are in no way a representable study, but for me, it put the radical professionalism movement of Uncle Bob in a whole new context.
Proper technique and best practices are definitely important. They can, however, be a part of the self-learning process, just like learning how to write the program itself.
What a terrible advice.
About javascript(vanilla js), nobody even wants touch it anymore. Almost anybody who interacts with javascript code does it with a 5 foot stick(coffescript, clojurescript), and/or behind huge frameworks that protects you from its perils.
Something that is more usable and understandable in its barebones state like python makes more sense for beginners.
There is a huge amount of tooling these days and specially the Node.js community and ecosystem are flourishing. Code coverage, static analysis, test frameworks for every use case imaginable, you name it.
Coffeescript and its brethren are a "solution" for people who are not interested in JavaScript and don't care about performance / maintainability in the long term. The additional compile step and the resulting problems with not being able to know exactly what it ends up generating become a huge burden in the long run. If you're really good in JS, you know what we'll be JIT'ted and what not, just like a really good C++ developer knows what the compiler will eventually optimize away and what not.
Seriously, building your cool, new library in <Insert Fancy New Compile to JS Language here> is like writing the latest addition to Boost in C89. Nobody wants to depend on it in the long run.
From what I have seen, the people who are mainly using things like Coffeescript are coming from Ruby or Python and want their cool-aid back.
If you don't want to learn a language, don't use it and if that means you won't be able to do stuff on the web, well I'm totally fine with that. I've seen enough code that looked like a J2EE developer just started coding C the other day.
Learning a language with prototype-based inheritance would serve less for a beginner than a professional.
That's your personal opinion, and frankly, it reeks of elitism.
Actually, it was. If you read the rest of the parent's comment, he completes that sentence with: "...and sure as hell HTML/CSS is not programming."
So it's pretty clear from the way the sentence is written that the parent has clearly established some sort of hierarchy in his mind, and what he actually meant was, "web programming is not real programming."
No, it wasn't. Read it more carefully. You may be right about the beliefs of the author, and I don't endorse the entirety of the comment, but "web programming is not programming" was not said anywhere there, and the principle of charity would suggest you should at least make sure that is what the author was trying to convey before lambasting them for it.
"If you read the rest of the parent's comment"
I did. Before I replied to you, even.
'he completes that sentence with: "...and sure as hell HTML/CSS is not programming."'
HTML/CSS is not programming, it's markup. Markdown and LaTeX are also not programming. That doesn't mean there can't be plenty of programming that involves those.
'So it's pretty clear from the way the sentence is written that the parent has clearly established some sort of hierarchy in his mind, and what he actually meant was, "web programming is not real programming."'
It's plausible, but again, principle of charity.
"See look, it's not so hard to talk to a computer. Those words on TV aren't all gibberish."
It's not like it teaches bad practices like a number of other "entry level" languages do. I'm sure the majority of people in my generation (late 20's, early 30's) started with HTML/CSS when they were kids.
I initially tried js/html with the kids in my school, and although it was fun because they were making making visual things, it turned them away from the console. This is not a good thing since the console is where they have to do a lot of the work, and having an aversion to it is one of the worst things that can happen to you.
I simply state this as my experience. Yours might be different.
Writing some code that works, though, doesn't forward the state of the art. I was lucky enough to take AP computer science in high school. I remember arguing with the teacher when she criticized my code in front of the class. I said something along the lines of "Well, it runs and produces the right output!" She then lit into me, explaining that the structure of the code, its readability and maintainability were at least as important as its output. I've carried that lesson with me in the 19 years since, and had in reinforced multiple times over.
The art of "Googling well" won't teach you good abstraction and maintainability, and yet I would argue it is one difference between junior engineers and (good) senior engineers. We talk about learning all these frameworks, but that's not nearly as useful as developing the skills to create the next powerful abstraction to make a class of hard or time-consuming problems easier or faster to solve. You won't learn how to do that on Stack Overflow.
Part of the issue is that it's much more rewarding to add a new shiny feature than it is to refactor the existing mess, but another part is I'm not really sure what goes where. Most online courses targeted at inexperienced programmers teach x feature of y programming language, instead of practical software engineering... as a result I feel like I've learned how to build a fancy stained glass door for a house that has an unstable foundation.
I've often thought I'd like to hire a senior dev to sit with me and help me work through building an app the 'correct' way... but short of that I'd love to know of any books or web resources that would help.
Think of your code like an essay. Write comments on the motivation for decisions you make, not just what the codes does. Think of the exercise not as trying to just produce writing code, but to make the next person reading the code feel like they were with you the whole way, making decisions together, working out problems on a whiteboard.
While doing this, don't be afraid of honesty, don't be afraid of verbosity, and always have empathy for the next person reading your code.
1.) Read your code after you write it. I do this via git diff --cached. It's amazing how many bugs you catch this way. Be critical of variable names, code layout or confusion, lack of documentation. It's basically doing your own code review. Is it documented? Is it tested? Does it make sense logically? Is it easy to read?
2.) Document stuff. Fluff documentation is even fine to start with, you'll eventually learn to separate the important documentation from fluff. Ultimately you need to get to the point of the "why" code does what it does, not the "what" it does. "What" it does should be evident by the code itself and the variable names/etc.
3.) Plan ahead. I don't mean pseudo-code per-se...more thinking or writing down how code will fit together. Mind mapping is great for this, particularly with a white board or tile. I have a Galaxy Note that I bought partially for this purpose and use Papyrus for it now. Basically, how do the abstractions and parts fit together? Is it logical? Not everything requires a whiteboard, but a few minutes of thinking ahead can help spaghetti code a lot.
4.) Learn different programming paradigms. OO style can quickly become un-maintainable even to pros. I suggest learning functional programming in a language like Scheme/Clojure, Lisp, or Erlang. I now pick up a new language every year in different paradigms...not so much to learn the language or to brag, but to learn different way things can be architected, and the way other languages do things.
5.) Do refactor. Outside of budget constraints, don't be afraid to rewrite code that doesn't seem to flow properly.
You mentioned sitting with a senior dev...that was pretty huge for me too, even in limited times. (I'm not sure I'd pay for it, but it did cut the learning curve down quite a bit) Having someone do code reviews of your code that knows what they're doing and invests time in it is helpful too. I've found though that not every Senior dev is good at reviewing code or teaching...
Sorry, I don't have any actual resources for this other than well structured code like Django (mostly) or sqlite. I now have a B.S. in CS and I don't really think they teach this well in schools either. Patterns will only get you so far in OO too...generally, trying new languages, reading code, and refactoring has made the largest impact on me.
This way you force yourself to think outside your programming language and also forces you to write the corresponding comments.
I think this has a name as a methodology but cant remember it.
Mentoring with a senior dev is a great idea if you can find someone willing to sit down with you, but just doing the work of going through real world code is well worth your time IMO.
Another point I get from this is both a critique and praise for CS learned in a liberal arts college. You felt unqualified for getting a software engineering job, which is something that really needs to be addressed in small LACs. On the other hand, academic rigor probably prepared you well for cutting through bullshit that surrounds fashionable technologies. For example, you may not have heard of Heroku, but you may have learned about networking protocols and virtualization, which I think is the harder part to learn.
I think you struck a good community by choosing web development (a bit biased), but I'd like to amend that with a word for the road not taken, which is that back-end programming is becoming really, really accessible as well. Tutorials for Flask, Node, and Rails are just as prevalent (and potentially misleading) as HTML tutorials of yore. Now anyone with a mac (and even windows! would you believe that!) can set up a server and push "hello world" to heroku.
Anyway, I'm looking forward to seeing "How to become a Googler, or the art of ????? well". I don't know what ???? is but I imagine it involves a lot of frustrated inability to Google things :)
Don't be fooled by this false sense of know-how when you just start being able to write some html/js stuff.
Googling a problem is a reflex when you start coding, and yes, good or bad googling abilities could be the difference between you still being in the industry in 5 years or not.
But, still, this is only a first step on your path, and stopping there will also stop you from being a real hacker.
There are things that just can't be resolved with a single search: "How to center a div in CSS" is not like "How to share load across different servers", because a big question must be divided into a lot a smaller ones, and there comes the difference between you and your "code-god compatriot".
So the real path looks more like this: 1- read good literature (CS, functionnal programming, network, etc), 2- exercise, 3- read good code, 4- exercise, 5- goto 1.
Anyhow, best of luck at Google ;)
14 years of learning later, I now realize how little I know.
For example, I'm currently helping some fellow students with their F# assignments, even though I don't do F# at all. I just know what to google, because I know the concepts that I need translated to the specific syntax.
[0] Maybe Lisp, but Haskell is way too different from other languages in the way to programme. I'm currently learning it, but it's by far the language that has taken me the longest.
Lisp ought to be easy since all you basically have to learn is: "(function parameter1 ... parameterN)".
Coming from Lisp I've been trying to learn some Haskell and holy cow syntax[1]! There's a lot to parse and know (compared to Lisp) before being able to write a small program.
[1] I know it is not literally syntax but mostly function calls, it's still a lot of extra special characters one needs to know about.
In short: every time I thought I know "most" of what there is to know about something I soon discovered that I was wrong, and that "something" was a vast area which I didn't really explore at all except for a tiny little fraction of my immediate surroundings.
Then I applied for a course in Programming paradigms, that boiled to 4 weeks of haskell and then 4 weeks of prolog.
So, definitely add prolog to your list :-) It was eye opening :)
There's nothing worse than a programmer that fits together code snippets from Stackoverflow and similar sites without understanding what it is actually doing.
I think the some of the best developers are those who are smart enough to have gotten a CS degree but skipped a bit of the academics. (A bit self serving: I graduated high school in 1996, had my first intro IT job by the fall of 1998, and had my first real programming job in January 2000, while my contemporaries were still in college)
My take? I'm biased because I was educated as a researcher. I can name-drop three famous professors at my alma mater (and yes, I did study under all three), but what really pushed me was getting a job, on campus, writing software to support PhD candidates in another discipline. I quickly made the jump from researcher to practicum precisely because I was trained as a researcher, then applied those skills to understanding what my customers needed.
Seems to me this guy found his own "push". And yet, he's still a researcher.
I think what allowed you to make that jump was that you were inherently familiar with the problem domain; even though your customers did research in another discipline, at the end of the day they were still researchers.
I was the lead trainer at my company, and the training materials (hundreds of pages of them) used to be on Word documents. I got fed up with it, taught myself Rails, developed and deployed a learning management system, and migrated the content there. It was very successful because as the lead trainer, I knew exactly what features would be needed and how they should work. It was kind of funny actually because when I gave a demo to the trainers in other teams, they basically said, "wow, this is exactly what we need -- when can we start using it?" Which is music to any programmer's ears.
The first time I met him, he was in the middle of writing a
script to scrape Craigslist of all its free furniture
listings (which is illegal, btw).
Kind of funny that software engineering is compared to an athlete. In the current situation, I'd compare it with a headless chicken.
If you literally never heard about any of those during your computer science courses, you attended a sad, sad university.