5 ms·

The core idea of the article is valid, but the wording is off. It's not about frameworks. There are two types of knowledge you can get in IT. Fundamental knowl

The core idea of the article is valid, but the wording is off. It's not about frameworks. There are two types of knowledge you can get in IT. Fundamental knowledge that transfers across domains and trivia. Problems with trivia: - Just like the article pointed out, it often gets outdated. - If the system you work with is well-designed, you don't need to know much trivia about it. - Fundamental knowledge allows you to derive more knowledge. Trivia is gained through rote learning and doesn't allow you to derive anything. - Trivia hinders interoperability and innovation. Unfortunately, most IT people love their trivia. They brag about knowing trivia. They separate in-group from the out-group by trivia and use that as hiring criteria. Finally, they proudly design systems that require you to learn new trivia. It's a giant waste of society's resources, but it also creates job security and allows some people get much larger salaries that they would otherwise. As far as I'm concerned, eliminating the need for knowing trivia about their systems is one of the primary responsibilities of a good software engineer, regardless of specifics of what they do. "Stop designing frameworks" is my advice. PS: Design patterns are also trivia. Peter Norvig gad a great set of slides on that. http://www.norvig.com/design-patterns/ http://www.norvig.com/design-patterns/

WhompingWindows 8y ago
What are some examples of that trivia?
- gambler 8y ago
  "To concatenate a Stream of Strings, call .collect(Collectors.joining())" "References to missing variables will be sent to the output stream, unless you use quiet reference notation" "You need jetty-web.xml and web.xml files in your JAR to register a servlet with the server" Language/file syntax of any sort. Names of things (classes, methods, functions, commands, parameters, magic variables, magic files). Steps you need to take to get something running. Isn't it ridiculous that some people are considered "experts" simply because they memorized a bunch of poorly documented names for a piece of software?
bellweather49 8y ago
Thankyou for this. I've often thought of learning in terms of "learning trivia" vs. "understanding concepts", but had never applied the word "trivia" to learning programming facts. I'm a hobbyist, rather than a professional, so I learn what I want, while aiming for comprehensive knowledge. Over time, I have become bored with learning frameworks and libraries, and have become much more interested in learning standards. The phrase I have ringing in my head is "don't learn APIs", which is rather like your "don't learn trivia", but I think "trivia" captures the essence of it better. To be a little more nuanced about it, I think the thing to avoid is learning APIs for things that are not either standards, or defacto standards of long-standing. Of course, learning APIs is necessary, but everytime I find myself wading through API documentation, I stop and ask myself whether it will still be relevant in a few years time; often the API will change, or even worse (I'm thinking of React here), the whole ecosystem will probably have disappeared in 5 years time. This talk[1] makes a similar case. Obviously, if someone wanted to pay me to learn and use React, that would be a different matter. [1]https://www.youtube.com/watch?v=k7n2xnOiWI8 https://www.youtube.com/watch?v=k7n2xnOiWI8

WhompingWindows 8y ago

What are some examples of that trivia?

gambler 8y ago
"To concatenate a Stream of Strings, call .collect(Collectors.joining())" "References to missing variables will be sent to the output stream, unless you use quiet reference notation" "You need jetty-web.xml and web.xml files in your JAR to register a servlet with the server" Language/file syntax of any sort. Names of things (classes, methods, functions, commands, parameters, magic variables, magic files). Steps you need to take to get something running. Isn't it ridiculous that some people are considered "experts" simply because they memorized a bunch of poorly documented names for a piece of software?

bellweather49 8y ago

Thankyou for this. I've often thought of learning in terms of "learning trivia" vs. "understanding concepts", but had never applied the word "trivia" to learning programming facts. I'm a hobbyist, rather than a professional, so I learn what I want, while aiming for comprehensive knowledge. Over time, I have become bored with learning frameworks and libraries, and have become much more interested in learning standards. The phrase I have ringing in my head is "don't learn APIs", which is rather like your "don't learn trivia", but I think "trivia" captures the essence of it better. To be a little more nuanced about it, I think the thing to avoid is learning APIs for things that are not either standards, or defacto standards of long-standing. Of course, learning APIs is necessary, but everytime I find myself wading through API documentation, I stop and ask myself whether it will still be relevant in a few years time; often the API will change, or even worse (I'm thinking of React here), the whole ecosystem will probably have disappeared in 5 years time. This talk[1] makes a similar case. Obviously, if someone wanted to pay me to learn and use React, that would be a different matter. [1]https://www.youtube.com/watch?v=k7n2xnOiWI8 https://www.youtube.com/watch?v=k7n2xnOiWI8