Open Letter To New Programmers
blog.akash.im
blog.akash.im
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.
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.
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.
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.
There is a reason they are called "The Basics"
Edit: Fixed a spelling.
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.
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..
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.
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 =))
Agree fully with what you say in last para. No disagreement there.
Peace.
But decent article overall.
My learning curve so far has been a balance between building something for fun and learning CS basics.
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.
PS: Learn Linux. It's an important skill.
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?
The Unix Philosophy, design of software and the idea behind the Unix are good to know and learn.
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.
Algorithmic insight = power. But it's difficult to get that insight without the context of experience.
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.
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.
Thanks for this brave sentence. I already started to think it was only me.
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.
> 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."
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'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.
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.)
"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.
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.
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.