12.11.2006

Be a programmer, but not today

This author is pretty much correct, but I have to expand on it a bit. You can't become a good developer in 21 days, although if you are already experienced, you can learn a new language pretty fast. Probably you can't become a good developer in less than 5 years, and that's if you have a natural aptitude for it. Ten years of plugging away at something doesn't make you an expert either. I've played guitar for 20 years and I pretty much still suck at it, but I enjoy it and I am 100x better than I was after my first week of playing. The one thing I think this author and everyone who addresses this question, is missing is the suggestion that learning programming languages means anything at all. If you want to be a good developer, focusing on languages is not the way to go. Everything else I agree with but I would phrase it a different way:

1. Make sure you enjoy it. Good programmers really love coding. They are known for staying up for days on end to write code, because they are so excited about it that they can't sleep. BTW, it's not the coding that keeps me up at night, it's the pursuit of better ways to solve a problem. Very important: be a connoisseur of problem-solving, and methods of attack. A good programmer is just as likely to stay up all night solving a crossword as they are to be coding.

2. Talk. Be social. One thing that I wish would come back into vogue is the development-based user group. I'm talkin about local groups that get together in person. Online forums are great but no substitute for crowding around a screen and actually learning something in a group. Know programmers, meet them in person, have drinks. Get out in the real world and interact. Programmers are known for being an antisocial bunch, but the best programmers love to get together and share.

3. Practice, a lot. Start by building the hello world example to get a feel for whatever you're learning, but then go ahead and dive into something complex. Figure it out along the way, by using #1 and #2. When I learned C++, the first thing I made (after hello world) was a linear algebra class library. One of the first BASIC programs I ever completed was a version of Othello for the Vic-20. Do something like that... if you can't hack it, better that you learn that early. Getting bogged down with things you don't understand isn't the way to go, but learn concepts slowly and build them up into a complex program.

4. Get a degree... if you want to work as a programmer. Having a degree will help open up more opportunities... it's like Boot Camp for higher-level jobs. Your degree does not have to be in Computer Science, just have a degree in something. My degree is in Biology, with minors in CS and Math... this helps tremendously.

5. Debug - a lot. Debug your own code, upgrade your own code after a few years of ignoring it. Read lots of sample code and try to hack sample projects you find. Debug someone else's mistake. Answer questions on forums. Accidentally break something and then fix it. Knowing what can go wrong is half the battle of preventing it. Being able to handle the unexpected is the other half.

6. Know how computers work. You should have knowledge of what it means to write a computer instruction, and what will happen at the electronic level when your code is executed. Know how processors execute instructions, and know how data is transferred around to various parts of the system. Know the parts of the system, and be able to compare their differences and know about their similarities. A hard drive has a bunch of chips in it... what are they doing, and how are they different from the cpu or the gpu or the math co-processor chips? Those are the questions you should have knowledge of... not expert knowledge, but basic knowledge of how it works.

7. Learn 2 programming languages - SQL and something else. SQL is the most commonly used declarative language, and you will need to know it for most jobs. Don't just learn the language either, learn how to use it effectively and learn it along side another language so you can compare the declarative and procedural styles and learn which to use where. Your 'something-else' language will more than likely be obsolete by the time you become an expert in anything, so struggling to learn multiple languages is a waste of time. Learn what you need to be functional now, and focus on other languages when you have time. (So, learn SQL and C#, VB or Java)

8. Without focusing on multiple languages, learn the concepts that are common to all languages. The list from the article (class abstraction (OOP), functional abstraction, syntactic abstraction, declarative specification, co-routines, paralellism) can all be learned within the framework of C# and SQL. There is no reason to learn Lisp simply to understand syntax abstraction, since almost every language supports that feature to some extent. Lisp takes it to the extreme, and IMO, is not a well-balanced language for a beginner.

I disagree about learning an interactive language (although SQL can be good in that respect). I think a developer should get used to the 'code-compile-test-debug' cycle early on. My intern is struggling right now because he doesn't compile often enough... so when he finally does, he has introduced lots of errors, which sometimes compound each other. Learn the consequences of that behavior right up front.

When you are an expert, you will be able to learn a new language in 21 days, maybe less, so the book titles are misleading by making you think they are targeted to 'fast-track' beginners. If you've ever read one of those books, you would see what I mean... it basically starts by saying you need to know the basic concepts of programming as a prerequisite for understanding the book (usually). I learned C# in a few days, but I had years of experience with the concepts first. The "dummies" books are for beginners, and if you take a look at the Java for Dummies book and the Java in 21 days book (both of which I own), you can see that difference. One is focused on learning both the concepts and the language, while the other is focused on quickly learning the language, but assumes you understand the basics already.

So yeah, teach yourself a language in 21 days if you want to, but if you want to be a good developer, you're going to do a lot more than just learn a language or two.

Good luck!
Jasmine

3 comments:

Unknown said...

After reading this article I do have to say that I think it's quite short-sighted to say that it's a waste of time learning multiple languages. I also don't quite agree with Pete Norvig here -- the importance of learning multiple languages is not just learning various "programming concept", but to train yourself in solving the same problem in different ways. From my point of view, each language, though supports many programming concept, encourages only a certain programming paradigm, and these can not simply be categorized as "functional", or "OOP", or "imperative", but more of something cultural, like Ruby encouraging Duck Typing, like Haskell encouraging very concise, recursive programs that are best for reasoning. C# is built based on other languages. It copies programming concepts from other languages, but it can never copy the spirits of other languages, it may eventually form its own paradigm, or may become another Java, which in my opinion is just a redundant language, because "a language is not worth learning if it doesn't alter the way you think". SQL is not a general purpose language at all, so in my definitions it's just a "tool" rather than a "language". Well, if you're happy to always solve the same problem in the same way, that's absolutely fine, and you'll become a good developer eventually but nothing more, and I see that's complete against the creative nature of the activity of programming.

Unknown said...

Don't agree with you on that it's a waste of time to learn multiple languages. But I don't want to convince you.

Jasmine said...

It's not a total waste of time to learn multiple languages, but for the purpose of becoming a great developer, it doesn't get you what you want. I agree with you that exposure to other cultures and different approaches to the same problem is important, but I think that trying to learn multiple languages for that reason is forcing the issue. It's like if I taught you to hang siding with a nail gun, and then forced you to do it with a rock. It's good for you to know that the rock will drive nails, but much more productive for you to use the right tools and learn the job that way. "Wax-on, Wax-off" doesn't apply to learning programming concepts. There are plenty of reasons to know multiple languages, but this is not one of them.

The common view of SQL as a tool rather than a language is probably due to misunderstanding of the declarative vs. procedural thing. Thinking of SQL as something parenthetical is a particularly harmful thought when it is adopted by management. SQL is used in every business I've worked in, but it is a specialised language, not a general-purpose one. It's not a general-purpose language, but that doesn't make it less important. It is used to create and manipulate databases, and that is an exceedingly important operation. SQL is the one language for which the thing I said above does not apply. SQL is the only way to learn (relational) database concepts and learn them correctly.

SQL is a tool in the same way that big trucks are a tool for the Post Office. It's the crust of your pizza. It's the core of your earth. It's the big turtle upon which everything else stands. Far more than a tool... it's the tool that you will use to build the foundation of your world! Better get it right!

(I've spent a good portion of my career fixing bad SQL written by people who didn't respect the fact that the database is the foundation of the app. Bad SQL can bring a company to its knees... ignore at your own peril! I guess this is a business-focused answer though. SQL is essential for businesses, but if all you care about is games... SQL isn't going to get you very far.)

 
hit counter script