I am very illiterate in C, but I am put off by singling out C as an unproductive language. C might not be the best language high-level tasks, but I know more than one person that is as least as productive in C as I am in several scripting languages. C is a cool and productive language to begin with if you are interested in the stuff C is good for.
I would very much prefer if that paragraph encouraged learning multiple languages early and comparing them. I had my first CS professor at the university do that with me: I learned ML, C and Java in the first 2 month of studies. I only understood half of it, but it already showed me one thing: languages are tools as everything else in the CS world. Different tasks, different tools.
I'm not sure I agree that learning multiple languages in the first 2 months of studies is a good approach. I think it's difficult to appreciate the advantages and disadvantages of a language until you've really used it for a while, and I'd underline that several times if we're talking about a new programmer learning their first languages. Better to learn one (ideally well-chosen) language well enough that they have their footing, so that they can put other languages in context and understand the problems they solve (or create!).
I partly agree with you that learning multiple languages helps. But how long do you keep doing that? Instead, pick some language and just create something. It satisfies the creator's thirst.
Your point makes me agree with Paul Graham, that there is a fine line dividing those who learn stuff for fun (academics) and those who create stuff for fun (creators/hackers). I love how Paul Graham's essay "Hackers and Painters" (http://paulgraham.com/hp.html) differentiates Math guys, traditional CS guys and the hackers(creators).
I'll have to mention that at some point, the interests of these 3 kinds of guys overlap and IMO, that overlapping point is programming.
Oh, I wouldn't say that you should not stick with one. In the end, I ended up with just doing Java for university and learning a co-language (Ruby) for personal pleasure and fun. Pick early on. You can also pick based on the support you gain from the community for your special problem. But at least have a look at some of the tools that are handed to you instead of blindly picking one.
The problem I see is that a lot of people stick with the first language they ran over, even if it was not fit to solve their initial problem.
Slightly opinionated, but good post. My only objection is to the statement:
> Initially, screw the algorithms and data structures
If this is not the worst advice to a beginner, then I do not know what is.
What's so complicated about data structures like stacks, queues, linked lists, basic trees. What's so difficult about learning basic sorting, searching and traversal algorithms. I mean, if those are difficult for someone, probably they should not be programming. I know I would not hire such people.
If you learn the data structure and algorithms, it is possible when you need them you will know where to look and what to look for, even if you do not know the exact data structure or the algorithm you need. But if you do not have any idea of data structures or algorithms how will you know that you need them.
Look at advice to beginners like a conversion funnel. If you end up losing 90% of people who try programming when you start them off with data structures and lose only 80% if you start them off with a little JavaScript game why not start them off on the latter? After their first public launch they will cling to interesting topics, but in the beginning it just seems like route memorization. The what but not the why.
I do not say one should implement a linked list before writing the customary Hello, World program. Off course, it will be a couple of months before a "first time programmer" implements the first data structure program. But saying "Screw 'em! You can learn them when you need them" is a very very bad advice.
One should be aware of data structures and algorithms before writing any non-trivial program. Heck, data structures should be everyone's first non-trivial programs.
Whenever I pick up a new programming language, first thing I do is implement simple data structures like stacks, queues, linked lists etc. I have found that this way I can learn the most important parts of the language at hand pretty quickly. This is a habit I picked up when I first learnt data structures and this has stayed with me and has been paying me off handsomely.
IMHO, author's point is to motivate future programmers to create stuff. To create stuff you need right attitude and to be excited about it.
Algorithms on other hand are already created. And “When you don’t create things, you become defined by your tastes rather than ability.", tastes to algorithms in this case..
When I say learn data structures and algorithms. I do not mean simply read up on the code. I learned programming, data structures and algorithms, under the man named Vinod Vishen. He never let us see any code or any book. He would explain the algorithm to us and provide a printed explanation on a plain piece of paper. Then we had to implement the algorithms in code ourselves. This approach worked wonders.
Initially, It took us days to implement even simplest of algorithms because we were encouraged to constantly improve our code bit by bit. Only when he was satisfied with what we had implemented would he allow us to look at the code in the book. He taught us to think independently. Independent of the book. Unfortunately this method got a bit lost as the number his students increased from 30 - 40 to hundreds.
No wonder most of the people from my batch and my seniors went on to start small but successful companies like me. Even today, most of the people I have hired are either from my batch or my seniors.
I have never met a single person who delayed learning data structures and was good at programming.
Heh.. I never _met_ in real life single person studying CS and being a good at programming. So what? =))
I also was studying network engineering, not CS, but I still believe I am good programmer and clients willing to pay for my work only prove it more.
This is regarding your aggressiveness of the last line...
Now - what you are saying is basically what I meant - do not just learn (as memorizing) algo, but try to implement it yourself, or better - stuck with a problem where you have to implement algo yourself not knowing such algo already exists and described. (of course, this is not applicable when you work for a client, that's why 'fun' period is necessary =))
I credit a lot of my success as a developer to starting out with C as my primary language. Of course, I graduated an Electrical Engineer, so I might be biased. :) My first gig was writing firmware for disk drives with some of the most talented people I've ever had the privilege of working with, and starting w/ a solid foundation in C gave me an appreciation for how "things work" at a very low level. I think it must be harder to understand what compilers and interpreters actually do without that background.
Overall, good post to people learning. I've been teaching myself programming and have more or less followed this advice, though I'm also working through SICP and planning to continue with K&R and Cormen afterwards. For an approach that's more grounded in CS fundemantals, I highly recommend what Joel Spolsky has to say: http://stackoverflow.com/questions/414779/what-should-a-self...
My learning curve so far has been a balance between building something for fun and learning CS basics.
I think your balanced approach is better than what is proposed in the post. It's good to just get started doing stuff in a language like Python or Ruby, but a serious programmer should also try to learn real computer science along the way, either through college or self-study.
"if you are aspiring to be a web developer, you’ll need atleast basic knowledge of linux."
No, you won't. There are thousands of enterprise level web development jobs that don't use Linux. And I say that knowing how to deploy web apps on Linux myself.
If you want to be a top level web developer, you'd better understand how to build apps in multiple languages, not just the one you learned when you were a teenager and it was free.
I'll also formulate that differently. One of the tasks I usually give to newbies is to configure a Linux or BSD with a running Apache/Nginx/whatever from ground up. (for example using Gentoo Stage 1, as I know that it has hidden bugs)
I don't do that because I think they should learn Linux by heart, but because it gives you a great insight on how an operating system distribution is put together: what is fixed, which parts are moving. Its a quick run through everything that you cannot get using Windows or Mac OS X.
And what does that mean? Know how to write apps? How to use your favorite shell? What the Kernel loadable-drive API? Know the Kernel internal API? Know how to build packages? Learn how to port Linux to new hardware? Know how to administer linux services?
There are folks with facility in just a couple of those that know they are "linux experts", and they are right. They are all valuable. Which ones are we talking about here?
Only thing I would add is work on projects complicated enough that you would need to learn data structures eventually. Whenever I try to read about trees and hashmaps my eyes glaze over. It's only in practice that I find I learn data structures and how to use them. After watching something speed up, it is pretty easy to sit down and read some theory for an hour or two.
It's not so much that I disagree with OP, it's just that I've never done much of what he recommends.
Initially, screw the algorithms and data structures.
That's like saying, "Initially, screw the basement and build the attic." The number one problem I've ever seen with shitty code, over and over and over again, is lack of understanding of fundamentals. Do yourself a favor and learn how to build things properly first. Poorly structured data cannot be overcome by the greatest of processes. Poorly structured processes will give you technical debt forever.
Choose a good language. One that you think you can produce something useful in short time.
This is a chicken and egg problem. How would anyone know which language to choose without using it first? Choose anything, just get to work. (When in doubt, choose something popular. Things will be tough enough without running into problems no one has ever seen before.)
Choose a good editor.
No. The more features and functions an editor or EDI has, the more crutches you'll routinely use when you don't need them. Which means you won't learn and grow as quickly. Choose something simple like Textpad, disable the syntax color highlighting, and make mistakes. Sure, it'll be a pain in the ass, but that's the best way to learn the quickest.
Use an operating system that’ll teach you something.
If you are paying enough attention to the operating system to know what it is, then you aren't paying enough attention to what you're building. Focus on what you're building. Get it to work properly on any operating system. Let someone else worry about porting or emulating on other operating systems later.
Don’t copy-paste files to backup stuff.
I've been doing this for 30 years and have never lost anything. I save every old version. Relying on special software to do this for you makes you dependent on that software so much so that you may lose track in your head of what you have. Other programmers may disagree with me; it just shows that there is more than one way to do things.
Know where to get help.
The more popular your choices are, the easier it is to do this. (Don't make the same mistake as me: using specialty and proprietary technologies. When Technology A and Technology B don't play nicely together, it's really hard to find someone else who has experienced the same problem.)
Develop your netiquette.
"netiquette" shouldn't be any different from any other etiquette. Just treat others the way you'd like to be treated.
Meet people, because books only teach you routine stuff (oh and the "book" is dead they say).
People aren't much better than books. The best teacher is building stuff.
Write opensource code.
I've never done this and have never understood why people think it's so important. I prefer to build stuff for paying customers. They're never bashful and are a great way to get really good really quickly.
I have to say that I agree with the article on 'screwing the algorithms and data structures'.
Sure, if you want to be a good, successful programmer, you need to know your algorithms and data structures, inside out, back to front, whilst underwater being surrounded by sharks. This is far more important than being up-to-date with language X or framework Y.
However (and this is a big however), the letter is targeted at people who are thinking about learning to program, in which case it's important for them to actually achieve something quickly, so that they will be encouraged to continue.
When I started to program (at the grand age of 3), I wrote absolutely terrible programs in BBC-Basic. For years I wrote lines and lines of code without a single function, procedure or subroutine. Even Arrays, lists and such were beyond me.
I didn't care though. I had written stuff that worked. I had created text based adventure games that the computer would play with me. To a young kid, that feeling of power, creativity and success was like a drug, and I was addicted.
If instead, I'd spent ages reading books to work out whether I should be using quicksort or radixsort, or whether my Hashmap would scale well enough, I'd have gotten bored and never written anything, and probably become an accountant.
> No. The more features and functions an editor or EDI has, the more crutches you'll routinely use when you don't need them. Which means you won't learn and grow as quickly. Choose something simple like Textpad, disable the syntax color highlighting, and make mistakes. Sure, it'll be a pain in the ass, but that's the best way to learn the quickest.
I disagree...disabling syntax highlighting is crazy advice. This is not endurance training with sand bags on the ankles, and there is no real long-term benefit of having a syntax-unaware editor. I'd instead recommend using an editor with basic support for many file types, like vim, emacs, or TextMate (or something like notepad++ for windows, which I can't comment on) to eliminate as much as possible the chilling effect on picking up something new, caused by "uh oh, my editor has no clue what this is."
Thanks everyone for the comments on the blog post. I don't know how whoever submitted this found this one. This started as a letter to my junior in college who asked me for advice on where to start.
The number one problem I've ever seen with shitty code, over and over and over again, is lack of understanding of fundamentals.
I humbly beg to differ and would stick to my words - "Initially, screwing the algorithms and data structures". I guess I should have written the word "initially" in all-caps.
I feel that to be creative as a programmer, it's very essential that you can fuel your creative self by motivation. And that can happen not by reading too much about how to do it, but instead just jumping into the pool and checking it out (which a you, me and a lot others agree on). Later on, when interested to improve, the theory part can be learnt. The intention was not to scare away those who want to begin by telling them there's a learning curve to be followed and instead just say "here's what you can do, check these out, install these stuff and get started".
How would anyone know which language to choose without using it first?
Which is why I mentioned trying out some languages for a few hours and choosing something of personal taste + something with good docs (getting started, tutorials, etc).
About backing up files by copy-paste, IMO, it's just personal choice. Whatever works for you. Since the post was targeted at someone who wanted to begin, I thought I should clearly mention to the reader that better tools existed.
I prefer to build stuff for paying customers.
Atleast to get to that point where you 'can' build stuff for paying customers, you have to start somewhere. First, finding paying customers isn't that easy for everyone. Second, when you don't know programming at all, and are trying to deliver something technical to a paying customer, IMO, it's just building castles in the air.
> I've been doing this for 30 years and have never lost anything.
Just because it works for you doesn't mean it's good advice. I don't doubt copy+paste has worked for you for $LONG_TIME but I wonder whether you would say the same thing if you had started using $VERSION_CONTROL_SOFTWARE $LONG_TIME ago.
Having finally gotten into the habit of doing all my development with the help of version control I can't imaging going back to copy+paste or project/backup/YYYYMMDD. Yes it works but all it is is a poorly, and incosistently implemented manual version control system with none of the advantages of a real VCS.
> I've never done this and have never understood why people think it's so important. I prefer to build stuff for paying customers. They're never bashful and are a great way to get really good really quickly.
I'm not sure if you mean in a startup context or a freelancing, but both have some degree of urgency that don't promote writing great code and developing new skills. It's very tempting to stick with what you know because you're out of time and don't want to take a chance on something new.
That said, it's also easy to fall into the trap of never releasing anything so I prefer a mixture of both.
I've never done this and have never understood why people think it's so important. I prefer to build stuff for paying customers. They're never bashful and are a great way to get really good really quickly
This is explicitly advice to new programmers. If you're established and have people who want to pay you money, sticking to paying customers makes sense. But do you really think that applies to people who are new? I mean, who in their right mind would want to pay Joe Justlearnedpython to build their stuff? From what I hear, even many people who actually know what they're doing but haven't had their name "out there" have a hard time finding paying work.
(I can't speak from experience. I'm not primarily a freelancer, and I pretty much only do it when somebody I know comes up to me and says, "Hey, I need X. Can you provide it?" But I don't feel like I could just magically get clients if I wanted them.)
I have to agree with the fact that one has to be patient when it comes to programming,it takes time because its skill that needs to be mastered by repetition.Also it doesn't improve you if you always code alone,large projects are done by teams so it is important to start working with other coders as soon as possible.
The first thing I do when someone tells me that they want to learn how to program is teach them how finite state automata work. If they seem to enjoy that, walk them through the NFA to regular expression proofs. Then we have a talk about the data structures that would be involved in storing and manipulating automata, regular expressions, and their input. Finally, I recommend that they start playing with SICP or How to Design Programs. The people that I've introduced to programming this way have a fairly sophisticated, "no-magic" attitude earlier than is normal. Introducing automata first provides a really good way to talk about machine model (automata itself) and programming language (how to specify the automata).
"The only thing you learn using Windows is to click the .exe file to install the software and use it."
really? is that the only thing you can learn on windows?
"if you are aspiring to be a web developer, you’ll need at least basic knowledge of Linux"
again, that's just plain misleading. Will web not exist w/out LAMP? Are web apps hosted in IIS (or on any other OS than Linux) inferior to the ones hosted in Apache?
"Linux also allows you to customize stuff the way you need them to be."
what stuff?? you can write your own web server on windows.. everything in .Net framework is extensible and substitutable. You can write perl, php, or python apps. You can provide your own http handler implementation that will do whatever you tell it to.
You can, but general attitude from windows programming community is to do one "right" way.
I had real hacking feeling with windows development only when I was doing some assembler windows programming. But this makes sense, since I was communicating in the same community where real (virii, malware writer) hackers were asking/answering internals-related questions.
For me it works like this (not just programming, but car tuning, guitar playing, house building... all random stuff i like to do, often not for profit):
1) get excited about something
2) forget about rules, advises from experts/"experts" and do it how you feel you should do it. less constraints in the beginning - more chance you will never notice these artificial walls.
3) get stuck many/many times in some basic stuff, because of #2 =))
4) start to read/learn/ask knowledge from expert sources.
In short - try and then learn right way.
Again, it works for me, but I believe - this way of thinking is true hackerish way.
I think we should be funneling new programmers to languages that are easy to recover in. I have a few years of programming experience, but I've been taking a course that taught in C++.
Do you know how easy it is to write syntactically incorrect code in c++ that compiles yet dumps upon program execution? Do you know how hard it is for someone with little experience in the language to diagnose segment faults without a line number?
I recommend Java and Python. I avoid C++, C, and Ruby.
I feel he neglects to mention how excruciating frustrating it is trying to learn Vim. Evrytime I try it is stop after an hour or so, laugh, and say this has to be some sort of joke. Unix programs like that seem to violate just about every human computer interface principle imaginable. Everything is hidden from you, nothing is self evident. Maybe after a lot of practice and memorisation you see good productivity gains but at least warn people what they're in for.
Wow? This is terrible advice. Probably written by someone who didn't get a real 4-year CS degree? I am afraid you don't even know what you don't know.
You don't need to know every single algorithm and data structure, but you definitely do need to know the basics, especially how to evaluate the different algorithms, how to choose the right one for your needs, how to create new ones and how to prove correctness. This is one of the most fundamental of skills for a programmer.
C is actually one of the easiest programming languages to learn, because it is so close to the hardware. It is one of the hardest languages to write real programs in, because of this closeness to hardware, but it is also one of the most important languages to know, and to learn first, because of this. Without a basic understanding of C or assembly, without a basic understanding how high-level code gets compiled into machine code, you won't understand the performance costs of classes and recursive function calls, issues like memory fragmentation, cache misses, etc. Basically unless you never plan to write fast code, you need to know something like C.
Vim and emacs have been around more than 20 years .. They are the old reliable but there are better alternatives now with less of a learning curve and modern innovations. Eclipse, IntelliJ, Visual Studio comes to mind, there are many other IDEs out there. If you are willing to put in the time, emacs is probably better than everything else out there, but if you are still learning to be a programmer there is no reason to be struggling with your editor too. Eclipse is a good free solution that most people can start out with.
I would very much prefer if that paragraph encouraged learning multiple languages early and comparing them. I had my first CS professor at the university do that with me: I learned ML, C and Java in the first 2 month of studies. I only understood half of it, but it already showed me one thing: languages are tools as everything else in the CS world. Different tasks, different tools.