4 ms·

I've read The Pragmatic Programmer on a 10 hour flight and I fell asleep 2 or 3 times, because it was freaking boring. Either you already knew that the things

I've read The Pragmatic Programmer on a 10 hour flight and I fell asleep 2 or 3 times, because it was freaking boring. Either you already knew that the things it recommended were good ideas and were doing them, or you haven't yet learned why the things it recommended were good ideas. I know "soft skills" is a euphemism for a bunch of stuff that I'd rather not unpack here, but personally I do think learning good practices around how to write maintainable, testable code are actually, y'know, important and useful, even if they get communicated with icky horrible soft words instead of burly awesome hard math symbols. This means algorithms and math. If you say so. But the niche for heroic god-tier 100000000000000000000x rockstar wizard ninja gurus who roll their eyes at tiny puny baby-child beginners while channeling the heartbeat of the universe to derive the Perfect Algorithm™ is... pretty small, and getting smaller ever year. Working programmers don't -- or maybe shouldn't, but oops, that's a "soft skill"! -- actually re-invent all of CS from first principles on a daily basis. And there's really no level of programming you can run to anymore to escape. It's frameworks and libraries and gluing stuff together all the way down, even into the "bare" metal (which isn't so bare anymore, and is a rich programming environment in its own right). I mean, maybe you work someplace that routinely has to invent entire new fields of theoretical math just to describe the stuff you're building. But I've worked at a household-name place, and known plenty of other people who worked for other household-name places, and in my experience and their anecdotes that kind of stuff is vanishingly rare. Also, I'd be willing to bet almost anything that you didn't start out as a programmer by reading Turing's "On Computable Numbers" and going from there. You probably started out with an already-built, friendly programming environment in which you could slap things together to see what happened, and only later -- possibly years later -- started to dive into all these "fundamentals" that you now insist everyone learn up-front instead.

fixermark 8y ago
> It's frameworks and libraries and gluing stuff together all the way down, even into the "bare" metal (which isn't so bare anymore, and is a rich programming environment in its own right). + a lot. Even TensorFlow is driven by a Python API.
ryanar 8y ago
An excellent point. To corroborate it, there was a challenge issued by Jon Bentley to Don Knuth to write a program that Doug McIlroy would then critique. The program was to parse a file and count the frequencies of words, outputting a list of the frequencies sorted highest to lowest. Knuth wrote -everything- from first principles, custom file reading, parsing, the whole nine yards. At the end he had a 10 page WEB literate programming document that solved the problem. McIlroy, in his critique, wrote a six line shell script to do the same thing tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn | sed ${1}q McIlroy pointed out that by using generalized abstractions over small tasks, file reading, parsing, sorting, etc. you can write software that can be re-used and solve the business need in a reasonable timeframe. If we did everything from first principles then nothing would get done. The merits of McIlroys argument in the context of Bentley's challenge are another matter, but I believe that his point is a good one in the general case, we are hired to build software that meets business needs, and most of the time that does -not- mean hand-crafting purpose-built data structures and algorithms. For more on the Knuth, McIlroy story: https://franklinchen.com/blog/2011/12/08/revisiting-knuth-and-mcilroys-word-count-programs/ https://franklinchen.com/blog/2011/12/08/revisiting-knuth-an...

fixermark 8y ago

> It's frameworks and libraries and gluing stuff together all the way down, even into the "bare" metal (which isn't so bare anymore, and is a rich programming environment in its own right). + a lot. Even TensorFlow is driven by a Python API.

ryanar 8y ago

An excellent point. To corroborate it, there was a challenge issued by Jon Bentley to Don Knuth to write a program that Doug McIlroy would then critique. The program was to parse a file and count the frequencies of words, outputting a list of the frequencies sorted highest to lowest. Knuth wrote -everything- from first principles, custom file reading, parsing, the whole nine yards. At the end he had a 10 page WEB literate programming document that solved the problem. McIlroy, in his critique, wrote a six line shell script to do the same thing tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn | sed ${1}q McIlroy pointed out that by using generalized abstractions over small tasks, file reading, parsing, sorting, etc. you can write software that can be re-used and solve the business need in a reasonable timeframe. If we did everything from first principles then nothing would get done. The merits of McIlroys argument in the context of Bentley's challenge are another matter, but I believe that his point is a good one in the general case, we are hired to build software that meets business needs, and most of the time that does -not- mean hand-crafting purpose-built data structures and algorithms. For more on the Knuth, McIlroy story: https://franklinchen.com/blog/2011/12/08/revisiting-knuth-and-mcilroys-word-count-programs/ https://franklinchen.com/blog/2011/12/08/revisiting-knuth-an...