|
I know how this works, but yeah I am the lazy one and never bothered to even try to remember those values.
Seems like his cool guy. Maybe we would paste some code images on CP
No more Mister Nice Guy... >: |
|
|
|
|
|
Member 7989122 wrote: You won't find many persons like that in the software houses of today! I think you may mean there is little need for that level of intimacy with the OS these days. There are certainly a large group of people have a really deep knowledge of their chosen technology.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Sure - you can't expect everyone to know all the bottom level of all sorts of technology. Like, I know nothing of the theory of transistor technology - I can explain how an instruction code is decoded into signals to each logic unit of the CPU, but nothing below that.
But: Many years ago, I learned one rule: As a minimum, understand what's going on (at least) one level below the one you're working at yourself. When you ask for a service, you should always understand what needs to be done to provide that service, even if you don't have to implement it. Maybe the implementation you make use of do the details different from what you think, but you should know how the task could be done. You need to know that to make the right service request.
The opposite approach is the "just in time" knowledge. When a question is raised, google the answer (or look it up in Wikipedia), read the answer out loud, and forget it. No need to learn or understand; you can look it up a second time if you need it a second time.
My impression is that modern IT education covers so many sub-fields, has such a broad scope, that there is never the time to learn anything that's "not necessary" to know. You learn what to do, but not why that is the right thing to do. Lots of the newly-educated people have learned a lot of things that we never heard about when I was a student. Much too often, difficult problems are solved more or less by trial and error, and when it "works" (sort of), they believe they have found the "right" solution. Until I, or some other oldguy, explains to them what really happens when an external interrupt signal is processed. Or how overloading is realized. Or why most OO-systems are incapable of redefining a method at the instance level. Or ...
Even expertice can be skin deep. While I think Google and Wikipedia are great tools, they do corroborate the "Just in time" idea, rather than the "deep level of understanding" idea. Too often, broad but shallow knowledge (which certainly has its merits - but different ones!) are mistaken for being deep knowledge.
|
|
|
|
|
The irony to that is, when I write apps in FlowSharpCode, yeah, there's code behind the images, but it's actually the images (meaning shapes) that are more important than the code, as they organization of the shapes describes what's actually important about the code -- the flow, loops, decisions, etc.
So it's something I've been wondering about -- will people be annoyed when I write articles about FlowSharpCode which are screenshots of the shapes and their code-behind!
Marc
|
|
|
|
|
"References to CLstCtrl" and "BACON".
No article is perfect without them.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
And no reference to the welsh rugby team either...(or sheep!)
|
|
|
|
|