You should try skimming to the end, where there are two pages of references. Not to mention the fact that Cardelli is a prominent figure in the study of programming languages.
And I think you'll find that Gilad Bracha is a more informed critic of reliance on static type checking.
That conclusion made me laugh. In the early to mid 90s, I was working on 3D interactive software. The video drivers and chips had advanced so much in one year that all of the lovingly handcrafted assembly I had written over that time was useless. I thought to myself, "what an unstable industry to build a career in". I also made comparisons to accounting, medicine, and law, thinking perhaps I had made a wrong choice.
Turns out that adapting to rapid change is a critical aspect to this career choice. It is also a problem for businesses, which you start to grapple with as you move up the chain of command. The mistake is wistfully hoping that things would slow down enough for you rest on your hard-won knowledge, as in other fields. There is no competitive advantage in aging technology.
Although the OP seems to be asking for "engineering" not "programming" books, I'm going to second this. Benjamin Pierce's "Types and Programming Languages" will help you get down to what programming is really about. If you are not familiar with lambda calculus and its notation, it may be rough going at first. But lambda calculus is VERY simple, and Pierce takes you through it. The book progresses methodically to the concepts found in most common programming languages.
This is one of the few truly language agnostic books on programming. SICP is close, but it is limited in relevance at times due to the limitations of a particular language (Scheme).
As a long-time advocate of functional programming, I was once asked after a talk what is the "best" FP language to learn. Since I'm known as a Haskell/Scala/ML person, I surprised much of the audience by answering that I thought F# was the best entry point. What I did not say, however, was that I think that Windows is a challenging environment for anyone who is used to Linux/Mac -- and this includes the "open source" world in general. I think that Microsoft is a leader in language design, but their platform relevance was slipping for many years. I believe it may be on the upswing (with Xamarin etc). I would encourage you to stick with F# as you will be further along in not only understanding FP, but other modern programming languages, including ones that haven't been invented yet.
He keeps warning not to write thousands of lines before talking to customers (as you often hear from biased survivors). But it sounds like they didn't find PM fit by talking to customers. Rather they identified -- perhaps out of desperation and exhaustion -- 0.1% of the code they had written that they thought might be useful and threw it out there. The takeaway really seems to be write as much code as you can, if one-tenth of one percent is going to be the golden nugget. Also, I suspect that they were able to use that other code and the processes around it to capitalize on their good fortune.
Speaking from personal experience ... At the time of signing you can see the upside (the offer), but you can't know the downside, which can be quite significant. It's a poor trade-off. Avoid these unless you get some kind of severance for the period of the agreement. Mere employment as "consideration" is a bad deal.
Here is an essay I wrote following my son's first technical talk, weeks after his seventh birthday. It references what I believe works in teaching children to program.
Not at all high-brow, but I revisit the in-the-trenches case study of "Scaling Pinterest" on Infoq from time to time because I find their fighting through the pain inspirational for my own scaling troubles.
Absolutely! Every time programming education comes up, someone brings up Scratch. It's advocacy is -- possibly detrimentally -- overused. It may be appropriate in some cases, but it is not a universal tool for introducing people to programming. There is certainly something inauthentic about using blocks. They may not be appropriate for people with motor-control issues. And the reliance on imperative constructs (assignment-based statements) as being essential for understanding computation is arguably wrong and possibly hurtful.
I only have a sample of 1 (my six-year-old son, turning seven today), but he is perfectly capable of typing, understanding function definition and composition, data structures, and working with reactive I/O. He's not some super-genius. He's a regular kid who likes to swim, ride his bike, play Pokemon, and watch Netflix. But he can also make things by "real" programming. I'm sure other kids could as well.
I was delighted to see most of the answers here encourage you to continue from where you are in your interests. Only one comment mentioned abandoning your love and going to where everyone else is. Bad idea. You will find that if you keep pulling on the threads that interest you, worlds will continue to open up. And there is definitely work in those worlds.
Age is definitely not a factor. The speed with which you are able to learn definitely is. Good luck. I think this is awesome.
I was delighted to see most of the answers here encourage you to continue from where you are in your interests. Only one comment mentioned abandoning your love and going to where everyone else is. Bad idea. You will find that if you keep pulling on the threads that interest you, worlds will continue to open up. And there is definitely work in those worlds.
Age is definitely not a factor. The speed with which you are able to learn definitely is. Good luck. I think this is awesome.
I teach my 6yo son using Pyret and Racket simultaneously. Pyret is, hands down, the best teaching language today, but hasn't been in use as long as Racket, so there aren't as many resources.
I would suggest that the need for Englishy variable names is due to a weakness in programming languages and possibly the programming model itself. Why should a set of legitimate values for a computation benefit from how you refer to that set? Can that variable take on undesired values? Do you rely on that name and its comprehensibility to distinguish good from bad values? I sometimes find it hard to believe we still program this way.
Even without trying to follow the proof proper, the sub-sections of the second part are interesting on their own, particularly Gödel numbering and primitive recursive functions. Here is another translation that covers just this part:
It's true that if you know nothing about formal logic, history of metamathematics, and decidability, then it's going to be particularly hard going, but there are a lot of accessible resources for each of those topics and the paper is well structured (meaning you can concentrate on the pieces).
The encoding that Gödel used for formulas should be fascinating for anyone familiar with Turing work on decidability as well as how computers work generally. Primitive recursive functions don't handle computation generally, but seem to be a first step in understanding what it means. Anyone familiar with Alonzo Church, lambda calculus, functional programming, McCarthy's first paper on Lisp would probably be interested in this bit.
Of course, Gödel's result on formal systems shattered the idea of an axiomatic basis for mathematics, but I personally think its greater long-term impact is helping to usher in computation. It's worth recognizing both.
Although it's nice to see Gödel show up in the popular press, I didn't get what the point of this was. His Incompleteness paper is not that impenetrable. Sometimes it does pay to at least look at primary sources in addition to listening to others' efforts to summarize or dissect. I don't think the author of this article made much of an effort to understand what or who she was writing about. Sad, really, given Gödel's importance in understanding the beginnings of a science of computation (easily one of the most significant achievements in human history), where there is already too much myth-making and mischaracterizations.
I had to wing it because the ages turned out to be younger than I expected. I've taught my 6yo son using Racket and Pyret so I had the basic approach already. Although I shot over their heads in spots, overall the girls seemed to be really engaged, as were their parents. For my money, Pyret is THE language for an intro to programming, almost regardless of age.
And I think you'll find that Gilad Bracha is a more informed critic of reliance on static type checking.