
A Cautionary Tale of Learning to Code - michaelq
http://blog.freecodecamp.com/2014/11/a-cautionary-tale-of-learning-to-code.html
======
dkbrk
I think the author is correct in that he tried to learn too many things at
once; starting with a friendlier environment and focussing on a small number
of new technologies has obvious advantages.

But in some other ways, the author is too self-critical:

> I'd spent months sitting alone in libraries and cafes, blindly installing
> tools from the command line, debugging Linux driver problems, and banging my
> head over things as trivial as missing parenthesis.

All these things have value, and I doubt that this was time truly wasted.
Although some people can get by for a while without it, becoming intimately
familiar with the command line is extremely valuable. Also, although this is
by no means a requirement for being an effective programmer, most good
programmers I know use a traditional text editor such as emacs or vim.

Ultimately, I think the point is that expending time is an investment, and you
should prioritise based on the expected future utility from your time
investment. More often than not, this means finding the most important thing
and putting almost all of your energy into it.

~~~
pwnna
>> I'd spent months sitting alone in libraries and cafes, blindly installing
tools from the command line, debugging Linux driver problems, and banging my
head over things as trivial as missing parenthesis.

> All these things have value, and I doubt that this was time truly wasted.
> Although some people can get by for a while without it, becoming intimately
> familiar with the command line is extremely valuable. Also, although this is
> by no means a requirement for being an effective programmer, most good
> programmers I know use a traditional text editor such as emacs or vim.

I agree. I think the prime takeaway is do what you need to do to solve a
problem and then most of these things that the OP described came organically
for me: I started on Windows, learned programming via Python, used a wide
variety of text editors. Eventually I grew dissatisfied by the tools windows
provided me and installed Linux. I spent many hours debugging weird weird
issues with my then laptop, until one issue (a kernel bug? I think...) forced
me to abandon that laptop and switch to a thinkpad. When I started my first
software job my coworkers recommended vim to me. After I used it for a while,
I began to become fond of its key bindings so now I'm using sublime with
vintageous and just straight up vim if necessary for my development.

Along the way, I've learned unix tool sets, dealt with init system, know how
to find and interpret logs in a reasonable manner, figured out where to get
help from people if needed, and so forth. The experience from this is
invaluable to me when looking at a problem and being able to quickly identify
at least where the problem is coming from based on what I've seen in the past.

At the end of the day it all depends on what you're interested in and what
problems you have/need to solve. I'm interested in the stuff I've done, so I
found it to be a valuable exercise (albeit some headbanging every now and
then). If someone is only interested in doing iOS development or Windows
development. They might find the things I've fiddled around with to be not
useful, and I think they would be right.

------
SnacksOnAPlane
I think the key takeaway from this is that you need to focus on learning one
thing at a time. If you want to learn how to program, don't distract yourself
by trying to learn some complex text editor at the same time. Use whatever
plain-text editor feels easiest to you. And use the environment that's easiest
to get going in.

As you learn more, you'll find things that annoy you about your
editor/environment. Fix those as you see fit. Eventually you'll have an
environment that fits you "like a glove".

It's absolutely detrimental to try to get a fully customized environment set
up before you know what your workflow is going to be like. It took me years to
get to my environment (tmux, vim+plugins, ack, a VirtualBox environment with a
proxy). I experimented a lot. But getting "the perfect environment" was never
a goal; it was just a lot of "this is annoying, there has to be a better way
-> google -> environment change".

------
ndcrandall
This was one of my biggest issues, even as an experienced developer with a CS
degree. I always felt a step behind since I wasn't fluent in the latest and
greatest framework. All of that changed when I mentally decided to focus on
one language, namely Ruby. It's amazing how much you can do with any one
language even though it's not fully optimized for a specific use case you
need.

------
michaelvkpdx
Great article and observations. It's always good to see what this field looks
like from a newbies' eyes.

If it only it were so simple as keeping a small tool set and a dev team
committed to it. You can certainly build a business from scratch with a small
toolset. But as the business adapts to customers, you always start to find
things that customers want that the tools do not support. In initial dev, you
don't necessarily care, but when you're live, it's better to implement than
say 'no' to executive management and sales in most (not all) cases.

Once you modify the tools a bit to support the unique business, you're no
longer able to keep new developers focused on a small toolset, because you've
customized. New devs may not agree and may look for ways to work around the
customizations. Soon, you have a unique codebase that is valuable- central- to
the business, and your changes have crept in to the point that off-the-shelf
devs and tools and upgrades don't work.

Now you're in maintenance mode. Code schools don't teach maintenance, but it
is the lifeblood of the software business. Developers avoid maintenance jobs.
They try to find new, greenfield work. That's why we end up with so many
disposable business models, 3 year dev-to-acquisition cycles, and ridiculous
amounts of abandoned code.

Maintenance is hard. Much harder than development. But it's much more
important. Anyone can launch an app that builds a business. Not everyone can
adapt and grow that business with code changes that require getting out of the
dev comfort zone.

Code schools don't teach this because they don't want to expose aspiring
coders who just want to get rich to the grimy dirty details of a real
profession. But ask yourself this- would we have cars and highways if all we
trained were new car designers (not mechanics or road builders)?

------
edw519
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, googled it, and within 15
seconds, I was working through a random 4 Handed Dentistry tutorial.

A week later, I went to my first dentalspace meeting. Everyone was talking
about techniques like orthodontics, endodontics, and maxillofacial surgery.
There was so much to learn. I borrowed three O'reilly books and got about 50
pages into each of them.

Most dentistry books start off nice and easy before making big assumptions
about your prior knowledge.

A friend told me I should get good at drilling, and gave me his drill bits. I
spent a few hours learning basic foot controls so I could further configure
it.

Then some guy walked by and saw me drilling. "Why are you drilling?" he asked
me. "Don't you know lasers are better?" "Hm. Lasers." So I started memorizing
dozens of laser shortcuts.

Most arguments about restoration techniques are what dentists call "religious
wars" \- rooted more in historical differences than practical merit.

At the time, it seemed reasonable to think that the faster I could drill, the
faster I could fix teeth. I switched to a hydraulic drillset because, hey, it
was objectively the most efficient method a dentist could use.

Can you count how many letters, numbers and teeth are in their original oral
positions? I'll give you a hint - it's in the low single digits.

On the days I could actually get my netbook to successfully boot DentalCAD -
and that I was able to drill more than 10 teeth per minute - I studied oral
surgery by working through books and Udacity courses.

After 7 months of grueling self-study and going to dental events, I landed my
first Dental HMO job...

You kinda get the idea by now? I dunno, I think what we do is every bit as
professional as dentistry. So why don't posts like OP's seem as absurd as
mine?

[UPDATE: For those of you who have suggested that programmers don't have
others' well-being in their hands, actually quite a few of us have, just not
as directly as dentists. We are a profession and we do do important work. A
few examples in an old post:
[https://news.ycombinator.com/item?id=2882620](https://news.ycombinator.com/item?id=2882620)]

~~~
jng
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
tech companies for $30MM, month in and month out. (2)

Because we call it "software engineering", but it still isn't engineering at
all. (3)

Software development is still a very, very young field. The fundamentals are
not properly understood yet. It will still take decades before they are,
possibly over a century. We won't be able to put proper education in place
before the fundamentals are well-determined.

Agriculture, livestock breeding and cloth making are many millennia old.
Architecture, engineering, and the law are 2-3 thousand years old. Book
printing and complex music are about 1,000 years old. Dentistry is centuries
old. Cinema is over a century old. We know a lot about how to do those
properly, and schools are pretty good at teaching the important parts.
Software development is less than 50-years-old, and schools are still dismal
at figuring out the important parts (practitioners are only so-so most of the
time too). That makes it different.

It would be hard to get more misguided advice than what the OP received (pro
tip: don't learn vim, Emacs, configure Linux or switch to Dvorak before you
can write functional, working code). That doesn't mean teaching yourself is a
bad way to learn.

(1) Why can't programmers program, by Jeff Atwood
([http://blog.codinghorror.com/why-cant-programmers-
program/](http://blog.codinghorror.com/why-cant-programmers-program/))

(2) Summly

(3) Just a random sample, but very representative: I developed a software
package for building structure calculation about 20 years ago, helping an
architect with the software part. There are manuals enumerating the exact
steps to follow and excess safety measures to add: assume 50% extra weight,
40% wind-load force with higher percentages for higher structures, twice the
amount of iron to be put into the concrete when certain conditions are met,
etc... Those manuals are _the law_. If you are an architect or an engineer,
and you follow those rules, two things happen: (1) you are not legally liable,
and (2) the building doesn't fall down! Software projects fall down all the
time (read: Obamacare). 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.

~~~
tjr
_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._

Sure we are, at least pretty close.

Commercial avionics software developed to DO-178B standards calls for reams of
requirements, verification tests, compliance to process, internal quality
reviews, external audits, and sign-off by FAA representatives.

A one-line code change can take days to implement, and might not be released
to "users" for months or years.

But the software is extremely robust.

If we wanted to engage in the same level of software engineering for _all_
software, we could. But we don't want to. Developers don't want to, and users
don't demand it. If an iPhone game crashes, who cares? If a productivity
application crashes, you might have lost an hour's work, but it's probably not
so annoying so as to warrant a couple orders of magnitude more cost associated
with the software.

But if a software failure could kill people, well, that's different. It's
worth spending a huge amount of time to make it perfect.

Avionics software can be so thoroughly tested because it is thoroughly
designed up front. You know exactly what it's supposed to do. Much less-
critical software is designed in a more ad hoc fashion; or there might not
even be a design at all! How much software has been organically grown,
starting with an idea and hacking on it until it seemed to work?

If you want to thoroughly test that, you have to go back and thoroughly state
what it's supposed to do.

It's quite possible, but by and large it's not desired enough to make it worth
actually doing. I'm not sure how this could change, or even if it should
change. Instant bug fixes on web applications are cool, even though they come
with the risk of having broken something else...

~~~
cbd1984
> But the software is extremely robust.

Does the specification specify the input as well, or is it _actually_ robust
against _real_ input?

By _real_ input I mean stuff like HTML tag soup: There's no single standards
document which describes it fully, or even mostly, and it isn't going to be
fixed. Ever. It simply has to be processed, to the limits of your ability to
process it.

Avionics software is robust, sure, but it's almost a toy problem, its domain
is so well-specified. You can ignore so much about reality because you've got
a contract which says "We only care about what's listed, everything else can
go hang" and in the real world (or, well, in the rest of the real world) you
can't usually do that.

~~~
tjr
A fair observation. In the example of handling HTML input, I would suppose
that's not a problem with individual developers, but a problem with the
industry. Such a relaxed format should not have been allowed to exist, if the
industry cared about its software products being as robust as possible.

I'm failing to think of any avionics application that might handle HTML, but
avionics systems do have their own formats to deal with. ARINC 661, for
example, is an XML file format for transmitting graphical display elements:

[http://en.wikipedia.org/wiki/ARINC_661](http://en.wikipedia.org/wiki/ARINC_661)

Of course, all uses of ARINC 661 data are thoroughly tested. I'm not sure I
would go so far as to describe it as a "toy problem", but it certainly does
intentionally limit the problem domain to exactly what needs to be dealt with.
Malformed ARINC 661 data received would just be discarded, not tried to be
displayed in the best possible way even if it wasn't quite right, because that
would be unacceptable; the problem would be with whoever was sending the
malformed data.

Anyway, you're quite right though; without a precise and unambiguous format
definition, you can only go so far down the path of robustness.

~~~
jasonm23
> Such a relaxed format should not have been allowed to exist.

Amen

------
bitwize
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 fun ones that have separate
compilation steps and may produce segmentation faults if you're not careful.

~~~
twic
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.

~~~
pcthrowaway
> 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.

~~~
twic
The thing is, in the JavaScript i've seen, there is no direct use of
prototypal inheritance. Instead, there's some mechanism, usually involving a
method called "extend" which implements something that looks like classes and
instances on top of prototypes. This is what i meant by "artisanal object
systems".

------
notto11
The overall message of this post is great, I've wasted plenty of time learning
a shallow amount of "cool" tools.

One thing I wish I knew starting out was how to create a basic VM. I shudder
to think of all the time wasted thinking I was a sysadmin genius for dual
booting Linux and later doing something stupid to my hard drive. VMs give me
my Linux environment without the pain from those moments when I think to
myself "maybe I want to be a kernel developer."

------
ericcumbee
Really good advise. All mistakes that I seem to make repeatedly. I've gotten
started trying to learn one thing and then jumped over to something else (i.e.
node or rails) because it was what the cool kids were doing.

------
kiraken
This blog post is an insult to every developer out there. The blogger actually
want us to believe that he just overheard a conversation, went home, googled
what ever he said he heard and in 7 months became an expert and landed a job.
So in my professional opinion, and i do get to say that as opposed to the
blogger since i actually studied Computer science and been a developer for 20
YEARS, that his story is a work of fiction, or the company that hired him is
one of those startups that just hires anyone that walks in the door like most
of them these days. A developer needs time not just to learn a language, trust
me once you learn one you learned em all, you just need to get used to the new
environment and light changes in syntax. What you need time for is to learn
the LOGIC of our trade and learn how to fix errors and how to improve/optimize
your code. And all of these things come with time and effort and no amount of
facebook posts or reading books could teach you that.

~~~
Sammi
> or the company that hired him is one of those startups that just hires
> anyone that walks in the door like most of them these days.

Ding ding ding.

You could replace startups with company though, because there are loads of
companies of different ages that would hire someone with only 7 months of self
study of programming.

Cause the thing is that the industry is starving for software developers.
Those that are not employed either live in rural areas without jobs in
general, aren't trying, or are just unbelievably bad at job interviews or work
overall.

~~~
kiraken
And even considering all of this i highly doubt any company that pays more
than 500$ a month would hire someone with 6 months of experience. That much
time is not even enough to master html and css

------
onion2k
This is why having a mentor/tutor is important - if you can focus for months
_on the right things_ you'll learn quickly. Focusing on the wrong things means
a lot of that effort is wasted.

------
spain
This actually mirrors my own experience a lot, except for a few differences.
Biggest one being I haven't actually looked into employment yet.

I too bounced between Vim and Emacs until recently I decided to stick with
Emacs. I too switched to Dvorak, later switching to Colemak. I used a typing
tutor software with which I was actually able to get up to a respectably 50-60
WPM if I remember correctly. However I eventually switched back to Qwerty
after growing tired of keyboard shortcuts never working the way they were
supposed to. Sure I could rebind them in my favorite editor (and even that was
a pain in the ass) but each time I installed something new I'd have to do it
again. One thing I am grateful for from Colemak is rebinding Caps lock to
Control, what a great idea.

I've also been dabbling between C, Lisp, C++, Python, Bash, and a few others,
but I never really became really good at any of them. It was more than just
the OPs 50-page dabble (something like 400 pages into C++ Primer) but I feel
like I can relate. Sure I can write basic programs in all of them but I didn't
have a "default" so to speak that I've mastered. Only recently I made the
decision that Python would be that default. The reasoning behind it is simple,
I already kinda knew it and it fit my use case well. I just wanted to do stuff
with the language and Python makes it easy with its wealth of libraries and
(in my opinion) intuitive structure. Stuff like Lisp and Haskell still have a
place in my heart because of how elegant they are, but I just feel more
productive in Python.

That's my sort of ongoing story of getting at what I feel is the same kind of
focus the OP was talking about. Now if only I could just settle on a Linux
distro instead of hopping around every few months (currently messing around in
Slackware, though I suspect I'd be better off switching back to Ubuntu which I
was using before I switched to Slackware).

~~~
ibebrett
I have been programming for 10+ years (and really more like 15 if you count
being a teenager coding), and I change languages/editors/distros all the time.
I have never switched keyboard layout (this honestly to me sounds like the
biggest waste of time I have ever heard of). I am just saying that its not
about finding some random piece of technology that you stick with forever, 90%
of the time its using the right tool for the job, or contributing to something
that already has momentum.

~~~
axotty
If you're already a decent QWERTY typist I agree it is a waste of time to
learn a new keyboard layout.

But if you're hunt a peck QWERTY typist who decides to pick up touch typing,
choosing an ergonomic layout like Dvorak or Colemak makes sense. You're
essentially staring from zero anyways so you're not wasting much time on the
layout anymore so than you would on the QWERTY layout.

This way, you retain your two-finger QWERTY skills while learning a layout
that minimizes the odds of developing RSI.

~~~
ibebrett
I suppose so, it just seems that the odds that you may need to work on a
machine that isn't setup for you is probably going to be pretty high at some
point. I agree that RSI is probably something we should avoid, but other than
that things like typing speed have zero effect (in my experience).

~~~
axotty
It's takes a trivial amount of time to set up these layouts on most machines.

I agree that good typing skills do not necessarily make you a more productive
programmer. But I do find that it is a skill that compliments other
programming skills nicely. It's also nice for countless other parts of my
workflow that do not include programming.

~~~
ibebrett
let me put it this way. i have never met a programmer who's productivity was
at all based on their typing speed.

~~~
axotty
I think you misunderstood me. I never claimed anything like that. In fact I
suggested most of the benefits of touch typing are not related to programming.

That being said, you will never know the benefits of touch typing if you can't
touch type. You seem to be threatened by the thought of it being a valuable
skill so I won't try to convince you otherwise.

~~~
ibebrett
i can touch type just fine. I'm not threatened by the concept of touch typing,
I am making the case that its a waste of time to try and learn to touch type
another keyboard map. While it may have some benefit, there are literally
thousands of things you can do that will be much more useful than learning to
touch type dvorak.

~~~
axotty
We've come full circle to my original reply to you. If you are going to learn
to touch type you are starting from zero with QWERTY anyways so using a new
layout wouldn't add any additional time.

> there are literally thousands of things you can do that will be much more
> useful than learning to touch type dvorak.

You could say this about any skill or hobby. You are not the arbiter of
usefulness. Plenty of people have derived utility from learning to touch type
Dvorak or Colemak. You're writing them off out of pure ignorance.

------
arenaninja
Focus is hard, but it's great that you learned this in under a year. I still
have issues with focus now and then. Like when I decided that I was gonna
spend 2 hours after work for a week on new tech and decided to try and pick up
clojure... except that I'd never used a lisp, and after a myriad of compiler
errors that I was plowing through, I eventually gave up and I know no more
clojure today than I did then. In the meantime, I passively continue to
improve on those things that I do know (PHP/Python/JS).

I had the same issue with emacs/vim and while I use vim now, I don't consider
myself a vim power user

Lastly, the OS... I started with Ubuntu, wasted a week trying to get CentOS
minimal up and running (I couldn't), ran with Kubuntu and have used it for
about a year. Fedora is growing on me right now since I just spent the past
week downloading/destroying/upgrading VMs, but I think that was more trying to
find the right flavor of Linux for what I need than anything else (and with
Faience theme, GNOME 3 is pretty good, although slow in a VirtualBox VM since
you can't have more than 256VRAM)

------
ryanolsonx
I can definitely recommend your key point in the article: focus. It is easy
today to lose focus since there are so many different frameworks and
programming languages. Even if you just focus on Javascript, there are so many
different frameworks here (ex. angular.js, ember.js, react.js) that it's easy
get distracted and get to a point where you are only familiar with each a
little bit.

Great article.

------
bswen
I've worked as the main developer and designer at an online publication using
Drupal, then WordPress, among many other duties including communications and
social media. I learned enough PHP and HTML/CSS/jQuery to write custom themes
and a couple custom plugins. Recently I started working a side project as a
technical cofounder (called SpareChair) and have been working with a
design/dev shop to build the site with Rails. The TeaLeaf Academy has nailed
the tough problem of learning to code with Ruby and Rails online. It's a
Goldilocks combo of written and video tutorials and exercises, weekly live
sessions and nearly instant responses to questions from students, the founders
and TAs in their project forums. It's focused on producing a coder ready to
sit in that dev bullpen and hang with everyone from day one of the job and
accomplishes that goal. And it's very affordable, the ROI is amazing. Anyone
looking to get into Ruby and Rails should check it out.

------
AlexanderDhoore
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...

~~~
BonsaiDen
There are a whole lot of things every programmer should know because they'll
have a profound impact on their code no matter how far up they sit in the
abstraction chain.

Even things like memory alignment and cache lines can bite you really badly if
you don't know about them and order your loop the wrong way around :)

Date and Time Handling, Unicode and Data Structures are also a common area for
many misconceptions and sources of error. Of course nobody needs to know
everything, but have a lively thirst for knowledge always helps, especially
one you got over the initial confusion of learning the basics. There's just so
much interesting stuff out there and a lot of it will help you improve even if
you don't end up using it right away / at all.

Even if you're just swimming on the surface, it's always a good thing to know
at least the 1-3 meters beneath you, just in case something happens or you get
stuck in some seaweed and struggle to get out on your own.

I've actually made quite some good experiences with teaching people a few
things about ASTs right once they started writing code, even though I only
gave the some very basic lessons about how the "text" is eventually
transformed, it really helped them a lot in understanding why certain text
does certain things.

In the end, it's always very hard to play the game successfully if you don't
know the rules by which you have to play. And a little can go a long way.

~~~
jtchang
Do you mind going into memory alignment and cache lines and what would be good
to know? I feel like I ignore most of that unless I am coding in C. I mostly
do python or Javascript so does that stuff mater when you are that high up in
the tech stack?

------
jreed91
The author makes a great point and something I've been struggling with. We
have so many great tools and with tech constantly improving it makes it hard
to focus on a single topic area. Personally, I've gone through so many
tutorials on so many different languages and frameworks (Obj-C, javascript,
python, ruby, etc etc etc) but have never really focused on a specific stack.
I think the most important for any new developer is to choose an area like web
development or ios programming and focus on the fundamentals of programming.
It's just like learning a foreign language, you're never going to be able to
speak fluently until you do it everyday for months or years.

------
TheHypnotist
I like this article because as someone who struggles with learning to code, I
have found myself making it worse by jumping from language to language,
learning the very basics of their syntax. Great, I can FizzBuzz in 4 different
languages, but I still can't put together something comprehensive and useful.

Reading this was kind of the reminder I needed. Focus. Pick one, become
proficient (with the language and just the concepts of programming), and I
guess somewhere down the road if I feel compelled try another.

So for now, I'll focus.

------
gcv
There's a difference between learning computation (how to make a computer help
you solve problems), and all the bullshit you have to do to build software
(especially for other people). The former involves timeless concepts. The
latter is full of fads and arguments over tools, broken dependencies and
configuration nightmares. The author hasn't actually learned that, yet — he
just started working with people who standardized their tool chain for some
semblance of simplicity.

------
josephjrobison
Thanks so much for this, been learning and failing with some decent wins for
years. Any time there's a clear, focused guide for learning to code I get
inspired again.

------
icarot
The last sentence was the most important; the rest should be ignored. Have
patience, perseverance, and you'll do anything.

Or, converge onto interesting problems and fail gloriously; the only way to do
anything of worth.

The post comparing this to dentistry is precisely what I was thinking, except
nowhere near as hilarious. I wish I was intelligent enough to write a Markov
algorithm for logic that paralleled reasoning in such a way automatically.
Thank you for that.

------
mrpoptart
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.

------
drcomputer
I am going to be slightly rude, but only because I have done exactly the same
thing.

Stop trying to cram n years of experience into a blog post seeking some form
of social validation. You are guaranteed to contradict yourself more than half
the time. That's because you can't include all the important bits that helped
you learn. Every stupid mistake is really your future best friend.

------
foopod
As important as it is to have expertise and proficiency in a single skill, I
also believe that the more diverse your knowledge base the easier it is to
pick up new things when you need to.

But maybe I am just trying to make excuses for myself, maybe if I learn a new
language/framework/IDE every month I will get better at learning new
languages/frameworks/IDEs.

------
vezzy-fnord
_I 'd spent months sitting alone in libraries and cafes, blindly installing
tools from the command line, debugging Linux driver problems, and banging my
head over things as trivial as missing parenthesis._

Yet this illustrates a very important thing that most proponents of "learning
to code" neglect entirely.

Writing code isn't an isolated black box. To write code is to interact with
the extremely entangled software environments that we have cumulatively been
building up for over 60 years now.

Anything beyond Fibonacci sequences will require you to spill out into lots
and lots of domain-specific areas and subdisciplines. A proficient programmer
in general will also need at least basic skills in system administration.

To build a real useful application intersects with areas such as network
protocols (which is immeasurably vast, depending on what layer you pick and
how much you abstract), widget toolkits (and the wider quandaries of computer
graphics, windowing, displays, etc.), cryptography (which pretty much
intersects with most bodies of computer science), the workings of the kernel,
dynamic linker (thus object files and libraries), the C library...

Profiling an application will likely require you to learn some complexity
theory. I/O-bound applications will require you to learn how file systems, I/O
schedulers and disks work. System programming is a rabbit hole of its own,
with POSIX alone just about being an independent branch.

The bottom line is that programming can mean just about anything. And since
programming itself is not innate, but a member of its own in the tangled web
of computing, programming is thus a vast body of theory itself, a lot of which
one will need to learn, unless they intend on staying frozen.

Paradoxically, the more we try to make things so that people won't have to be
specialized in order to use them, the more we necessitate huge drifts of
specialization in the people that want to do more than cursory tasks.

While picking a few components and sticking with them is probably necessary at
least in professional environments to maintain sanity and interoperability, it
is not very realistic for hobbyists and learners.

Of course, if you just want to write macros to automate tedious tasks, you can
get by with the basics. But that is pretty much something that will end up
being born from necessity, and likely self-discovered rather than taught
through compulsory means.

------
cylinder
How did you land job interviews after being self-taught? I'm doing the same
right now, but I assume I need to complete some sort of bootcamp or what not
in order to actually land an entry level job as a web developer. How do you
get noticed when you don't have formal experience?

~~~
JamesSwift
Have something to show. I don't know what technologies/languages you have
experience in and/or are looking to interview in, but having a single example
of a fully completed app/webapp will get you to the interview portion in a
fair number of places.

------
cranklin
The problem is that crash-course developers are too satisfied with just making
something work and most online tutorials are focused on language syntax. If
you're learning to code, great for you... but I'd be scared to be part of your
team, maintaining your code.

~~~
TillE
Yeah. There's a huge difference between learning "how to code", and how to
actually design good software. Lots of a focus on the former, almost none on
the latter.

~~~
twic
I'll cut the young 'uns some slack here. You need to learn how to assemble
curly brackets and semicolons and whatnot into a machine that actually does
something before you can learn how to design machines. The art of design is
the difficult and important part, but it's impossible to learn it before
learning the basics of construction.

------
scarygliders
For the past year I've been learning to code in Python. My basic methodology
was this;

I had come up with an idea for a niche product - I reckoned at the time that
something like this would sell. All I needed to do was to code it up - at the
time I had been reading about Python and had tentatively prodded and poked it
as I wanted to find out why a lot of my acquaintences were always scoffing at
this language... "I friggin' hate whitespace!" seemed to be the number one
reason for not bothering with it, which was an instant reason for ME to get to
know it as I'm the kind of guy who likes to see what all the fuss is about.

So I had an idea, and I had chosen the language to learn and implement the
idea in. That was the easy part. The hard part was to learn enough Python in
order to implement it.

I bascially started off with nothing and worked my way up from there by asking
"How do I do X with Python?"

I knew in my head what the program should be and what it should look like -
"it should be a GUI", for example. I'd already used the Gtk bindings for
python, but had gone off Gtk (as I've written before in a post on HN). So I
decided to give Qt a try. The answer to that is to either use PyQT or PySide.
I decided on PySide as I couldn't afford the PyQt commercial license (I want
to sell my application after all, and my budget is next to nothing).

After a while, I was getting used to how Qt Designer works for designing
layouts.

Next question was "How do I get the GUI widgets to send signals to my Python
code?" followed shortly after by "How do I see signals from dynamically
created tab widgets?" \- I ended up both asking AND answering my own question
on StackOverflow. ( [http://stackoverflow.com/questions/17344805/how-to-see-
signa...](http://stackoverflow.com/questions/17344805/how-to-see-signals-from-
qwidgets-inside-dynamically-created-qtabwidget-pages/17467700#17467700))

And so as the days, weeks, and months progressed, I needed to Do Things. For
me it was a matter of asking the How Do I Do That question and researching the
answer, then implemented it.

Before I knew it, I was increasingly getting proficient in Python, in Qt, in
parsing configuration files using ConfigParser, in loading and saving files,
in using QtWebkit in sneaky ways so I can display my company's animated logo
using CSS. And so on.

Then I needed a web site. So it took me 4 months to learn enough Django to go
implement a basic site. That site and the product I recently launched. (
[https://xrdpconfigurator.com](https://xrdpconfigurator.com) ) - that's all
done in Python, including the application - which was converted to C via
Cython then compiled to object code after that.

[ And now I've learned another important lesson after all that time and effort
- no one seems interested in my product - perhaps I should have open sourced
it and asked for donations instead ;) Or perhaps I just need to patiently
market the thing better. Or perhaps it is just TOO niche! ]

~~~
ianmcgowan
Likely some people would be interested, but it seems fairly unlikely that a
mass market would actually pay money for it.

Once you go from "all debian and ubuntu users" subset "those that use xrdp"
subset "those that need to customize their configuration" subset "those that
are willing to pay money", you probably don't have a lot of people left ;-)

[http://www.amazon.com/gp/product/B004J4XGN6?btkr=1](http://www.amazon.com/gp/product/B004J4XGN6?btkr=1)
\- The Lean Startup is received wisdom on MVP. On the positive side, you've
built a product and shipped. Now you can do it again, but with a product
people actually will pay money for.

~~~
scarygliders
Indeed, and it's actually been a fantastic learning experience in itself.

And yes, I do have one or two other ideas that aren't as niche and more to do
with real-world applications needed by many more people - something which I
was intending to move on to after I'd completed this one.

Thanks for the link to that book. :)

------
guncheck
This was a really good read. I thoroughly enjoyed it. Thanks!

------
vnagpal
i am still struggling with this problem, but great article and thanks for
sharing.

------
joemellin
Yes.

------
bafilius
definitely a lot of good points here

