ericssmith

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.

"Je n’avais pas besoin de cette hypothèse-là." -- Pierre-Simon Laplace

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.