My personal struggles with learning how to program
vutran.me
vutran.me
A little over a decade later after finishing my time in the military I made a conscious decision to study and get into information security. I guess I was more confident by then. I've only been at it a few years, learning fundamentals, coding, actually not a ton of security stuff yet since that in itself is an advanced topic and I thought if I was going to aim for infosec I wanted get there the right way.
Now I'm working a contract job for a local guy, making him tools to automate his business and have been pestering a security company about a job as well (for the past few years in fact). My most recent correspondence with the technical lead at the security company yielded me a "maybe later this year".
I know I'm far behind many of my peers in knowledge but I've just taken that simply as more reason to work harder at it than them. I'm starting to see results I honestly never thought I would, and I am starting to get the impression that I can be good at this.
I was lucky enough to be born in a country where the biggest obstacle to my success is myself. Keep that in mind when you're doubting yourself.
Security, unlike many things, can be freelanced in your spare time: many companies offer bounties. So just go in and figure out how things work, and try to break them. If you find something, submit a bug report, and who knows, you may pick up a few grand on a security bounty. Land a few of those, and getting an interview for a full time job should be relatively easy.
Though in between I spent a few years working in IT on helpdesks and stuff. I didnt really like architecture + the work was drying up. I put my ease of getting into programming down to.. 1. I am just a natural. I'm very logical and think in terms of structure and organisation by nature. 2. I grew up with a C64 and then a series of pc's, from a 286 running DOS onwards, in my home.
Though I never did any programming on them, I just played games on them. Though back then getting games working was all command-line and editing autoexec.bat and so on. When I was about to start learning programming recently I was apprehensive that I would find it hard because I had never done it when I was young.
I also think years of architecture helped somehow. Architectural design is often about organising lots of competing elements into a structure or framework that makes sense. The project management aspect of it is useful for most jobs, also whats described as AGILE by software developers (doing a design, evaluating / critiquing it, then designing again etc.) has been the standard in architecture since time immemorial.
The #1 thing I told him to do is start by programming small, useless programs and work up to more and more substantial programs. The more you program, the more you learn, and you build on that wealth of knowledge. And more importantly, you learn how to avoid the mistakes that you made from your previous programs. I'm in the process of learning Scala on my own, and this is the tract that I'm taking as well, and I've been programming for years now.
And in the process, the key thing you learn is perseverance. If you don't have perseverance, there is no way you can be a programmer, because that is the life of a programmer. You hit roadblock after roadblock, and you need to figure out how to get around those problems by yourself. You have to try 100 times to fix a problem, so that the next time it might only take 97 times, etc, etc.
I couldn't disagree more. Seeing useful results on day 1 is a major motivator. Doing purely theoretical tasks for the sake of understanding is mind-numbingly boring. You only need to get into the details after you see the way to just get it working. I think this is why weakly typed, high-level scripting languages are so good at starting out with. Learning pointer arithmetic in C as a first exercise never made anyone want to program more.
No one needs a program that outputs the listing of a directory, but if you can get that working, then that's a huge accomplishment, especially for someone that hasn't taken formal programming classes.
I think the most important thing for me was finding a mentor. I was fortunate enough to get an internship at a startup with little programming experience (possibly out of a sheer determination to learn).
The engineer I paired with was able to answer all of those early "roadblock" questions — the ones that you can't really Google since they seem so obvious to someone with experience that no one writes about them (this was before Codeacademy, etc.).
Anyway, finding a mentor can be tough, but I've generally found that friends who program are pretty eager to talk about it or willing to help out. I've been programming for a while and I'm still learning stuff all the time.
It took a long time to learn to read errors messages and interpret them for what the actual problem is. Forgetting the semi colon on the end of a class in C++ is another one that will making baffling errors, though I think most modern compilers now say "did you forget a semi colon?"
It takes time to learn all these common simple errors that are impossible to look up in a reference book. (Though now you can usually google them)
I remember getting so frustrated that I couldn't figure out how to cast a function pointer to a C API correctly in C++ correctly that I gave up and switched the entire project to C.
These are the only onse that really stick out in my mind, but there were many more.
That's where the mentorship helped. Before, I only had a vague idea of how a non-static website worked. After, I had an okay understanding of the entire system, from the databases to the front-end, and how it was built. I learned about stuff like MVC, and got to the point where I could build a website on my own.
Possibly the most helpful thing was looking at segments of code, trying to work out what they were for, and then having people to talk to if I didn't understand.
It probably didn't help that Perl was my first language. With a solid grounding in C I might have made the "this is just a struct with functions and some sugar on top? Why the hell didn't they say so!?" leap much sooner—as it is, I eventually made that leap from associative arrays instead of the closer analog of structs—again, I learned on Perl.
Someone to say, "look, you pretty much already know this, it's..." would have saved me tons of time and accelerated my learning substantially.
I hope for the sake of people learning now that all these online tutorials and interactive exercises have made that sort of thing largely a thing of the past.
[EDIT] grammar
Easy analogies: DNA GATC vs binary encoding. The amino acid coding for proteins vs machine/assembly op codes, even down to non-byte aligned access issues and invalid opcode interrupts. The concept of an algo like a biochemical cycle, someone who sits thru the Krebs cycle has the concept of an algo or at least a flowchart down. Depending on how much neuro there will be at least a conceptual discussion of many simple voltage operated nerve cells in a peculiar arrangement much like a pile of little cmos transistors in a peculiar arrangement, both are made out of simple parts in a complex system. The blood / hormone homeostasis system kinda like calling a function and getting a response. The cell wall as an object oriented paradigm, there's public and private data in a cell and there's getters and setters and methods. I guess the concept of cell division is very good analogy to threading whereas process spawning is more like giving birth? There are a couple blood and organ control loop systems that are vaguely "while loop" and "if then" like. Tree structures and FIFOs and maybe LIFOs are intuitively obvious to a bio major.
I wonder, given the nature of organic chemistry, if something like teaching assembly language could ever "swap into" the medical doctor weed out process. Its more similar than you'd think, building things out of smaller things, certain peculiar interactions, path finding from here to there, a mix of simple analysis and intuition, plenty of memorization. Assembly language would make a perfectly good medical doctor weed out course replacement for o-chem.
Analogies that probably exist but I'm missing the details: Something like pointers "must" exist in genetics, right, otherwise how would the cells know where to find a protein to synthesize along a strand? Cells don't really "run" every protein off the entire DNA strand, do they, surely they have some kind of filesystem however crude? Something like variable types probably doesn't have a good biological analogy. I suspect the existence of more sort algos than the bogo sort or at most a radix are probably confusing to bio majors. Stranger data structures may or may not exist in bio, are there plant tree branches that spawn like our weirdest tree structures? Some database concepts "probably" fit into some enzyme scheme I don't know about WRT transactions and durability and atomicity, but what exactly I donno.
That didn't happen. I started a couple Python tutorials on coursera and code academy and haven't looked back since. It's been a little taxing at times (pretty sure I experienced a similar semi-colon blunder) , but learning to program is really fun if approached as a hobby and not the end-all be-all of being successful in tech. I think the key is not to be too hard on yourself and get help whenever possible.
About the frustration, programming involves many dimensions: syntax, paradigm, linguistic idioms. Some people can't think in a language, while they fly in another. Write your ideas down, try to refine them in logic/math, don't lose them, the programming language you use won't matter soon when you have a clear mechanic of your solution.
19 is young.
I've solved so, so many tough bugs while writing an email for help. I had to explain the problem with enough depth, and try all the things I know they'd say "have you tried X", before I sent it--and the solution appeared. That's RDD, essentially, with the fallback of getting help if you don't find your own answer!
Many articles talk about that. It's when you defocus from a task (pause, shower, walk, talk) that your brain starts to get new insights.
Also, REPL driven development vs 100 lines of text you don't completely understand and pray it compiles and good luck understanding the errors in a 100 line program, although a one line REPL usually isn't hard to figure out which line had the error (LOL).
You need not wear out your paren keys forever, but it might not be all that awful of an idea to at least start with a LISP like Scheme or Clojure or whatever, just to get the basics down.
This is, uh, not a new idea or an original idea of my own. Could do worse than pick up "Little Schemer" book. Someone should write the "Little Clojurist" book... assuming someone hasn't already. (edited to add, embarrassing, I searched the publisher of the Little... series for the obvious title and found nothing, turns out there's multiple crowd sourced projects along this general line, none official or commercial, or probably, legal)
With ruby, use rails. With python, use django. With PHP, be wary! (but it's incredibly widespread, so it should still be included here).
Learn javascript as well, as you can't avoid it entirely.
Use codecademy for the bare essentials, explanation, and then jump to framework-specific tutorials. Build your knowledge from there by building new sites or new features on your existing site.
If you want me to narrow it down and choose for you, here's basically your whole stack: Python, Django, Heroku deployment, Postgresql, jQuery, (HTML/CSS obv).
A year or two of full-time, focused work at this and you're more qualified than plenty of already-employed developers.
I'd suggest Sinatra instead, and find some smaller ORM to go with it. There's _way_ too much magic going on in Rails to make for a good place to start.
I recommend rails mostly because of the incredible number of helpful resources. Also because you can use it as a beginner, ignore the magic while you don't understand it, and later try to understand it.
I committed rails code my first day on a new job with no prior ruby/rails experience, though I had used Django before. Pretty green there, as well.
But you had _some_ programming experience, is what I'm getting at.
My problem with rails for a complete beginner is that you end up with too many rails-y things to learn, and you can't focus on the basics.
Sinatra was cool to get something out quickly for sure. I'm definitely glad I ventured out of the Rails sandbox a bit. That said, the quantity and quality of Rails resources on the web far exceeds that of Sinatra. For a beginner that is likely to encounter a ton of errors and bugs, there are simply more answers online for Rails than Sinatra. That can make the difference between giving up and keeping the excitement going which is crucial for a beginner.
If you find, like I did, that certain concepts are interesting, you will start to naturally peel back the layers of Rails magic on your own to learn what is going on under the hood.
Beyond that, Mike Hartl's Rails Tutorial is something I'd recommend to anyone learning to program as it seems to give solid coverage on ideas that are framework agnostic. Things like version control/Git/Github, writing unit tests and TDD, DRY, REST architecture, proper handling of authentication, etc.
There are so many different rabbit holes to go down, but I'm glad I did, because while I'm not deep on any of these areas yet, it has definitely given me a more complete picture of my projects, how to approach them, things to watch out for, etc.
Many people prefer one language over another. Both core languages, Ruby and Python, have excellent documentation and resources online as well as strong communities around them.
My comment was speaking more specifically to the case of Sinatra vs. RoR. I feel like RoR simply has many more high-quality resources available on it than Sinatra does. This is likely due to how much more development occurs in RoR vs. Sinatra (pure speculation there).
That said: If you want to learn programming, just do it. Doesn't really matter what you choose now, at some point you'll think "Language X would come in handy now, I wish I'd learnt that instead". Resist the temptation to switch to something else, and stick with your choice for long enough that you can look at non-trivial projects and can sketch the implementation in your head and identity trouble spots. If you keep jumping between languages, you'll waste a ton of time learning syntax that could've been spent learning more about programming as a practice. Anyway, as you get more experienced, picking up new languages becomes easy (provided they're moderately similar to _something_ you already know) so there's not much pressure to do it right away.
A lot of what they have available is web based - e.g. learning javascript, html, php, css, etc.
IMHO you would be better off starting with python (or maybe ruby), which is also available at Code Academy. Learn to make simple programs on the command line before you jump into higher level languages and combining them with mark up. And, really, python is pretty high level as well so the learning curve shouldn't be too steep.
I started with Visual Basic many years ago and in hindsight I didn't really "get" programming by learning VB. I did some great stuff with it but until I learned some C and Perl I really didn't understand much about what goes on at the OS level. Once I learned to do things "the hard way" doing things with VB, javascript and combining Perl and HTML made a lot more sense to me and made it easier to step back and debug when things went wrong.