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.
Thursday, June 28, 2007
Is it good to be perfect?
So over on raganwald there was an interesting quote pulled from an article by Steve Yegge that I believe attempts to point out just how much he loves working at Google. The article goes on to essentially point out that Google seems to do everything right in terms of software development. The appropriate levels of documentation are always available, the correct unit testing and other information is always completed and as blasphemous as it may sound developers are given a bit of free choice and input into what it is that they are actually doing/developing. THIS sounds a little bit like a Utopian society of developers but is it really? Steve attempts to point out that the way Google has done it is part of a discipline he states:
"I don't think you can get that kind of software-engineering discipline without doing it right from the start, and creating a culture that enforces and reinforces that discipline as the organization grows."
While this may be true is it the reality? This statement would seem to exclude all those companies that didn't start out in the way prescribed. Does that make sense?
I think what the quote is missing is that most companies are in the software business because they have to be, not because that is their main focus or even their main business driver. Take for instance BigCo. BigCo has a range of products that it offers to people. The products that BigCo. offers are what drives its business. Now it just so happens that the products that BigCo. offers are sold through the web and that BigCo. also has a fairly large IT department managing all the systems that deal with the product that it sells. The process that BigCo. follows grew out of the product process not out of a software development process. Does that fact make what BigCo. does for software development inherently flawed - or better yet would it make the avg. software developer mad? I am going to guess that like most things some portion of the way software is developed would and some would not. In the end however I would argue that it is still possible for BigCo. to come to a similar nirvana as Steve has found in working for Google.
Companies grow and they change a great deal in their life times. Alot like humans grow from children into adults hopefully learning along the way. This learning process can be long and it can be arduous but it can be done. What I would argue that the change from child to adult software development requires is good people that are willing to help BigCo. move towards a vision of nirvana. I would argue that being the 'Perfect' development shop from the start may leave no room to grow, to change, to expand the horizons and most importantly it will lack the people with a questioning eye for how the process runs. Without the questions the process, no matter how good it is, may stagnate and start to blemish or tarnish and when it does - those developers living in nirvana won't know how to fix it because they have been too happy for too long.
"I don't think you can get that kind of software-engineering discipline without doing it right from the start, and creating a culture that enforces and reinforces that discipline as the organization grows."
While this may be true is it the reality? This statement would seem to exclude all those companies that didn't start out in the way prescribed. Does that make sense?
I think what the quote is missing is that most companies are in the software business because they have to be, not because that is their main focus or even their main business driver. Take for instance BigCo. BigCo has a range of products that it offers to people. The products that BigCo. offers are what drives its business. Now it just so happens that the products that BigCo. offers are sold through the web and that BigCo. also has a fairly large IT department managing all the systems that deal with the product that it sells. The process that BigCo. follows grew out of the product process not out of a software development process. Does that fact make what BigCo. does for software development inherently flawed - or better yet would it make the avg. software developer mad? I am going to guess that like most things some portion of the way software is developed would and some would not. In the end however I would argue that it is still possible for BigCo. to come to a similar nirvana as Steve has found in working for Google.
Companies grow and they change a great deal in their life times. Alot like humans grow from children into adults hopefully learning along the way. This learning process can be long and it can be arduous but it can be done. What I would argue that the change from child to adult software development requires is good people that are willing to help BigCo. move towards a vision of nirvana. I would argue that being the 'Perfect' development shop from the start may leave no room to grow, to change, to expand the horizons and most importantly it will lack the people with a questioning eye for how the process runs. Without the questions the process, no matter how good it is, may stagnate and start to blemish or tarnish and when it does - those developers living in nirvana won't know how to fix it because they have been too happy for too long.
Subscribe to:
Posts (Atom)
