Why Learning to Code Is So Damn Hard

If anything, we need to promote education among adults, give them the choice to possibly check out any vocation that they would want to try. Liberate them from the notion that they are "stuck" doing what they chose to do earlier in their life. I'm not saying that its easy; you have to start small and take baby steps. And its not something that can be done in a day or a week or a month. But if modern society has provided us one great benefit, it is of making knowledge accessible very inexpensively.

Other pursuits that are so interesting that the social factor isn't required include physics, mathematics, etc... These people aren't necessarily programmers.

I agree, and I don't think it's a good thing. As Crockford once said, we chose software because there's something wrong with us.

In fact, often better programmers than "naturals" because along the way they had learned a lot of discipline that isn't necessary when programming is fun -- but as every "born programmer" turned professional finds out, programming isn't always fun.

This describes me quite well. However, I'm not sure that this addiction is required in order to do software development at all.

There is evidence that with certain concepts in software development--pointers and recursion are two that come to mind--people either grok them or they don't, and if they don't, no amount of education or training seems to help. But I'm not sure the ability to grok these concepts is always correlated with the addiction.

I did find a job and turned out to be an average programmer and I worked mostly for the heck of it.

The turning point in my life came when I ventured into management. I realized how fucked up that industry was, as compared to even the most inane programming task I had ever done. So that's when my love for programming started to grow and it hasn't stopped ever since. More and more I see other industries I realize how shoddily disorganized they are. I mean - consider the process of getting an approval. It takes days where as it's just a push of a button on an app.

So it's not true that as an adult - you can't realize the magic of programming. You just need the right context and some affordabiity for the right tools.

I always avoided maths at school, despite being reasonably good at it, because I didn't find it interesting. Studied biology and ended up in software engineering.

Now after many years in the "real world" I can see the practical application for many forms of mathematics (particularly statistics), and kind of wish I had studied it more. If I had the chance to go back to university and study it, I am sure I would find it a lot more interesting, as now I can see where all the techniques could be put to use, rather than seeing some abstract set of symbols on a blackboard.

> To me educational efforts for adults are misplaced.

My theory is that the difference is just that (some) young people have more spare time. If you have lots of time, then the inherent fun of learning stuff makes it fun to wander around learning stuff. But if you don't have much time, then you prioritize the things that relate to your goals, and then unexpected things in between you and the goal are stressful obstacles.

If you have tons of time, then your default state (alternative activity) is boredom, and learning anything interesting saves you from that, so you're glad you did it. But if you don't have much time, then learning something only to find that it wasn't as useful as you thought it would be (which often happens when you don't know what you don't know, but are trying to learn) is disappointing, because you know you sacrificed other important things (in retrospect, things that were more important) to spend time learning that.

Seriously, that was a major sticking point for me having programmed for a long time: going from "if you have not declared that identifier, game over" to "magic happens".

Cathy, a new frontend student, experienced similar struggles when starting her first real project - a simple HTML/CSS resume. She spent countless hours fixing minor typos and almost quit. It wasn't until she was reassured that this was _normal_ and "real" programming was much different from codecademy did she feel like she was truly learning. She wrote about her first month (with similar highs and lows as OP's visual) in this post: http://blog.thinkful.com/post/98829096308/my-first-month-cod....

side note: Erik (OP) is an incredible guy, we had the pleasure to share our experiences in Edtech and it's obvious that he truly cares about student outcomes.

This is where the beauty/simplicity of some programming languages, namely, intepreted languages (e.g., Python), comes in: if a bad line of code never gets executed, then the program itself will run fine. In other words, if the line is never called in the program, then you'll not know that the functionality that that line presented was bad. In this case, the analogy breaks down a bit - and also shows why certain languages are easier to learn than others (e.g., Python vs. C++).

There are a lot of jumbled concepts here, most of which don't matter anyway, because what you are talking about is the phenomenon of graceful degradation. In the physical world, both natural and man-made, almost nothing at the macro scale is ever perfect, so the best designs tend to be those that remain good enough under the widest range of circumstances vs. a more common software goal of being perfect under perfectly controlled circumstances.

As software gradually moves out from the wall garden of a single mainframe to fill the world with interacting systems spanning diverse machines, sensors, communications channels, data types, etc., design for graceful degradation becomes more and more of a focus for professional software architects.

Coding in the gracefully degrading way is much harder than coding in the "if even one of your ten lines is wrong, you crash" tradition. The fact that even the latter is so hard for us humans means we will need more and more help from machines that learn what to do without being explicitly told by us.

UNIQUE ETHICAL PROBLEMS IN INFORMATION TECHNOLOGY

By Walter Maner

http://faculty.usfsp.edu/gkearns/articles_fraud/computer_eth...

I was lucky enough to fiddle with computers as a kid, so I kind of knew what I wanted to do, so I had years and years of "play time" in which I gently and accidentally introduced myself into programming, databases, operating systems, hardware, the web, etc. Often, things that I never thought would be useful turned out to be down the road. I also learned to be more fearless when experimenting and understanding a system - versus it takes some people years to get out of the "afraid to break things" mindset into the mindset of experimentation, trying things out, prototyping, poking things to understand them.

I think these are things that the sausage factory modality of education can't really provide, and working in the field will definitely give you this kind of thing too.

But the issue I see often is that the self taught or "graduated" (whatever that means) from support folks aren't taken as seriously as a person with a BsC in CS from a "legitimate" engineering school.

I /did/ get a formal degree, and it taught me tons (won't comment on the whole is it necessary thing) but I think it would have been way harder for me to get a programming job otherwise even though I probably had adequate skills for an entry level job in many places.

I don't think in many places today that someone would consider training a support person to do engineering, for various good and bad reasons, and we need to think hard about providing more long term learning-through-doing and on the job apprenticeships that other craftspeople do.

I was decent enough to implement basic algorithms and data-structures since high-school. I couldn't build apps of course.

Then in the first year of college I got hired for a small and shitty company doing web development, on a very low salary. My first project was to clone a popular dating website (Match.com). For me the project was overwhelming, as I knew nothing about what it meant to do real things. But I felt the pressure of delivering and I really needed the job, so my path from a near zero to somebody hirable took one month, because that was the deadline for showing something working.

So basically for me the driving force was hunger - and I'm talking about both the attraction towards CS and the need for an income.

Of course, from there to somebody that can call himself a decent software developer, well, that took another 12 years. And the kind of projects you're working on matters a lot. At some point I worked for a startup that had crazy technical challenges, crazy constraints, crazy deadlines, crazy everything. For 3 years I worked on that and learned much more than I learned in the other 9 years.

The fun part was that they turned off the timesharing service at night - but they didn't want to power down the Sigma 5 for fear that it might not start back up in the morning. There were occasional overnight batch jobs to run, but mostly I didn't have much to do.

I already knew BASIC, having punched programs on paper tape in high school to run on Transdata's service (which was how we got acquainted). I found a copy of the Algol-60 report at the office and thought it looked interesting, so I read it, tried out a bunch of programs, and learned Algol.

Then I found an assembly language and opcode reference for the Sigma 5, which was fascinating. There were plenty of blank cards to punch, so I learned machine language too.

I could have just sat back and done the night operator job and not much else, but man, there were such interesting things to fill in the rest of that time. And it's stayed interesting ever since.

Of course that was an unusual situation, and I suppose not one you could repeat now. After all, how often do you get a chance to have a whole computer all to yourself?

When you get into real-world software development, it's much easier to work with an existing codebase than to start from scratch on a new one. If the application is in production, then you know that the existing code works, so you've got a baseline. You can study it to figure out how it works, and you can compare that to requested changes in the way it should work, and then you just need to figure out how to change the code to make the behavior change. That leads you to asking the right questions, focusing on the right code. It's like the hand-holding phase, except it's real code instead of play code. Figuring out how the code works also teaches you a bunch of stuff on the side, like how to do debugging in this new codebase, how to set up and work within your development environment, the practices and patterns of your team, etc.

From that perspective, I absolutely understand the urgency here, and appreciate how this article talks about how the moment when the tutorials break off is when the real learning begins.

I compare it to wha we do today: My code uses libraries, that use libraries, that use libraries. Languages are huge in comparison. Sure, it's easier to do what we used to do 20 years ago, but nobody expects from us what we did then: Even someone that is just learning wants to do more. This is what builds the despair phase of the article.

It's a well known issue that both affects how we train new people and how we even manage large pieces of software today, so it's well talked about. For instance, the first talk of JSRemoteConf last night was all about this issue. Hopefully they make the recordings openly available soon.

Totally unrelated to that, Algolia's HN search really is magnificent - supremely fast, accurate, and even quite attractive. Impressive.

One thing that I think separates senior engineers from juniors is a level of confidence and willingness to tackle the unknown and learn new things, tempered by pragmatism that they don't all need to be tackled and learned right away.

I just don't know how to actually _do things_ with code. So, in essence, I think I know the language, and in a sense I do insofar as I know how to write an if else statement, a while statement, declare a variable, etc., but I _don't_ actually know the language, because I can't do anything with what little I do know.

Do you have any advice?

I learned to program in a completely utilitarian way. I had a problem that I needed to solve, I knew others had used programming to solve similar problems, so I learned only what I needed to know to solve the problem at hand. After using it this one time I began to notice all sorts of other problems around me that could be solved using programming. I developed my passion for coding because I understood it was a tool that could make my life easier.

Or a similar modification of your music analogy: "Some people want to be good at guitar, others like making music".

Just keep practicing. Varied things. Challenging things.

You'll get there!

Most people who write code for a living never bother to memorize the syntax for all the tools they use. Figuring out the logic is the hard part of coding, having to look up the syntax for every other line shouldn't have much impact on your productivity.

If you want to memorize the syntax then there are a bunch of guides to doing that (e.g. Derek Sivers wrote something on this), but that's probably not actually your limiting factor.

Also, learning in a vacuum can make it hard to really benchmark how knowledgable or 'good' you are. So getting some feedback in groups may help out.

  I always try and obsessively look for the "best" or "proper" way to do something.

There are nigh-infinite blog posts about ways youcan do X better (unit test, standards, unicode compliance, date handling, names, design, CSS, layout, etc) -- don't worry about those yet.

=== Coding on your own ===

Consider writing code to solve programming puzzles, like Project Euler -- it can often start small, and then improve as you learn more.

Consider building a "simple" toy project in a web framework -- Django, Flask, etc. (I mention those as they are some Python frameworks.) There are often tutorials that run you through building something toy-scale. (Your own twitter, a TODO app, etc). Doing this will let you quickly build something with a simple UI, and simple guts, and then you can look into ways to improve it.

For example, I'd like to make a flash card game for my kids. (Real project, tired dad. ;)) I can start with some code that randomly generates problems, and shows them to a UI in a pretty way. (Large font, perhaps.) Later on I can improve it with things like letting people enter the answer, tracking how long it takes to answer, tracking scores over time (so that I can focus on the ones they have problems with), leaderboards, and custom decks. ALL of those are way out of scope of the initial project though.

=== Coding with others ===

If you'd like more of a challenge, or in some ways less, try being a contributor to a larger project, rather than trying to write something totally from scratch. This is really important -- most of us are not writing Large Software solo. I might write a handy tool solo, but most of my day-to-day work (and the environment in which I do most of my learning) is maintaining a larger codebase.

Existing projects already have a build framework, a code review protocol, RPC/API infrastructure, GUI, etc already done for you. They have a test suite that tells you if you broke something. Now, your improvements are things like, "Add an error message when this happens", or "Add support for a new API call...". It's MUCH easier to add something similar to what someone else already wrote (once you understand how it works by reading their code ;)), than it is to have to write all of that infrastructure yourself. There are also OTHER developers who have domain knowledge of the codebase, and that you can ask for help -- this is VERY useful and important for our learning as programmers.

=== Direction ===

I have no idea how to help you there. ;) It's easy to feel inadequate in this profession, as there are always smarter/faster people. Since what we can create is endless, it's hard to PICK something -- that's why I suggest doing a tutorial-based project in a web framework. You can then use that to focus on the Python side, or on the UI side, or as inspiration/guidance for making your own things.

Also, don't worry about looking at Stack Overflow. Definitely do that if you're stuck on something, or you forget whether something is possible ("Can I declare a dict plus it's members in Java the way I can in Python?"). It can at times be hard to tell when the answer you find on SO doesn't match the problem you really have, though, which takes practice.

I'd be happy to talk more via e-mail if you like. I've updated my user profile to include a poorly-obfuscated rendition of my gmail address. :-)

I've been toying with the idea of quitting everything and going all-in for 3-6 months.

Would that be 100% retarded or just about 70% retarded?

I can live with 70%.

Motivation will fail you when you are left with those last 10% of a project that feel like the first 90%, but now with uninteresting tasks like tweaking the hell out of a UI, fixing all those bugs resulting from code optimization in obscure cases, implementing database integrations to assure backwards compatibility with earlier versions or some such shit that is impossibly uninteresting but required to finish the project.

Then in play comes discipline, and that is something you have to learn systematically, and when you don't feel motivated at all to continue through and just wish to quit it all.

But you are correct, you have to get satisfaction from the process. Maybe the motivation is to see the end result. But still, there is that phase where all hope seems to be lost, inspiration and motivation are nowhere to seen and all that remains is just grind and decide to follow through.

But most people won't get that opportunity, or isn't smart enough to go look for it.

* How to run a meeting.

* How to allocate Make time.

* How to collaborate with other people.

* How to understand business needs.

All of these are skills you need in any white collar job. Learning them is a part of any job you might do.

Even the software specific ones like:

* Packaging

* Shipping

* Versioning

* Tooling

Are all going to be job specific. You'll find some of them to totally non portable and some of them will transfer just fine.

The good news is that by now you'll have begun to hit a groove when it comes to knowledge acquisition and learning this stuff will get easier.

The next high is when you start to recognize Process Patterns in the jobs you take on and how to best handle them. Or even which ones to avoid like the plague either by effecting change in the company or changing employers.

I was going to say that this was nothing like my experience of learning to program, but it does quite accurately represent the process of adding new skills these days.

For me, the hardest parts of programming as a beginner - understanding OOP, data structures, etc. - didn't really 'click' until I stopped reading tutorials about them and start writing my own programs. The idea of 'objects' and 'instance variables' was mind boggingly confusing at first, but once I stopped worrying about how to make sense of them, the concepts somehow just fell into place.

I've also been trying to learn French simultaneously. The process was somewhat similar - taking a few Duolingo lessons and thinking that 'hey, I can do this!'. Then I read some actual French prose and everything seemed impossibly difficult. Things didn't 'click' until I started living and breathing French.

It's the same thing with coding.

If you feel like your knowledge is getting flushed away with a new platform, then you've been learning the wrong things.

I loved every bit of it. And still do.

I really try to keep a more emotionally neutral stance on all of my code and my abilities. If I want to indulge in arrogance I philosophize.

In the end, it's the same thing over and over again. Symbols swapping with others symbols denoting some kind of esoterically tangible, but ultimately fleeting, meaning.

It'd be nice to not feel perpetually stuck in the desert of despair though. I used to think being there meant I was learning stuff, because I had intuitively learned from repeat failure that after failure comes success. Turns out you can think about yourself plodding along at a steady pace, with no comparison to anyone else, as long as you stop assuming that there exists a clear, coherent, ordered organization to knowledge.

There exists such a thing in school, or at least the commentary on a topological sorting would have you believe. Technology doesn't always develop and get released in school though. Sometimes it develops in webs that are can not be causally described, because thought and skill do not necessarily travel in measurable directions, nor is their instantiation completely definable/observable.

People apply too many theoretical concepts to describe, dictate, and organize reality without understanding the effect on perception.

Developers are problem solvers, the student doesn't get the material, figure out how to solve the problem.

So probably those who are naturally logical thinkers, even to a level that normally would not be very useful, become useful in the computer space where they can utilize their internal skills of putting things into neat ordered rows of zeros and ones.

This is a great point because it's easy to get stuck in analysis paralysis. There's always a tension between needing to stretch out and build something just beyond your capabilities and then having to backfill some of the fundamental knowledge you missed along the way so next time you can reach further.

At that point, it was up to me to figure out what to do. I started with a single screen that showed some text and added a few more screens that had the same text. Then I added a button that triggered a change of that text. Then a button that displayed an image. And so on until I had a real card game that could even identify whether there were any legal moves available and if the player was stuck.

Every step along the way was not easy and I got derailed a couple times, nearly giving up. The hardest single feature to implement was dragging and dropping a card. It took a lot of cribbed code from a few useful blog posts, but the feeling when I actually got it working was indescribable. It was a Saturday morning and I was running around my house, dragging and dropping cards on my tablet like I was 8 years old and it was the greatest Christmas gift ever. That was the moment when I realized I could actually finish this if I was willing to put in the effort. The rest of that weekend was spent in blissful coding and my commitment to becoming a developer has never wavered since.

Now in my job, which I got an interview for because of the card game, I have witnessed other people with less self-guided (contrasted with CS class projects) experience than I started out with be unable to persist long enough or self-teach hard enough to solve a problem by themselves without asking for help to get over minor bumps. I won't ask for help from a more senior dev unless I have exhausted my abilities to understand the problem space and can enumerate the things I have tried. I refuse to be the person who simply "doesn't know how".

Never ever give up.

This is a carbon copy of my life as a programmer right now.

I've made the decision to just fucking do it about 50 times, but each time I get barely started and get so frustrated with myself for not understanding and not knowing what to look for that I give up. I know that's another point where I just have to sit, searching, until I find the answer, but it seems that from my profound lack of understanding of the basics of the language (JavaScript; despite doing the Codecademy course, and the CodeSchool Node.js and Express.js courses) that I will have to do that for every minute step that I take in the program. It just seems so overwhelming that I become paralyzed in my desire to push on, but feeling that I know I won't make any progress.

Do no stop to think if it's any good, neither stop to plan ahead what it will look like. Not on your first few programs.

1. consume input 2. do work 3. print output

find a small but interesting piece of work to do and code that. repeat several times. there are sites that provide you problems to solve if you don't have any ideas of your own (like project euler).

- be executable - (optional) take input from somewhere (e.g. stdin, or command line arguments) - (optional) write output (e.g., print statements)

Would you be able to write a small script that implements solutions for Project Euler? (Even just a few of them.)

- You don't need any input at first, because the problems are already specified. - You can write a separate program for each problem, or just comment out calls to each exercise's solver - Brute force is OK for many early problems - You probably know enough to write a function that solves an easy one (e.g., Nth fibonacci number)

Once you write such a function, you should be able to find out how to write an executable program in your language, and then you're off to the races: Run it over and over from the command line until you (a) stop getting errors, and (b) get an answer that you can defend and understand. :)

If you break a problem down far enough, eventually you end up with groups of problems, each containing simple conditional statements, a few variables, maybe a loop :-). That's the challenge new programmers face!

Designing a nuclear submarine, however, requires a lot of interconnected disciplines that rely on an understanding of each other.

To a lesser degree, it's similar to setting up your own ESXi cluster at home. You need to know more than just VMware--you need to understand networking, storage, flashing and configuring the host BIOS... AWS is quite a bit easier than managing your own physical environment.

Which may relate to why we see more younger people getting into coding than infrastructure/operations (regardless of the money).

Digging into someone else's code base to understand it well enough to fix bugs and add features without introducing unintended side-effects is, at least for me, quite a challenge. It takes a tremendous amount of persistence, the ability to build a mental blueprint containing substantial amounts of logic, and - most importantly - the ability to swap into the mindset of whoever wrote the app, rather than the way you would have written it.

You know, a lot of us have studied tough things - I was a pure math major and I was a PhD student for a while in a very math-ish engineering department at Berkeley where most of the day was spend on proofs about stochastic systems or convexity. This sort of background isn't unusual here on HN, yet many of us would say that while code itself contains a wide range of challenges and difficulties, the field absolutely has monumental challenges that will push very smart people as far as they can go, maybe farther.

I once (about 15 years ago) got rebuked (gently) by a researcher at Sun Labs once when I dismissed a potential project as "easy." A museum was looking for someone to help build a search engine for their art collection. I said "a db search across some metadata, that's not a huge challenge." The researcher replied, with a mild smirk, "oh, I didn't realize you'd already solved all the issues in image search."

So then I backpedalled a bit and talked about the specs the museum had mentioned, "oh, well, they're just looking for search on some metadata". He replied, "well, maybe that's the only way they understand the problem, but you don't need to accept those limits".

And, as mentioned elsewhere, there's a big difference between writing an application or two and being involved in a larger software engineering effort.

| Learning to code is not hard. At all.

This assertion is empirically untrue in the market for programmers (if nothing else). Why are programmers paid as skilled laborers? How many not hard (at all), highly paid, and quite frankly cushy job exists? In the Bay, hiring is the biggest problem.

| how many teenagers can design a nuclear submarine?

Why is designing a nuclear submarine the point of comparison? Is this some sort of humble brag?

| That is much harder to learn.

No one claimed programming is the hardest job in the universe. It is perfectly possible for harder jobs to exist and for programming to be hard.

Just about every one I meant.

It isn't likely to work. But then I wonder how many teenagers could code a working control system for something like a nuclear submarine.

Seriously. "Just code" is the worst advice that everyone gives. It's trite. You'd be better off saying nothing at all. Do you think you can sit someone down with a C compiler and come back five years later to find they've written the Linux kernel?

Don't say "just code". It's not helpful. It's disparaging. You don't tell a child "just walk". You learn to code, you're not born with it.