A Cautionary Tale of Learning to Code

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/)

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

What is interesting to me is that we have gone from having computers go from giant obscure machines in room, leased by large corporations, to having them all over the place in your house. There is a gradation of expertise and capability as there are with cars or other complex systems. From 'tinkerer' (usually a hobbyist) to 'mechanic' (who earns money adjusting and fixing) to 'engineer' (who earns money designing from scratch). They also come with different financial liabilities.

And that last bit is something that computers have largely avoided by consistently disclaiming all warranties. When that changes, and programmers (or their employers) are held liable for the incidental or consequential damage caused by their bugs, you will see a much stricter code for hiring and employing people who write code that runs on other people computers.

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

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 ) - 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! ]

Learning without casting a wide net may means you end up with the kind of tunnel vision that used to lead poor souls to 'learn Dreamweaver', or 'learn Crystal Reports', or ... ASP.NET controls, or something.

This guy ended up with a sense of the tech landscape, and knowledge that will serve him well. In one year!

Honestly, if people copied him and just avoided editor/keyboard silliness, they'd do well.