Developers should Learn Why not just Memorize What
I have gotten a few emails asking why I read so many books. Simply put, I read books to learn about all the things the people who are much smarter than me recommend I do.
The one thing I learned in college is that if I wanted an A, I needed to work for it. I was not naturally smart like some of my classmates were. I am also horrible at memorization, so I had to learn why something was done and not just the formula to accomplish the task at hand.
I also learned that the more I learned the less I knew. Programming and architecture require a lot of knowledge, much more than my little brain can hold. So I read and what keep is the why something is done the way it is done. I also do my best to remember a reference to the location of what I read (which book I read it in).
This has burned me when memorization was a preferred skill over experience. I was in an interview once that had gone on for a pretty long time. Nothing technical was asked for hours. Then one of the interviewers came in and started asking very simple yet broad technical questions. The random memorization type. You know, define an assembly, list the new features in .NET 4.0, how many toes does a monkey have. Those type of questions.
My gears didn't switch, instead they locked. I could not recall the lists of things they wanted me to recall. I could actually remember the page number and the page layout the answer to one of the questions was on, but could not remember the content of the page.
It worked out for the best, the company I was interviewing with has seemed to have lost its direction. It also seemed they were interested in a road warrior, which I am no longer willing to be.
I don't feel bad about doing poorly in interviews that are just a bunch of random questions looked up by one of the interviewers 2 hours before the interview. I expect to be asked about my resume and grilled about what I have claimed to do. In the interview above not one question was about anything on my resume that day. It was one of the weirdest ones I have been on. I guess the point is, preferring memorization over understanding why something is done, does have its place in the industry, but I am not interested in those places.
I recently attended a presentation where one of the topics was the death of apprenticeship. The line of thought is that with all knowledge now available at ones finger tips, the only skill you need is to know how to use Google or any other electronic data resource. Experience no longer counts for anything.
Although I agree with this line of thought for certain jobs, I do not agree with it for Software Development (and many other professions that I am not qualified to talk about). Although I know there are a lot of developers that would disagree. There are a lot of them out there that believe all you need is Google and other people's code to succeed at developing software. Like I said above, I do agree with this line of thought, but with respect to learning the other's experience and understanding behind those code snippets they so kindly post. Just using the end result without understanding why you are using it, will come back to bite you later.
I have attended several technical review meetings over the years and sometimes I am simply left speechless when I hear something like "Now that we have the application deployed we need to talk about XXX". You can put security, logging, error handling, performance, testing, etc. in XXX. They collected all the pieces of what it takes to build the application, but no one on the team had any architectural experience to put them in place in the correct order. When I asked how they could be so far off base, I have been told … They see architecture as extra work that gets in the way of real progress.
My response is they simply don't have the experience on the team to know better. For those that have never seen architecture done correctly, they don't believe it is worth the effort. Most of those environments give a team of inexperienced individuals the responsibility to execute the architecture business cycle and they simply generate a whole lot of useless artifacts that are later viewed as a waste of time. They learned what artifacts to produce but never learn why you produce them and what the goal of producing them is. They were simply a check box on a list of "this is what is produced during the architecture process".
To me having information is knowledge, knowing what to do with the knowledge is wisdom. I see a whole lot of knowledge these days, but very little wisdom. As long as the shortcut to the end result continues to be taken, our industry is going to continue to produce garbage, but I guess that is not all bad for those of us who make a living cleaning up garbage.
The one thing I learned in college is that if I wanted an A, I needed to work for it. I was not naturally smart like some of my classmates were. I am also horrible at memorization, so I had to learn why something was done and not just the formula to accomplish the task at hand.
I also learned that the more I learned the less I knew. Programming and architecture require a lot of knowledge, much more than my little brain can hold. So I read and what keep is the why something is done the way it is done. I also do my best to remember a reference to the location of what I read (which book I read it in).
This has burned me when memorization was a preferred skill over experience. I was in an interview once that had gone on for a pretty long time. Nothing technical was asked for hours. Then one of the interviewers came in and started asking very simple yet broad technical questions. The random memorization type. You know, define an assembly, list the new features in .NET 4.0, how many toes does a monkey have. Those type of questions.
My gears didn't switch, instead they locked. I could not recall the lists of things they wanted me to recall. I could actually remember the page number and the page layout the answer to one of the questions was on, but could not remember the content of the page.
It worked out for the best, the company I was interviewing with has seemed to have lost its direction. It also seemed they were interested in a road warrior, which I am no longer willing to be.
I don't feel bad about doing poorly in interviews that are just a bunch of random questions looked up by one of the interviewers 2 hours before the interview. I expect to be asked about my resume and grilled about what I have claimed to do. In the interview above not one question was about anything on my resume that day. It was one of the weirdest ones I have been on. I guess the point is, preferring memorization over understanding why something is done, does have its place in the industry, but I am not interested in those places.
I recently attended a presentation where one of the topics was the death of apprenticeship. The line of thought is that with all knowledge now available at ones finger tips, the only skill you need is to know how to use Google or any other electronic data resource. Experience no longer counts for anything.
Although I agree with this line of thought for certain jobs, I do not agree with it for Software Development (and many other professions that I am not qualified to talk about). Although I know there are a lot of developers that would disagree. There are a lot of them out there that believe all you need is Google and other people's code to succeed at developing software. Like I said above, I do agree with this line of thought, but with respect to learning the other's experience and understanding behind those code snippets they so kindly post. Just using the end result without understanding why you are using it, will come back to bite you later.
I have attended several technical review meetings over the years and sometimes I am simply left speechless when I hear something like "Now that we have the application deployed we need to talk about XXX". You can put security, logging, error handling, performance, testing, etc. in XXX. They collected all the pieces of what it takes to build the application, but no one on the team had any architectural experience to put them in place in the correct order. When I asked how they could be so far off base, I have been told … They see architecture as extra work that gets in the way of real progress.
My response is they simply don't have the experience on the team to know better. For those that have never seen architecture done correctly, they don't believe it is worth the effort. Most of those environments give a team of inexperienced individuals the responsibility to execute the architecture business cycle and they simply generate a whole lot of useless artifacts that are later viewed as a waste of time. They learned what artifacts to produce but never learn why you produce them and what the goal of producing them is. They were simply a check box on a list of "this is what is produced during the architecture process".
To me having information is knowledge, knowing what to do with the knowledge is wisdom. I see a whole lot of knowledge these days, but very little wisdom. As long as the shortcut to the end result continues to be taken, our industry is going to continue to produce garbage, but I guess that is not all bad for those of us who make a living cleaning up garbage.
posted by tadanderson at 5:21 PM
0 Comments:
Post a Comment
<< Home