How long will it take me to read the Intel manuals?
How long will it take me to read the Intel manuals?
I dont have that many spare hours in the day because at present I work on an assembly line screwing caps on tubes of toothpaste. The goal I've set for myself is to wake 4 hours prior to work and devote 3 hours to consuming the Intel AMD64 documentation (3 hours because it takes me one hour to eat breakfast and get to work on the train). Assuming 3 hours a day and a skilled mnemonist, how long will it take me to commit the entire volume to memory? Is one year a sufficient timeframe? My immediete goal is to work as a kind of traveling consultant helping out teams of software engineers when they cannot break through their confusion.
-
Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: How long will it take me to read the Intel manuals?
You need to be an excellent developer and software engineer of yourself to be a good consultant. Committing a processor manual to photographic memory serves little purpose to that extent. In fact, most of us just read through 3A once and remember the general features, then only use it as a reference ever after. There is little use of that book in actual production work.
Becoming an excellent software developer requires many years of practice, and learning facts at home or taking classes only teaches you what the tools are, not how to use them.
Becoming an excellent software developer requires many years of practice, and learning facts at home or taking classes only teaches you what the tools are, not how to use them.
Re: How long will it take me to read the Intel manuals?
+1 to Combuster.
Just knowing the Intel Manuals will help you nothing in most areas. There are very few project teams that actually have to access Intel CPU internals. Even fewer would be willing to pay someone to to the job that a book on their desk (or a PDF on their desktop) could do just as well. Those are areas where a university degree in CS is more or less a given requirement, because we're talking compiler or OS development here, and that takes quite some theoretical background, beyond the mere technicalities of a given CPU architecture.
Actually, roughly remembering facts just well enough to know how and where to look up the details is more valuable than committing lots of information to memory, since chances are you won't need most of the information ever again.
That is where "experience" comes into the picture. Experienced developers have seen problems just like this one and can remember how they - or others - solved it. Or they can remember enough circumstantial information to Google for it real quick. Or they have the experience to put the problem into words so that their question on stackoverflow.com (or osdev.org, or wherever) is answered quickly and competently by others. (*)
When HR people are looking at your resume, they are looking for experience, for solved problems. That could be problems presented to you at university courses, or problems you encountered in hobby projects, or problems you encountered in previous employments.
What they are not looking for is books committed to memory.
Sorry.
PS: (*) For example, I know less than one quarter of the C++ standard library by heart. I can't remember 90% of the contents of Scott Meyers' "Effective C++" books. But I know that there is <algorithm> providing functionality for STL containers, that vector<bool> is deprecated and that you shouldn't throw exceptions in destructors. All the rest, I can look up as needed.
Or take LaTeX, something I started dabbling in only recently. I don't know half the parameters for the hyperref package, but I know that this package can generate an index structure for your PDF. I don't know the names of the parameters for the enumitem package, but I know I can use it to format item lists. I can look up whatever I need, because I have a rough map in mind that allows me to find information instead of merely looking for it. That is much more valuable than having "The LaTeX Companion" committed to memory - because it didn't take as long, and left me with time and brain capacity to do other things as well.
Just knowing the Intel Manuals will help you nothing in most areas. There are very few project teams that actually have to access Intel CPU internals. Even fewer would be willing to pay someone to to the job that a book on their desk (or a PDF on their desktop) could do just as well. Those are areas where a university degree in CS is more or less a given requirement, because we're talking compiler or OS development here, and that takes quite some theoretical background, beyond the mere technicalities of a given CPU architecture.
Actually, roughly remembering facts just well enough to know how and where to look up the details is more valuable than committing lots of information to memory, since chances are you won't need most of the information ever again.
That is where "experience" comes into the picture. Experienced developers have seen problems just like this one and can remember how they - or others - solved it. Or they can remember enough circumstantial information to Google for it real quick. Or they have the experience to put the problem into words so that their question on stackoverflow.com (or osdev.org, or wherever) is answered quickly and competently by others. (*)
When HR people are looking at your resume, they are looking for experience, for solved problems. That could be problems presented to you at university courses, or problems you encountered in hobby projects, or problems you encountered in previous employments.
What they are not looking for is books committed to memory.
Sorry.
PS: (*) For example, I know less than one quarter of the C++ standard library by heart. I can't remember 90% of the contents of Scott Meyers' "Effective C++" books. But I know that there is <algorithm> providing functionality for STL containers, that vector<bool> is deprecated and that you shouldn't throw exceptions in destructors. All the rest, I can look up as needed.
Or take LaTeX, something I started dabbling in only recently. I don't know half the parameters for the hyperref package, but I know that this package can generate an index structure for your PDF. I don't know the names of the parameters for the enumitem package, but I know I can use it to format item lists. I can look up whatever I need, because I have a rough map in mind that allows me to find information instead of merely looking for it. That is much more valuable than having "The LaTeX Companion" committed to memory - because it didn't take as long, and left me with time and brain capacity to do other things as well.
Every good solution is obvious once you've found it.
Re: How long will it take me to read the Intel manuals?
Does that mean a gold badge on stackoverflow or an uber reputation on www.codeproject.com will buy you some cred when applying for a job as a software developer?Solar wrote:
That is where "experience" comes into the picture. Experienced developers have seen problems just like this one and can remember how they - or others - solved it. Or they can remember enough circumstantial information to Google for it real quick. Or they have the experience to put the problem into words so that their question on stackoverflow.com (or osdev.org, or wherever) is answered quickly and competently by others. (*)
Re: How long will it take me to read the Intel manuals?
Absolutely. I value my ability to understand assembler-code I wrote 10-15 years ago more than my ability to remember "facts".Solar wrote:Actually, roughly remembering facts just well enough to know how and where to look up the details is more valuable than committing lots of information to memory, since chances are you won't need most of the information ever again.
Re: How long will it take me to read the Intel manuals?
Don't laugh. My SO account was opened only after I applied for my current job, but when I came in for the first interview, they did know of my OSDev.org postcount...bonch wrote:Does that mean a gold badge on stackoverflow or an uber reputation on http://www.codeproject.com will buy you some cred when applying for a job as a software developer?
Every good solution is obvious once you've found it.
Re: How long will it take me to read the Intel manuals?
Nice. And I was only 25% joking. I've often thought that various SO gurus (people like John Skeet etc) could just about name their own price to employers based almost purely on their SO rep, and wondered about how strange that is. Well, I should't say it's "strange", it's not strange at all but it is a new phenomenon.Solar wrote:Don't laugh. My SO account was opened only after I applied for my current job, but when I came in for the first interview, they did know of my OSDev.org postcount...bonch wrote:Does that mean a gold badge on stackoverflow or an uber reputation on http://www.codeproject.com will buy you some cred when applying for a job as a software developer?
I think what I need to do is wait until I get a bit (a lot) smarter and then "rebirth" myself on SO. Some of my old questions on there are so moronic that I'd be refused work as a janitor if people were aware that I asked them.
Re: How long will it take me to read the Intel manuals?
Fortunately you're not correct. There's no need to hide from your past. Being part of a community, asking questions in a way that gets the correct answer, then later giving back as you can, improving your knowledge by knowing that other people know better than you, perseverance, etc. These are the things valued in an engineer. Everyone starts with absolutely zero knowledge. It's what happens after that that counts.I think what I need to do is wait until I get a bit (a lot) smarter and then "rebirth" myself on SO. Some of my old questions on there are so moronic that I'd be refused work as a janitor if people were aware that I asked them.
If a trainstation is where trains stop, what is a workstation ?
Re: How long will it take me to read the Intel manuals?
You could start with the 80386 Manual, which is not so big. About everything in it is still valid for newer processors (of course unless you're developing for long mode) and you can pile new knowledge on top of it.