Something that I saw in two different posts recently got me thinking. The first post had to do with abbreviation and accidental complexity, the other was on Use and Reuse of code. The topics are intertwined and linked.
The commentary on Raganwald attempts to point out that just because something is brief it is not necessarily better and at the same time the reverse can also be true, that something verbose may not be easier to understand over all due to accidental complexity. Programming is about finding the balance between the two points. In other words the SNR (Signal to noise ratio) in ones code is an important factor. This leads to the second article on Use and Reuse of code.
I especially liked the commentary that Enfranchised Mind's Brian Hurt provided here, that the Use vs. Reuse of programming could be considered the Second Derivative of programming (remember back to all that calculus, the second derivative is acceleration). Stated in another way, that whats important in programming is the ability of a coder(s) to add new code faster and more efficiently in a constantly changing environment.
Why is this so important? What makes this idea of adding new code faster and more efficiently such an important topic to cover? Well, the reason that I have been finding it important lately wraps around to another fact of life - systems of things (programming software or otherwise) tend towards entropy and need attention to be held at their current state or improved in anyway. This plays out in the following fashion:
An existing system of code lends itself to doing certain things in certain ways. This way of doing things often represents the way in which the programmers 'thought' that certain bits of system code would be used in the short term. Those same programmers my have been forward thinking about needed changes or potential other uses but lets face it we are all not prognosticators and can not read the future. That being said at some point in the future the code is going to need to be modified to suffice some additional need. Now the question becomes how hard is it to suffice this new need given what currently exists. If it is hard to suffice this new need because the code is not structured in a way that allows its reuse then the coder is going to have to slow down and possibly implement a bunch of things she did not intend to. This temporary slowing down / refactoring is IMPORTANT as it makes the system more resilient to the 'new' types of changes being requested and it keeps people chugging along at top speed (or close to it).
Here is the practical take away, systems that do nothing but implement new stuff all the time and pay no attention to the things that pin them up (the pillars or underlying architecture) will eventually become so decrepit as to actually slow coders down when attempting to DO anything with the code. Refactoring is a necessity to keep people using and re-using code. It is the re-using that keeps the speed of implementing new things high and allows development to accelerate and succeed. The best case is to have accelerated (by re-using code) your development to the point at which it is lightning fast and hold it there devoting some percentage of energy to not decelerating from that really fast point.
Sunday, September 9, 2007
Friday, July 27, 2007
What I Learn(ed) from Others
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.
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.
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)
