Why Learning to Code Is So Damn Hard • Hacker News Board

Re: Why Learning to Code Is So Damn Hard

#201

Post by sonnym » Thu, Feb 05, 2015, 12:35 AM UTC

lelandbatey wrote: post #84

SilasX wrote: post #71

Earlier quoted context omitted.

Unless you're doing Rails, in which case it'll be read as a magic method and guess what you meant :-P 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".

That is absolutely something that irritates me. I've just inherited a large RoR application, and the amount of "magic" and things by convention is driving me crazy. There should be answers to questions like "why is this the way it is?!" On a side note, if anyone has some great resources for RoR, I'd love to have them linked. I suspect my inexperience is the source of my problems, and I'm welcome to any assistance any…

Aside from the things others have mentioned, which are all really good, there are some really good books on the subject.

Jose Valim's Crafting Rails Applications[1] is a wonderful resource, since it deliberately sets out to peel back the layers of magic. A lot of the techniques are ones I probably would not use in practice (storing views in the database and rendering them!), but they serve to elucidate the operation of the entire view stack. Really good stuff.

Two other good books are Rails Antipatterns[2] and Objects on Rails[3]. Neither of them has been updated in a long time, but the general principles will still hold. The former is more practical, the latter more theoretical; precscriptive and fanciful food for thought, respectively. Both solid.

1. https://pragprog.com/book/jvrails2/crafting-rails-4-applicat...

2. http://railsantipatterns.com/

3. http://objectsonrails.com/

Re: Why Learning to Code Is So Damn Hard

#202

Post by 4ydx » Thu, Feb 05, 2015, 12:43 AM UTC

superobserver wrote: post #87

rcthompson wrote: post #43

When I was in college, one CS professor explained the difficulty of coding to me in terms of discreteness vs continuity. In the real world, things are continuous. If you accidentally build your structure with 9 supports instead of 10, then you only lose 10% of the strength of the structure, more or less. The strength varies continuously with the amount of support. But if you're writing a 10-line program and you forge…

> But if you're writing a 10-line program and you forget one of the lines (or even one character), the program isn't 10% wrong, it's 100% wrong. (For example, instead of compiling and running correctly, it doesn't compile at all. Completely different results.) 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 exec…

Unfortunately this is a dark hole of horrible bugs just waiting to happen not to mention the fact that interpreted languages are very liberal with silent type conversion. It is a nightmare to deal with in a large system written by careless programmers.

Re: Why Learning to Code Is So Damn Hard

#203

Post by 4ydx » Thu, Feb 05, 2015, 12:51 AM UTC

geebee wrote: post #198

pflats wrote: post #89

Earlier quoted context omitted.

>Really? How is being a brain surgeon more difficult than being a computer surgeon ? Understanding how a CPU completely works... Well, we know how everything about how a CPU works. We don't know everything about how a brain works.

Are there really no longer any open and relevant research issues around this topic? Is humanity's understanding of CPUs, how they work, how they should work, is it all wrapped up and complete? Not really my field, so I truly don't know. But I'd be a little suspicious of someone who claims there's nothing new to learn here.

I don't think he means innovation which seems to be what you are implying. If you take a current working computer system, there are no "mysteries" in the existing hardware where the hardware designer just threw up their hands and decided to hope it would work. Sure when you throw in environmental factors there is certainly unpredictability in terms of hardware failure, but actually understanding what the system is doing? We know what it does. With something like the human body, it doesn't seem that we can be nearly as confident.

Re: Why Learning to Code Is So Damn Hard

#204

Post by chipsy » Thu, Feb 05, 2015, 1:00 AM UTC

jussij wrote: post #188

hibikir wrote: post #171

Earlier quoted context omitted.

That's because you, like all of us that learned in the 80s, were very, very lucky. We started in a world where writing good, production code and learning the very simple basics of programming were the same thing. I started with a ZX Spectrum. You could use simple machine code, or simple basic. Libraries? What are those? The one barrier to get good was when you ran out of memory, and had to switch to machine code and…

I think a lot of that despair is industry self-inflicted. I've been in the software industry for a long time and I can't remember a time when the industry created as many new buzz words as quickly as it does today. Take something as simple as ASP.Net for example. In just a few years it has gone through these iterations: * Classic * WebForms * MVC * MVVM * Razor Each name change represent nothing much more than a new…

I definitely get the sense that industry has only accelerated its churn rate over time. Just looking at what's happening to Javascript in the past year or two gives me butterflies in my stomach: There is attractive stuff and necessary stuff, and it's only getting harder to tell the two apart.

While I wouldn't say that everything about old-school coding is great, it encouraged a first-principles engineering process - checklists, printouts, technical docs, etc. - that is eschewed today in favor of looking up some framework and fumbling your way through to half-understand what's going on and leaning on the toolchain(which you also don't understand) to give you some reassurance that it isn't completely broken. This is discouraging for _everyone_, not just learners.

Re: Why Learning to Code Is So Damn Hard

#205

Post by ingler » Thu, Feb 05, 2015, 1:23 AM UTC

Stratoscope wrote: post #140

ingler wrote: post #110

Earlier quoted context omitted.

I was 8 years old in 1970. My dad was working for NCR in Waltham, Mass. He'd bring home a honkin' huge teletype and an acoustic coupler on the weekends. I taught myself BASIC and got hooked on Hamurabi [0], my first computer game vice. How much paper did all of us go through back then? [0] http://en.wikipedia.org/wiki/Hamurabi

A lot of paper! Do you remember the first time you saw one of those newfangled "glass teletypes"? A terminal that printed out your typing and the mainframe's reply on a CRT instead of paper? Was your first thought anything like mine: "How do I look back at what I was working on a few minutes ago? There's no roll of paper piled up behind the machine! How do I see my printouts?"

You know, I honestly can't recall my first glass teletype. I'm younger than you are so maybe it seemed like a natural evolution at the time.

I left the computer world in the late 70s when I discovered girls, music and partying. I came back to it the 80s when I learned about networked computers. Even through all of the intervening years, my coding still sucks. ; )

Re: Why Learning to Code Is So Damn Hard

#206

Post by dwd » Thu, Feb 05, 2015, 2:03 AM UTC

SilasX wrote: post #71

rcthompson wrote: post #43

When I was in college, one CS professor explained the difficulty of coding to me in terms of discreteness vs continuity. In the real world, things are continuous. If you accidentally build your structure with 9 supports instead of 10, then you only lose 10% of the strength of the structure, more or less. The strength varies continuously with the amount of support. But if you're writing a 10-line program and you forge…

Unless you're doing Rails, in which case it'll be read as a magic method and guess what you meant :-P 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".

Just wondering whether a distinction should be made between learning a framework (RoR, jQuery) and a language (JavaScript, Ruby). Frameworks do magic, languages generally don't.

Re: Why Learning to Code Is So Damn Hard

#207

Post by shostack » Thu, Feb 05, 2015, 2:19 AM UTC

cblock811 wrote: post #142

SilasX wrote: post #71

Earlier quoted context omitted.

Unless you're doing Rails, in which case it'll be read as a magic method and guess what you meant :-P 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".

I've been teaching myself off of online resources and 'magic' was what I hated most along the way. I can't debug magic. I've ended up digging so deep to understand things that I'm covering assembly now. It's painful, but going so far has made everything else make a lot more sense. Data structures are easier to conceptualize and will be easier to work with (for example). But most people I know don't get this far when…

I'm in a similar boat. Started with the training wheels of Codeacademy and such after having a basic working knowledge of HTML/CSS/JS and wanting to build database driven projects and grow my skillset.

Picked up RoR and was quickly overwhelmed with a million unfamiliar concepts as pointed out in the excellent (and very similar) article "This is Why Learning Rails is Hard."[1]. That knowledge tree they show is one I didn't formally stumble upon until later, but throughout my progress I realized "hey, this concept is really part of the much broader topic of X." Then I'd go down a rabbit hole on X.

Before I found that tree though, I had already given up on Mike Hartl's tutorial once, and decided I really needed to have a functional grasp of Ruby and core programming concepts. From there I realized "Ruby/RoR on Windows is not ideal." Then went down the whole devops path and learned about things like Vagrant/Chef/Virtualbox, etc.

I also started picking up books on much deeper computing concepts to understand the lower level mechanics of the magic. Like you I went down to first principles and even a bit of assembly. I couldn't write any to save my life and knowledge is still fuzzy, but I now grasp how the concept of data structures came to be, and more importantly WHY.

I recently tackled Mike Hartl's Rails Tutorial again. His updated version is a great improvement, and this time I actually understand the concepts he goes through. When a new one is introduced, I have enough of the underlying knowledge to at least have a sense of what/why something is, or what I need to Google to learn more.

I wish more classes online provided "deep dive" resources/links on things. Like, if CodeAcademy has an exercise on Ruby covering types, an eager student might really benefit from a deep dive sidetracking into dynamic vs. statically typed languages, and a high-level of what they should know.

My biggest gripe with the tutorials that are out there these days is that they cater to either absolute beginners or competent users. Wish they did a better job of trying to bridge the gap from absolute beginner to intermediate.

Another great example of that is the concept of design patterns. I haven't found many great beginner/intermediate resources on this, but as I've started learning more, I found myself saying "hmm, seems like lots of people do this a similar way--I wonder why." Turns out some approaches to problems are largely solved issues for a majority of use cases, hence: design patterns. This got me down the whole path of software architecture and starting to grok some of the higher-level abstractions and way of thinking in the abstract which was tremendously helpful compared to just being given specific examples with no broader context.

[1] https://www.codefellows.org/blog/this-is-why-learning-rails-...

Re: Why Learning to Code Is So Damn Hard

#208

Post by mamcx » Thu, Feb 05, 2015, 2:26 AM UTC

Great post.

Something to add: This cycle not happened only once in a programmer life.

IS RECURSIVE!

Every time you start with a new language or tool or job, the cycle start again.

But is added ANOTHER step: Overconfidence and blind arrogant OR indifference.

This is revealed when somebody dismiss the new language/tool/programing job and because is more-or-less similar to previous knowledge and could learn the basics of it in days/hours then think it nailed again. Is possible to be in this new honey-moon for a while (or forever somethings), but could eventually and suddenly hit hard that you are NOT A MASTER OF 2 SKILLS, you are a (maybe) a MASTER of 1 and a noob of 2.

The arrogant & indifferent mind also is revealed in the condesending thinking towards who are outside the "guild" or "below" us. Is very easy to believe you are in the laters steps, when is really not.

The key point in this article is the problem of "you don't know what you don't know". For years I imagine I was a decent developer (and could have said similar things as others in this threads) but is only in the last 2 years where I realize how misplaced my understanding was. I was in the "The Cliff of Confusion" and very happy about it ;)

Re: Why Learning to Code Is So Damn Hard

#209

Post by sciurus » Thu, Feb 05, 2015, 2:47 AM UTC

lelandbatey wrote: post #84

SilasX wrote: post #71

Earlier quoted context omitted.

Unless you're doing Rails, in which case it'll be read as a magic method and guess what you meant :-P 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".

That is absolutely something that irritates me. I've just inherited a large RoR application, and the amount of "magic" and things by convention is driving me crazy. There should be answers to questions like "why is this the way it is?!" On a side note, if anyone has some great resources for RoR, I'd love to have them linked. I suspect my inexperience is the source of my problems, and I'm welcome to any assistance any…

If you're not an experienced Rubyist, I'd recommend reading David Black's book The Well-Grounded Rubyist. Unlike many introductory books on programming languages that focus on making you productive in that language quickly, it focuses on building a deep understanding of the language. When I later read the book Metaprogramming Ruby, which uses parts of Rails for many of its examples, I already knew many of the techniques thanks to David.

http://www.manning.com/black2/

Re: Why Learning to Code Is So Damn Hard

#210

Post by john_butts » Thu, Feb 05, 2015, 2:55 AM UTC

Speaking as a rockstar bacon ninja Viking pirate robot code fu guru unicorn damn hell aged and wise app developer, many of these problems could be mitigated or eliminated in the web dev world if the web dev community could just slow down a little and clean up their existing messes before inventing twice as many new slightly shinier messes every funding cycle or so.