When I was in high school I was always fascinated by the stories I'd hear about hackers, I was just a lowly gamer back then. I always told myself something along the lines of "these people have been doing this since they were kids, it's too late for me, I could never be good at that stuff."
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.
The benefit of technology is that if you have the energy to learn, history doesn't matter much. All this shit is obsolete in 10 years. Experience gets you knowledge of patterns and methods, but the content changes so often that you can catch up relatively quickly (at least in the context of a career).
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.
I learned how to program when I was 30. I actually found it really natural and easy.
Now (one year later) I work fulltime as the programmer for a small games company.
So age is certainly no barrier.
Me too! Picked it up at 30 and spent about 8 years doing professional software development. Then I went back to school, got a degree, started an entirely new career and have kept moonlighting in software ever since. It's so gratifying picking up new things as you get older, and having options in employment is really valuable.
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.
I'm in the process of teaching one of my friends how to program. He's starting off with almost no knowledge, but he's a smart guy, so hopefully it won't be too painful.
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.
> The #1 thing I told him to do is start by programming small, useless programs
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.
That is the point I'm making: start small, make useless programs and see results quickly. If you start from scratch, trying to tackle something big will only frustrate you because there's too many things you need to learn before you can get a complex program up and running.
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.
Communities can be effective in helping folks learn how to program. You don't have to go at it alone. If you're interested in learning programming with Python, for example, look into the Tutor mailing list. https://mail.python.org/mailman/listinfo/tutor
I think I can empathize with the author to an extent — I switched into computer science after freshman year, and encountered many students that had been programming since a young age, or at least since high school.
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.
For me OO was a roadblock for years thanks to really bad early chapters in introductory Java and C++ books that made it sound magical and used awful "sally tells tommy that she wants to buy some flowers"-type examples. From those I figured it was something really complicated (nope) and advanced (unh-uh) so I didn't seek help when I needed it (if I can't learn it from the intro book I must not be able to, right? Hahaha).
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.
I remember when I was learning to program in C I once put a semi-colon on the end of a #define. Statements end in semi-colons, seemed like a fine thing to do and didn't stand out when I was looking for the error. The compiler errors were of no help. It took days to find.
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.
For me, the language wasn't the difficult part (like how the author mentions semicolons, etc.) I was able to pick that up from reading books. I remember having a Python book that walked through some simple programs which I ran on my computer. After, I was able to write loops and do math with scripts, but I had no idea how that translated into actual software used by companies.
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.
honestly, I felt this way in elementary school, all the way back to 3rd grade. It seems stupid, there were probably only a couple other kids around who knew anything about programming. One knew C++ and I thought 'damn, I only know Visual Basic'. I remember programming for independent research projects and thinking 'Of course I'll get an easy grade because the teacher doesn't know how to program and can't see how simple my project is, I'll hand them a pile of code and a working program and I'll get an A'. I was making RPGs in 7th grade but felt it was insignificant until I learned how to build a real game with real 3d graphics, etc. The feeling continued until maybe 11th or 12th grade when I started learning OO programming and really felt confident when I started introductory classes in college.
I think we'd be discouraged less if we didn't habitually overestimate the abilities of our peers. With hindsight I'm sure we can agree that the idea of a 3rd grader really knowing C++ is ridiculous -- heck, adults who use it every day are usually missing huge swaths of knowledge about various parts of it -- but at the time I'm sure that idea could have been discouraging.
The beauty of this profession/hobby/lifestyle is that we are always learning. If I don't feel a moment of "wtf?" every so often, I know something is wrong. Programming can be very humbling and I wouldn't have it any other way.
No discussion about the authors history as a bio major? Lets just limit the game to analogies that might be helpful for a bio major programmer.
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.
A (smart) friend recently bought me Raspberry Pi as a gift. As a non-technical person, I thought it was kind of a strange present at first. I figured I'd play around with it and learn some basic code before inevitably getting bored and tossing it aside.
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.
19 is not too old. As long as you're interested and still in a good learning context (curious, working memory, emotionally ok, no burn out etc) you can and will learn.
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.
I think it's worth noting that 'different strokes for different folks' applies to learning programming as much as for any other skill. Some are fine with following books and tutorials or taking a class. Others may benefit from diving into a real world project. Competition might motivate you but it might discourage you too - as seems to have happened in this person's experience.
The semi-colon thing to me really drives home the point that when I'm faced with a problem, I just feel so very stupid, so very incompetent, and then when I have a breakthrough (usually by letting my subconscious work on the problem for a while), I completely forget that I ever had a problem at all, and completely forget all of the misery I suffered through while it was a problem.
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!
Something I find interesting about the large number of semicolon anecdotes in the comments is, as usual, LISPs got it right a long time ago. Unbalanced parens look weird even to non-programmers, and not wrapping up something you know is a "packaged unit of thought" also looks intuitively wrong even to non programmers. But should this line end with a semicolon; or not; hard to say
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)
Well. There is a magic contingent of how much humans can know at a time. And the amount of time to learn nearly as much as an expert know is five years of hard learning (or better: good teaching). It's just a guess. I think, experts/programmer/whatever will unlearn sufficiently fast, that it doesn't matter much if he is an expert for 10 or 30 years.
Short and to the point. Good stuff. Hey guys, in your opinion, what language should I learn first? I am new to this and I will be going to codecademy and other sites. What is the most useful language for web apps and such. For example, what if I wanted to build useful things like my own product hunt.
My son has been working with Code Academy recently. I've only briefly looked at it so hopefully someone else will correct me if I'm wrong.
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.
If your objective is to build web apps, you won't get anywhere without knowing at least some Javascript. If you want to go server-side, I'd suggest Go.
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.
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.
When I was looking at the Ruby/RoR path, I started with Rails, took a step back to learn Ruby, then went back to Rails. At that point I decided to play with Sinatra a bit because I was getting overwhelmed with the Rails learning curve.
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.
So would you recommend Ruby over Python? That's the feel I am getting from your post. If so, why (besides the obvious resources you mentioned that are available for a noob like me)? Thanks so much by the way! Really excited.
I'm not knowledgeable enough to be able to recommend one language over another for specific reasons. That said, from what I've gathered on reading more informed opinions on the matter, it is largely just that--opinion.
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).
Perhaps, but then we delve down the rabbit hole, and at some point you might as well make your own sql queries, right?
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.
thank you so much for your advice. I am going to start today so I really needed this. Looks like people agree phython and ruby are great places to start. I'm going to go with one of these.
Whatever you pick, pick just one and learn it well for a while before learning another. Don't fall into the trap of continuously changing technologies.
Probably JavaScript at first if you're web app focused. Then either expand to NodeJS or learn another language for the back end like Ruby, Python, Java (which is not JavaScript), C#, PHP etc. One you learn a language or two, picking up more becomes exponentially easier as the majority of the concepts transfer.
To become decent, it's going to take 3-5 years, depending on how much effort you put in. Do whatever it takes to get a job in the field. Grovel if you must, it's only temporary.
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.