A Cautionary Tale of Learning to Code

The list of techniques you provide is a hodgepodge of valuable but limited techniques, inapplicable theoretical results, and voodoo-like superstitions and rituals. They are all insightful and beautiful, but they do nothing to turn the discipline into software engineering. The day software development has turned into an engineering, you can bet the contractors who get awarded big contracts like the Obamacare web site would make sure they spend the $$$ to apply the practices which have been proven to ensure software projects become successful, they are still going to make a ton of money off the top of the contract, and that's what they do for large engineering projects for the most part. Nowadays, they are just at a loss, and try to get by, like everyone else in the industry.

GC: Apple keeps not applying it in iOS but switched to it for a lot of core OS X apps, notably Xcode 5, and switched back to assisted-referece-counting in Xcode 6 and others, since the performance degradation was noticeable. GC is great for many things but not for all. It's a trade-off.

Lexical closures: I am not sure this really makes software work better. I've seen many more well-engineered solid projects in C++ and Java, which lack them, than in javascript.

Hindley-Milner and purely functional programming: beautiful beautiful beautiful Haskell is probably the closest to practical purely functional programming system, and we have yet to see any proof that Haskell makes real software system implementation any better. Don't get me wrong, I love purely functional approaches, I designed and implemented a full custom regular expression engine with a purely functional design and implementation (even if I used C++ to write it), and it's the type of thing where the approach results in much better code in all regards. It's just still not practical for most things. I like to think about Haskell as computation poetry. It's just not practical.

MISRA-C: one entry which is just not compatible with the others. So if you are doing a project using C because it's the only practical option (controllers in vehicle engines being a paradigmatic case), it's good that there is a set of practices that, even if they make software 10x as costly, are quite good at preventing resulting deaths. I don't think this

Unit testing code coverage: another shaman practice, valuable but without providing guarantees. The space of program state is so combinatorially non-linear with regards to the space of its source code (read: entscheidungsproblem) that ensuring 100% line-wise code coverage is just a sad excuse in getting the whole building not to crumble. Better than nothing, still guaranteeing nothing.

Bug tracking systems: more good practices, guaranteeing nothing. Every single released software project I have worked on has been released with a ton of open entries in the bug tracking system. There is about as much team politics as engineering going on in a bug tracking system.

DVCS: yes, git is good and convenient, flexible collaboration, and flexible push/pull-based authority policies allow much more functional team dynamics, including fully auditable "sign-off" as part of the process. Defending this as if it provided any engineering guarantee with regards to the developed software sounds funny. Enforceable, auditable process is helpful and necessary, it ensures nothing with regards to the produced code.

Code review: frankly, this is the pinnacle of shamanism in your list. Four eyes see more than two. Eight eyes totaling 80 years of software creation experience are sure going to benefit the quality of the code. I find it indefensible this as "engineering", no matter if you include it in the commit/merge flow. It's just useful but totally fallible common sense elevated to policy.

Look, I don't shrug my shoulders, and I am not discouraging anybody from learning from past mistakes. I am saying that all the above are a nice but tiny start in the way to this field being an engineering. The difference between you and me is that I am convinced there is a set of tools and techniques which is so much qualitatively better that, once they're available, it will obvious that the current stage is more or less the stone age of software. They will provide a clear, concrete, enumerable set of guarantees about software and its production, allowing us to operate as engineers. Something which none of the entries in the above list do.

Your example from hobbyist to professional has real physical constraints that are huge to overcome for an autodidact like "where do I get a constant influx of patients to practice on" and that's solved with university. Building software only has "own a computer and have internet access".

As a self-taught my reasons for not attending university are purely financial. It's basically a subtle form to gatekeep lower-class "peasants" from following their own "brain craves" for knowledge and ascend the societal ladder under the guise of a higher moral cause, specifically the appeal to the professional worth. Tough luck for you and for anyone else from your social stratum that's going away sooner than you think, regardless of how loud your barking can be.

But what is more sad is the fact that there are at this time thousands of people trying to disrupt education and yet the highest rated comment in a place that should be focused in disrupting things actually tries to grip even tighter. That's what's sad.

Amen