Live data from Hacker News

A Cautionary Tale of Learning to Code

blog.freecodecamp.com

111–120 of 135 posts

Re: A Cautionary Tale of Learning to Code

#111
post #84

Very very good article, although the latter part is a bit too focussed on web dev and dynamic scripting languages. I personally think every programmer should know some C. Basic things like what the stack and the heap are. Edit: Ok, probably not in the case of absolute beginners, but after a year or two...

When I were a lad, everyone you'd meet in the industry had started out doing C on Unix, and had then specialised, maybe they liked Unix more and became sysadmins, maybe they liked C more and wrote Motif apps, or branched further out into C++ on Windows. But everyone had that core, fundamental knowledge. Nowadays people go straight into the very abstract stuff, and have nothing to tie it all together with.

C on UNIX? You were lucky! My dad had to toggle the bootloader into the front panel every morning before he could even run the assembler!

Re: A Cautionary Tale of Learning to Code

#112
post #90

I like the idea to choose one language, but... Start with Python. You're going to hear Ruby this and JavaScript that and Swift the other -- but seriously, I'm from the future. You should start with Python. It's essentially BASIC for this century: a great place to start learning the basics without being too weird. There's plenty of time and once you have those cold, you can investigate other languages, including the f…

The key thing about Python is that it's really plain. It's a straightforward procedural language - values, functions, names, calls, and that's about it. It has a simple object system, and some simple functional features. The whitespace business is superficially kooky, and there is a scary amount of metaprogramming and other craziness available, but people tend not to use it.

As such, it's a really useful preparation for learning other languages.

If you have the basic concepts from Python, then when you learn Ruby, you just learn some syntax and the special things that make Ruby distinctive (metaprogramming, monkeypatching, ubiquitous gemmery, Rails). When you learn JavaScript, you just learn some syntax and the special things that make JavaScript distinctive (callbacks, artisanal object systems, the interplay of JS and the DOM). You never have to learn to do without some special thing you've learned to depend on, because Python has no special things.

Well, that and it's incredibly easy. And it has a really strong batteries-included standard library. And it has a really friendly, helpful community. But mostly the plainness.

Re: A Cautionary Tale of Learning to Code

#113
post #32
post #21

A Cautionary Tale of Learning to Fix Teeth. My own. How a reasonably balanced individual nearly went insane I was just a guy in a suit in an office with a vague healthcare idea. Then I decided to learn to fix teeth. I overheard some guy at a happy hour bragging about how easily he was able to automate his overbite by using a technique called "4 Handed Dentristry". I thought, "huh, 4 Handed Dentistry." I went home, go…

Because one finds many self-taught developers out there who can outperform college-educated compsci majors day in and day out. Because one can read universally-acknowledged figures explaining how a large number of people with a software engineering degree can't code their way out of a paper bag or pass the most basic "fizz buzz test". (1) Because we can see non-genius 17-year-olds writing apps that are bought by top…

> That is engineering, software projects with today's tools and techniques are not. This will happen some day in software. We are not there yet, by far.

This statement is based on exactly the same fallacy as the featured blog post: ignorance. You are ignoring all the tools and techniques available for software engineering today: garbage collection, lexical closures, Hindley–Milner type systems, purely functional programming, MISRA-C, unit testing code coverage tools, bug tracking systems, distributed version control systems and code review practices around them, etc.

People developing widely used tools are still making idiotic mistakes that had widely known solutions 50 years ago: https://twitter.com/vsedach/status/527904732145537025

Engineering is about learning from previous designs. When you shrug your shoulders and say "software engineering isn't engineering yet" and "the field is too young" you are just discouraging people from learning from past mistakes.

Just because some idiot can pick up an oxy-acetylene torch and cut and weld some metal together doesn't make them an aerospace engineer. What's the difference with PHP developers?

Stop making abstract excuses and start treating software and software practices as tools and techniques. Tools and techniques have a history, a learning curve, and areas for improvement.

Re: A Cautionary Tale of Learning to Code

#114
post #26
post #21

A Cautionary Tale of Learning to Fix Teeth. My own. How a reasonably balanced individual nearly went insane I was just a guy in a suit in an office with a vague healthcare idea. Then I decided to learn to fix teeth. I overheard some guy at a happy hour bragging about how easily he was able to automate his overbite by using a technique called "4 Handed Dentristry". I thought, "huh, 4 Handed Dentistry." I went home, go…

Because there aren't a million online tutorials for learning dentistry and you need more than a computer and an internet connection to start learning.

Basically, the problem is that no sane person will let you mess with their teeth unless you lack the proper credentials, and experimenting on oneself can be painful enough that almost everyone will quit after their first equivalent of an off-by-one-array-access segmentation fault.

Re: A Cautionary Tale of Learning to Code

#115
post #25
post #21

A Cautionary Tale of Learning to Fix Teeth. My own. How a reasonably balanced individual nearly went insane I was just a guy in a suit in an office with a vague healthcare idea. Then I decided to learn to fix teeth. I overheard some guy at a happy hour bragging about how easily he was able to automate his overbite by using a technique called "4 Handed Dentristry". I thought, "huh, 4 Handed Dentistry." I went home, go…

He did focus in on python for 7 months which is good. I think what's missing is proper apprenticeship in software. He shouldn't be taking random advice to learn emacs/VIM from people, or use a new keyboard, or (a lesser extent) a new operating system. He needed a guiding instructor to tell him to learn how to code first and focus on building projects instead of trying to turn a 3-5 year education into a 1 year accele…

You should check out codementor.io. A buddy had a really successful time with it. Paired with 2 mentors and went from having 0 knowledge to an app on the App Store in 5 months.

Re: A Cautionary Tale of Learning to Code

#116
post #21

A Cautionary Tale of Learning to Fix Teeth. My own. How a reasonably balanced individual nearly went insane I was just a guy in a suit in an office with a vague healthcare idea. Then I decided to learn to fix teeth. I overheard some guy at a happy hour bragging about how easily he was able to automate his overbite by using a technique called "4 Handed Dentristry". I thought, "huh, 4 Handed Dentistry." I went home, go…

So why don't posts like OP's seem as absurd as mine?

I think the Fine Article does seem absurd. And while he doesn't come right out and say it, I think he would agree that in hindsight his approach was absurd. The whole second half of the post is about how actual programmers get actual work done, and it's nothing like the first half.

The interesting question is why did he think his original approach was reasonable? Did he not talk to an actual software engineer before embarking on his journey? Sure something like his original path can be successful for some people, but it that a reasonable expectation?

Re: A Cautionary Tale of Learning to Code

#117
post #73
post #43

Earlier quoted context omitted.

+1 I strongly believe that we're a profession and should have professional standards. On the other hand, I do suggest you look at hobbyist/quasi-professional magazines. It's.... not terribly dissimilar. Example cover: http://popularwoodworking.woodworkingplansplans.com/images/w... Conceptually, that's the same exact approach taken..

> +1 I strongly believe that we're a profession and should have professional standards. As long as we don't kill the goose which laid a lot of us golden eggs. If we destroy the ability of newbie programmers to come up outside the university-professional path, we've just irreparably damaged the whole field. This is also why I don't like the idea of unionizing programmers: Even if we come up with a union which isn't ba…

I look at it the opposite way. There needs to be a way to allow software developers to say, "My profession's ethics will not allow me to develop this (credit card, medical record, banking, etc) software in the way you've specified. You can either change X, Y, and Z, or give up on having the accredited software engineer label on it." It certainly wouldn't be required for many or even most applications, but it seems desperately needed right now (c.f. healthcare.gov).

Done right, this allows for both non-accredited software developers, and professional engineers to live and work side-by-side.

Re: A Cautionary Tale of Learning to Code

#118
I believe that your path didn't teach you to learn how to code, per-se, but that learning to code was a side benefit of learning how to teach yourself. Schools exist because specialization is useful, because having lots of people to help is useful, and because information is diffuse. On the bright side, once you know how to learn, learning additional things is easier, especially new things in the same field.

Re: A Cautionary Tale of Learning to Code

#119
post #25

Earlier quoted context omitted.

He did focus in on python for 7 months which is good. I think what's missing is proper apprenticeship in software. He shouldn't be taking random advice to learn emacs/VIM from people, or use a new keyboard, or (a lesser extent) a new operating system. He needed a guiding instructor to tell him to learn how to code first and focus on building projects instead of trying to turn a 3-5 year education into a 1 year accele…

You should check out codementor.io. A buddy had a really successful time with it. Paired with 2 mentors and went from having 0 knowledge to an app on the App Store in 5 months.

Thanks for the link. Applied to be a mentor :)

Re: A Cautionary Tale of Learning to Code

#120
post #112
post #90

I like the idea to choose one language, but... Start with Python. You're going to hear Ruby this and JavaScript that and Swift the other -- but seriously, I'm from the future. You should start with Python. It's essentially BASIC for this century: a great place to start learning the basics without being too weird. There's plenty of time and once you have those cold, you can investigate other languages, including the f…

The key thing about Python is that it's really plain. It's a straightforward procedural language - values, functions, names, calls, and that's about it. It has a simple object system, and some simple functional features. The whitespace business is superficially kooky, and there is a scary amount of metaprogramming and other craziness available, but people tend not to use it. As such, it's a really useful preparation…

> the special things that make JavaScript distinctive (callbacks, artisanal object systems, the interplay of JS and the DOM)

If you're coming to Javascript from pretty much any other language, prototypal inheritance is probably going to be the biggest difference in paradigm to wrap your head around.

Post reply on HN