Legal
contracts are just human programs written in English and not code; your
experience with them should make learning to program easy.
1) Choose bottom up or top down.
Bottom up programmers love GIT (a paradigm and tool for getting and sharing computer code); tend to love the Agile method (Agile software development); value writing code over planning code and shipping code over bug-free code; and generally proceed with a lore-based approach. They'll tell you that the best way to start is just to start coding, reading, doing; and that you'll slowly flood fill your way through the space. These tend to have an engineering background. If you join a company and ask to see the internal documentation and someone laughs at you, you're with a bunch of bottom ups.
Top down types, in contrast, may recommend going to get a degree first; put focus on reading and writing design documents; recommend and enforce strict adherence to style guides (the equivalent of grammar nazis in the written-English world); feature a lot more abstraction in their discussion, planning, and thinking (a chief source of 'over-engineering'); are accused of crossing bridges they haven't come to yet; and will recommend that you choose some overall targets in your quest to learn coding, and work constructively towards them. These tend to have an academic, or (pure) mathematical, background.
I'm a top down type, so that will color my advice accordingly. If you're a bottom up, you'll probably want to pay attention to bottom up advice. But hopefully what else I have to say will be somewhat useful.
2) Choose your field. There are lots of different kinds of programming; I'll categorize the bulk of most programmers into three types (controversial):
A) "near the metal", a.k.a. hardware programming. These are the people who program non-smart phones and device drivers. They dovetail with mechanical and electrical/computer engineering. They think in terms of voltages and 1's and 0's and clocks and caches and "fan out." These types tend to code in C or assembly, languages which give you a huge amount of control over individual bits and operations, but require you to do everything yourself.
B) "systems programmers" - these guys make desktop software, and operating systems. I'll also include smart phone developers here. You see people programming in C++ and C# (esp. Windows), Objective-C and Cocoa (almost exclusively Mac and IOS); and Java (Android). Sometimes you're coding stuff people can see, like GUIs - buttons and forms, choose a file, Word Processors, etc. Most of the time you're coding functional logic, the "engine" that nobody sees until something goes wrong and an opaque "Error 123302" pops up. Sorting numbers, moving data in and out of various abstractions (trees, lists, objects, queues, "boxing and unboxing"). You can often think in terms of a single computer, though depending on need and interest you may also work on massively parallel server farms as well.
C) "web programmers" - these guys tend to write the so called "backends" for websites. They may take umbrage at being split off from the systems programmers - the biggest websites, like Google or Amazon, really employ systems programmers to handle most of their operations. But at smaller websites things have a radically different feel. These guys are very often on a linux or unix terminal, and code in languages like Perl, PHP, Python, Ruby, Asp, Cold Fusion: languages which make it very quick to write something that works, but without giving you a lot of control over specifics. They spend a lot of time moving data between computers; user's computer to the front end server; front end server to the back end server; back end server to the database; reverse all that; call over to twitter or facebook's servers to get a picture or log someone in/out; etc. They should have at least some rudimentary control of SQL for talking to databases; and may be expected to be able to administrate their own servers (security, users/passwords, install new motherboards, etc.). Web programmers will also be expected to be conversant in the web display methods and means: html, css, and javascript; flash (or these days webgl); visual design. They may be able to do one or more of these things competently; if not, they better know how to at least work with designers who are.
3) Now you can (A) pick a language and (B) pick an environment/platform. Coding 3D graphics with the Visual .NET tools on and for a Windows box is going to be a very different experience from sitting in VIM over ssh to your webserver in Japan diagnosing why facebook connect fails for 1/100 of your users. Each configuration has its own little community too, almost like a national identity. If you're coding Java or python, it may make sense to actually read through the language specification early in your training. If you're dealing with, say, PERL or C++, I would recommend the complete opposite. If you're a Windows or a Mac fanboy, and buy into their developer programs, you can pay for your membership and get a lot of cool tools and friends and probably a forum where you can ask questions.
For certain languages, there are excellent book recommendations. In C++, perhaps not in the beginning but certainly before you're employed, you'll be expected to have read through Meyers' Effective C++. In Java I recommend Bloch's Effective Java. O'Reilly and Wrox have passably good introduction and intermediate texts for almost every language. For some tech, the best reference is online. Stack Overflow will be a godsend to you no matter what language and platform you're on.
Your Editor is going to be the single most important tool you use as a programmer. The tools you used to write papers in college are not going to work - you need what's called a 'plain text editor.' You can get surprisingly far with a simple editor like windows Notepad or linux nano (dirty secret; I got all the way through college and into my first job on nano), but I would highly encourage learning a professional editor earlier. A good editor practically writes your code for you; gives you undo-branches, not just linear ctrl-z; let's you search and replace text using regular expressions; and will automatically jump to the right page and paragraph in your code or anybody else's to show you relevant syntax and usage notes. The language and platform you choose may choose your editor for you; for instance Visual .NET and Apple XCode have their own editor environments which you'll be encouraged to use for those targets. Other times you may have some say; for instance in Android development you're encouraged to use Eclipse but you can just as easily use IntelliJ, vim or emacs. One way or the other, spend some time learning the tricks your Editor affords you, because it will be a massive time saver in the end.
Once you have a language, editor, platform, and hopefully a good book or website, pick a few beginner projects - think very very simple, no, simpler than that. If you're doing it right you will either break down in tears or scream very red faced at least once. That's normal. When you're working on a big physical engine, you know what bolt's stuck and won't move and you're still going to cuss and shout at it. In programming you don't even have the luxury of knowing what's not working most of the time. The whole profession rests on letting go of frustration without letting go of the problem, being thorough, and constantly warping your perspective to see what you couldn't before. That's not easy in the beginning, you're likely to be alone a lot, and when you do grudgingly go ask for help you're likely to run across a curmudgeon sniveling you off with "rtfm." So plan to get overwhelmed and let it go and promise yourself you'll come back to it.
4) Learn at least a little theory. Good Computer Science applies no matter how close or far from the metal you are as a programmer. This is the study of algorithms, running time and running space analysis, theories of programming languages and programming tools, and the handy practice of giving googleable names to things that would otherwise remain obscure (for those that know, compare googling "string concatenation" vs. "ruby + string", "double pointer" vs "C++ **", or try to describe a function closure without using that phrase.)
CLRS (Introduction to Algorithms) is hands down the best reference for theory. It will (or at least, should) be intimidating to a beginner, but this is the text that all the programmers I know review before they start interviewing for a new job.
5) Consider sidestepping everything I've said to begin with and doing something fun. If you're the type of person who learns a foreign language by picking up kids books, that approach may work well for you here too. We had a lot of luck at Harvard starting students off with Scratch (Scratch | Home | imagine, program, share). This will teach you the basics of variables, logic and logic control structures, loops, and common types of mistakes and bugs, all in a way that even a grade schooler could understand. The best part is that everything is visual - at any point you can see exactly what is happening and why. In many other languages you'll have to get really advanced just to get a colored rectangle to pop up on the screen, let alone see what's going on or understand why.
6) Learn the grunt work too. If you're going to make a career out of programming, you're going to need to know about the tools that all programmers use, but which isn't the glamorous part of the job. You'll need to know about version control, and the dreaded merge - metaphorically, how to rescue dying passengers when two programmers crash their trains into each other. You'll need to know what unit tests are and how to write them. To get hired you'll almost certainly be put in front of a whiteboard with a dry erase marker and asked to write legible code for your interviewer; and you'll also probably be expected to use some standard notation for expressing theoretical concepts (lots of circles and arrows, search 'graph theory'; and for arrays and lists you'll be drawing what looks like tape worms). You'll want to learn a diff'ing tool to see changes in a large text base. You'll want to learn a good debugger for your language/platform (some IDE's have this built in). You'll want to learn how to run a profiler to find things you can speed up or slim down in your code. You'll likely want to be able to read and convert grade school "decimal numbers" into binary, hex, and maybe octal; and have a good hexeditor at hand.
7) If you don't want to pay for a comp sci degree, there are good free courses appearing online that can give you the equivalent background, if you're dedicated enough to "go to class" when it's not required. Harvard's intro to CS is now free to the world via (About CS50x). Stanford's: Stanford School of Engineering. MIT's: Introduction to Computer Science and Programming.
There is no end to introductory books and websites on programming, and it is impossible to recommend the best ones for you without knowing you. My best meta recommendation is to understand who the author is, and what his or her background is, and ask if that coupled with their pedagogical style and narrative voice is going to take you where you want to go. No two programmers will agree what all programmers should know, or what order they should approach the material in.
1) Choose bottom up or top down.
Bottom up programmers love GIT (a paradigm and tool for getting and sharing computer code); tend to love the Agile method (Agile software development); value writing code over planning code and shipping code over bug-free code; and generally proceed with a lore-based approach. They'll tell you that the best way to start is just to start coding, reading, doing; and that you'll slowly flood fill your way through the space. These tend to have an engineering background. If you join a company and ask to see the internal documentation and someone laughs at you, you're with a bunch of bottom ups.
Top down types, in contrast, may recommend going to get a degree first; put focus on reading and writing design documents; recommend and enforce strict adherence to style guides (the equivalent of grammar nazis in the written-English world); feature a lot more abstraction in their discussion, planning, and thinking (a chief source of 'over-engineering'); are accused of crossing bridges they haven't come to yet; and will recommend that you choose some overall targets in your quest to learn coding, and work constructively towards them. These tend to have an academic, or (pure) mathematical, background.
I'm a top down type, so that will color my advice accordingly. If you're a bottom up, you'll probably want to pay attention to bottom up advice. But hopefully what else I have to say will be somewhat useful.
2) Choose your field. There are lots of different kinds of programming; I'll categorize the bulk of most programmers into three types (controversial):
A) "near the metal", a.k.a. hardware programming. These are the people who program non-smart phones and device drivers. They dovetail with mechanical and electrical/computer engineering. They think in terms of voltages and 1's and 0's and clocks and caches and "fan out." These types tend to code in C or assembly, languages which give you a huge amount of control over individual bits and operations, but require you to do everything yourself.
B) "systems programmers" - these guys make desktop software, and operating systems. I'll also include smart phone developers here. You see people programming in C++ and C# (esp. Windows), Objective-C and Cocoa (almost exclusively Mac and IOS); and Java (Android). Sometimes you're coding stuff people can see, like GUIs - buttons and forms, choose a file, Word Processors, etc. Most of the time you're coding functional logic, the "engine" that nobody sees until something goes wrong and an opaque "Error 123302" pops up. Sorting numbers, moving data in and out of various abstractions (trees, lists, objects, queues, "boxing and unboxing"). You can often think in terms of a single computer, though depending on need and interest you may also work on massively parallel server farms as well.
C) "web programmers" - these guys tend to write the so called "backends" for websites. They may take umbrage at being split off from the systems programmers - the biggest websites, like Google or Amazon, really employ systems programmers to handle most of their operations. But at smaller websites things have a radically different feel. These guys are very often on a linux or unix terminal, and code in languages like Perl, PHP, Python, Ruby, Asp, Cold Fusion: languages which make it very quick to write something that works, but without giving you a lot of control over specifics. They spend a lot of time moving data between computers; user's computer to the front end server; front end server to the back end server; back end server to the database; reverse all that; call over to twitter or facebook's servers to get a picture or log someone in/out; etc. They should have at least some rudimentary control of SQL for talking to databases; and may be expected to be able to administrate their own servers (security, users/passwords, install new motherboards, etc.). Web programmers will also be expected to be conversant in the web display methods and means: html, css, and javascript; flash (or these days webgl); visual design. They may be able to do one or more of these things competently; if not, they better know how to at least work with designers who are.
3) Now you can (A) pick a language and (B) pick an environment/platform. Coding 3D graphics with the Visual .NET tools on and for a Windows box is going to be a very different experience from sitting in VIM over ssh to your webserver in Japan diagnosing why facebook connect fails for 1/100 of your users. Each configuration has its own little community too, almost like a national identity. If you're coding Java or python, it may make sense to actually read through the language specification early in your training. If you're dealing with, say, PERL or C++, I would recommend the complete opposite. If you're a Windows or a Mac fanboy, and buy into their developer programs, you can pay for your membership and get a lot of cool tools and friends and probably a forum where you can ask questions.
For certain languages, there are excellent book recommendations. In C++, perhaps not in the beginning but certainly before you're employed, you'll be expected to have read through Meyers' Effective C++. In Java I recommend Bloch's Effective Java. O'Reilly and Wrox have passably good introduction and intermediate texts for almost every language. For some tech, the best reference is online. Stack Overflow will be a godsend to you no matter what language and platform you're on.
Your Editor is going to be the single most important tool you use as a programmer. The tools you used to write papers in college are not going to work - you need what's called a 'plain text editor.' You can get surprisingly far with a simple editor like windows Notepad or linux nano (dirty secret; I got all the way through college and into my first job on nano), but I would highly encourage learning a professional editor earlier. A good editor practically writes your code for you; gives you undo-branches, not just linear ctrl-z; let's you search and replace text using regular expressions; and will automatically jump to the right page and paragraph in your code or anybody else's to show you relevant syntax and usage notes. The language and platform you choose may choose your editor for you; for instance Visual .NET and Apple XCode have their own editor environments which you'll be encouraged to use for those targets. Other times you may have some say; for instance in Android development you're encouraged to use Eclipse but you can just as easily use IntelliJ, vim or emacs. One way or the other, spend some time learning the tricks your Editor affords you, because it will be a massive time saver in the end.
Once you have a language, editor, platform, and hopefully a good book or website, pick a few beginner projects - think very very simple, no, simpler than that. If you're doing it right you will either break down in tears or scream very red faced at least once. That's normal. When you're working on a big physical engine, you know what bolt's stuck and won't move and you're still going to cuss and shout at it. In programming you don't even have the luxury of knowing what's not working most of the time. The whole profession rests on letting go of frustration without letting go of the problem, being thorough, and constantly warping your perspective to see what you couldn't before. That's not easy in the beginning, you're likely to be alone a lot, and when you do grudgingly go ask for help you're likely to run across a curmudgeon sniveling you off with "rtfm." So plan to get overwhelmed and let it go and promise yourself you'll come back to it.
4) Learn at least a little theory. Good Computer Science applies no matter how close or far from the metal you are as a programmer. This is the study of algorithms, running time and running space analysis, theories of programming languages and programming tools, and the handy practice of giving googleable names to things that would otherwise remain obscure (for those that know, compare googling "string concatenation" vs. "ruby + string", "double pointer" vs "C++ **", or try to describe a function closure without using that phrase.)
CLRS (Introduction to Algorithms) is hands down the best reference for theory. It will (or at least, should) be intimidating to a beginner, but this is the text that all the programmers I know review before they start interviewing for a new job.
5) Consider sidestepping everything I've said to begin with and doing something fun. If you're the type of person who learns a foreign language by picking up kids books, that approach may work well for you here too. We had a lot of luck at Harvard starting students off with Scratch (Scratch | Home | imagine, program, share). This will teach you the basics of variables, logic and logic control structures, loops, and common types of mistakes and bugs, all in a way that even a grade schooler could understand. The best part is that everything is visual - at any point you can see exactly what is happening and why. In many other languages you'll have to get really advanced just to get a colored rectangle to pop up on the screen, let alone see what's going on or understand why.
6) Learn the grunt work too. If you're going to make a career out of programming, you're going to need to know about the tools that all programmers use, but which isn't the glamorous part of the job. You'll need to know about version control, and the dreaded merge - metaphorically, how to rescue dying passengers when two programmers crash their trains into each other. You'll need to know what unit tests are and how to write them. To get hired you'll almost certainly be put in front of a whiteboard with a dry erase marker and asked to write legible code for your interviewer; and you'll also probably be expected to use some standard notation for expressing theoretical concepts (lots of circles and arrows, search 'graph theory'; and for arrays and lists you'll be drawing what looks like tape worms). You'll want to learn a diff'ing tool to see changes in a large text base. You'll want to learn a good debugger for your language/platform (some IDE's have this built in). You'll want to learn how to run a profiler to find things you can speed up or slim down in your code. You'll likely want to be able to read and convert grade school "decimal numbers" into binary, hex, and maybe octal; and have a good hexeditor at hand.
7) If you don't want to pay for a comp sci degree, there are good free courses appearing online that can give you the equivalent background, if you're dedicated enough to "go to class" when it's not required. Harvard's intro to CS is now free to the world via (About CS50x). Stanford's: Stanford School of Engineering. MIT's: Introduction to Computer Science and Programming.
There is no end to introductory books and websites on programming, and it is impossible to recommend the best ones for you without knowing you. My best meta recommendation is to understand who the author is, and what his or her background is, and ask if that coupled with their pedagogical style and narrative voice is going to take you where you want to go. No two programmers will agree what all programmers should know, or what order they should approach the material in.
No comments:
Post a Comment