WARNING: Generally off topic for a bit of praise
In my career as a programmer I have attempted to learn as much as I can from my mentors and my peers. I have learned a great deal from the people that I have worked with, things like:
1) Don't rely on a debugger, log what you need when you think you'll need it. This will treat you a great deal better then the debugger.
2) DSLs can be an important thing to think about when presented with certain types of problems.
3) Java script can be fun and informative if you use the 'right' tools.
4) Always question and be curious - it will serve you well in your travels
and finally
5) Don't burn the bridges that you build, it will come back to haunt you.
All in all I think that I have come a long long long way from where I started out in the work world. Also I think that I have a great deal of thanks to be paid to people that have helped me along the way. Which brings me to why I decided to make this post... one of the people that I have been working with, someone who has taught me a lot both in working with him as well as reading his blog postings has decided to move on and find himself a new position.
Raganwald has been a great mentor and colleague and has brought a great deal to the table for me but has decided to move on. I am personally sad that I will not get to interact with him on a semi-regular basis in the work world anymore. I have learned so much - and certainly feel that he has more to offer. He thinks out of the box - aiming to simplify and make programmers lives easier. At the same time that thinking is about solving the problems presented in a novel and efficient way. I wish him the best of luck in his travels - I hope that he knows he will be missed.
Friday, July 27, 2007
Thursday, July 5, 2007
Conjuntion junction meets Certification Specification
A post over here at Raganwald got me thinking the other day. The post was about certifications for programmers and got started by posing the situation where he posted his resume with a recruiter and got back a request asking him where he attended college. The post itself goes on to discuss certifications (ala getting a degree) as a means to attempt to discover if someone is capable of doing the job at hand or the job that they are being requested to do.
This same post goes on to point out that in some respects certifications may be of use, but that the certifications might be working on the wrong things in order to pick out a good programmer. This post was also picked up over at Enfranchised Mind where the writer attempts to point out how Raganwald may have missed the boat when he stated that his programmer certification test would consist mostly of understanding the different ways in which you can be measured as a programmer.
Personally I think they both gloss over the nits/grits of the issue. Raganwald is correct, IMHO, in saying that he thinks that in order to be a good programmer you need to understand what you are being measured with. If the objective measure is a ruler, then anyone can be a good programmer. If the objective measure is how many lines of code you write, then a bunch of monkeys can be good programmers. IF however your measure is how much code did you write that:
1) Solved the problem that you were presented with
2) Solved it in as few a number of lines of code as possible
3) While simultaneously not producing any (or at least as few as possible) bugs
Then the pool of people that you are talking about being able to do the job suddenly gets quite a bit smaller. The understanding of this is important and I believe that he is attempting to point out the importance of knowing what your measured with is one of the important points of being a programmer. More Specifically that his certification (at least a first level certification) would have the programmers he certifies understanding this point in depth and completely before he would let them loose on the world.
The other blog article seems to wander off into the weeds a little and points out some things in the Raganwald article the he takes deference to. Then wanders into a diatribe about Ocaml and static typing (possibly as a dig or as an attempt to point out that he is not a Blub programmer). I think the thing this second article gets right however is that learning what makes a good programmer is an ongoing process. That in general people are still trying to get a good handle on what a good programmer is, and how they work. Which begs the question again of what individuals are using to measure against.
The point that I think they both miss is the thing that it is hard to discern in an interview "What has your experience brought you above and beyond the basics that make you a good programmer for BigCo?" I think the question says it all - a good programmer for a given place. Each programmer will bring a different eye and a different experience to what they do. An older more seasoned programmer might be what you are looking for, but seasoned in what way? It is difficult at best to, in a 30 minute interview, understand what a singular person brings to the table - so does the certification help? Is it about what language you write in/know?
I would argue that it isn't about those things - its about what information you bring to the table, its about the "Learning" you have done over time. Its about the intangibles - the things that are DAMN near impossible to 'test' for that make you a good programmer. There are certainly some things that you aught to know (like how you are measured) - but there isn't anything that can test for your experience and certainly nothing that can test how your experience applies to how you program/solve problems. Your experience (like the second post points out with commentary about solving problems and how you solve them, buy vs. build decisions etc.) is what makes you a truly 'good' programmer. Book smarts and understanding need to be there, but beyond that is what counts.
This same post goes on to point out that in some respects certifications may be of use, but that the certifications might be working on the wrong things in order to pick out a good programmer. This post was also picked up over at Enfranchised Mind where the writer attempts to point out how Raganwald may have missed the boat when he stated that his programmer certification test would consist mostly of understanding the different ways in which you can be measured as a programmer.
Personally I think they both gloss over the nits/grits of the issue. Raganwald is correct, IMHO, in saying that he thinks that in order to be a good programmer you need to understand what you are being measured with. If the objective measure is a ruler, then anyone can be a good programmer. If the objective measure is how many lines of code you write, then a bunch of monkeys can be good programmers. IF however your measure is how much code did you write that:
1) Solved the problem that you were presented with
2) Solved it in as few a number of lines of code as possible
3) While simultaneously not producing any (or at least as few as possible) bugs
Then the pool of people that you are talking about being able to do the job suddenly gets quite a bit smaller. The understanding of this is important and I believe that he is attempting to point out the importance of knowing what your measured with is one of the important points of being a programmer. More Specifically that his certification (at least a first level certification) would have the programmers he certifies understanding this point in depth and completely before he would let them loose on the world.
The other blog article seems to wander off into the weeds a little and points out some things in the Raganwald article the he takes deference to. Then wanders into a diatribe about Ocaml and static typing (possibly as a dig or as an attempt to point out that he is not a Blub programmer). I think the thing this second article gets right however is that learning what makes a good programmer is an ongoing process. That in general people are still trying to get a good handle on what a good programmer is, and how they work. Which begs the question again of what individuals are using to measure against.
The point that I think they both miss is the thing that it is hard to discern in an interview "What has your experience brought you above and beyond the basics that make you a good programmer for BigCo?" I think the question says it all - a good programmer for a given place. Each programmer will bring a different eye and a different experience to what they do. An older more seasoned programmer might be what you are looking for, but seasoned in what way? It is difficult at best to, in a 30 minute interview, understand what a singular person brings to the table - so does the certification help? Is it about what language you write in/know?
I would argue that it isn't about those things - its about what information you bring to the table, its about the "Learning" you have done over time. Its about the intangibles - the things that are DAMN near impossible to 'test' for that make you a good programmer. There are certainly some things that you aught to know (like how you are measured) - but there isn't anything that can test for your experience and certainly nothing that can test how your experience applies to how you program/solve problems. Your experience (like the second post points out with commentary about solving problems and how you solve them, buy vs. build decisions etc.) is what makes you a truly 'good' programmer. Book smarts and understanding need to be there, but beyond that is what counts.
Subscribe to:
Posts (Atom)
