|
So if your friend lived through hell and was able to tell about it, others should too? 
No more Mister Nice Guy... >: |
|
|
|
|
|
It earned him a job at with the computer manufacturer, when he decided that the Universty research center didn't pay him well enough...  He ended up as one of the two super-gurus in the OS development group, very highly respected.
Which gives me an excuse for telling another story about him: I once detected a reproducible bug that crashed the OS, which I reported to him. He pulled out his printout of the OS source code and sat for fifteen minutes flipping pages back and forth, mumbelign to himself. Then he grabbed a pen and wrote a couple numeric values into the printout. "OK, you'll have it fixed next time you upgrade your OS".
The numeric values where the fix. He didn't write down the fix in the mid-level language of the OS (sort of like plain C). With some experience, you know which machine instructions the compiler will generate, but he didn't write down the assembly instructions. He wrote down the numeric codes for those machine instructions, so that he could poke them directly into the kernel memory of his development machine, while it was running, to verify that they had the desired effect.
You won't find many persons like that in the software houses of today!
|
|
|
|
|
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!)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
