Sorry about the quiet period - it has been a very busy few months for me personally. Trying to understand and define what architecture is for me and the company I work for as well as taking 2 weeks vacation to sunshine filled areas. I have a few posts coming - the first one was just posted.
- A post continuing on the idea of architecture individuals being involved in some day to day programming (or at least having a task or two to accomplish for the programmers/infrastructure folk)
- A post about where I am right now and looking for potential guidance - basically a brain dump of my current thinking
- A post on attempting to ingrain security and testing into what programmers do from day to day
At least these are the ideas bouncing around in my head.
Tuesday, July 8, 2008
Interviews and the New Hire
There has been a lot of posting in the past about what peoples favorite interview question, problem, poser, situation are. Some have even gone so far as to offer descriptions and tips of what to do if you are looking for jobs using head hunters, or provide guidance if you are personally heading to an interview with Google. All of these articles are focused on attempting to discover, in advance, if the person that you are contemplating bring into your organization, startup, Big Co, team or what have you has the chops to do the work. Or if you are like most programmers the new hire is of your caliber or better (although in most cases programmers are not about hiring someone who could possibly show them up which is a short coming in most programmers).
So I wanted to offer an alternative to this point of view. The point of view I am talking about is that all the 'discovery' in hiring someone has to be done before they are made an offer to work for your company. Specifically I wanted to float the idea that the first 90 days (which in most larger companies is the 'trial' period) the time in which the company will evaluate you overall, hopefully spend time hand holding you to help you find your way around the Big Co. hallways also be used to help you determine if the person has the skills needed to do the job at hand.
How exactly can you use this first 90 days to you advantage when attempting to help determine if a new hire has the chops to do the job? I think the single biggest way that this can be accomplished is to prevent new hires from being able to commit code directly to the source tree in that first 90 days. Big Co. or your company should look at the new hires as being still 80% unknowns. There is no telling if the new hire will be overly complex in their code, not follow the company standards, or just plain suck.
I have personally run into the "just plain suck" situation when interviewing people - I personally interviewed an individual that seemed perfectly good on the surface. In the interview he had all the right technical answers - but when it came to actually implementing something all the implementations were mostly done but never complete and they were always buggy and HE WOULD ALWAYS COMMIT THEM to the source tree - which would of course break the build for everyone else. Eventually we had to revoke his commit privilege which lead directly to his quiting.
So here I am saying that while the company decides if you are a good working person - the developers should also be attempting to decide if you can really do the things you said you could do in an interview. For the first 90 days new hires should have a senior shadow - and they should NOT have commit privilege. They should be forced into submitting patches to the code through their company programming mentor.
This has a few benefits:
1) It forces a peer review of the code before it gets into the source tree allowing for a greater discussion about solutions, the why and how of what the programmer new hire has done.
2) It gives the Big Co. programmers the ability to essentially have another way of evaluating the new hire for ability and skill and to really validate if they are a fit.
3) Because in the first 90 days most folk can be fired for almost no provocation it is easier to dump someone who might be a half performer - or might not be the programmer you thought they were before they get ingrained and are near impossible to get rid of.
I know in the end that I would personally have a hard time with this idea myself - but I think I could live with this over taking a test, or other challenge in an attempt to prove what I can do. Just let me PROVE it for real - let me live or die by my own abilities. Both for the company and for myself... I think it could make the whole hiring process better.
So I wanted to offer an alternative to this point of view. The point of view I am talking about is that all the 'discovery' in hiring someone has to be done before they are made an offer to work for your company. Specifically I wanted to float the idea that the first 90 days (which in most larger companies is the 'trial' period) the time in which the company will evaluate you overall, hopefully spend time hand holding you to help you find your way around the Big Co. hallways also be used to help you determine if the person has the skills needed to do the job at hand.
How exactly can you use this first 90 days to you advantage when attempting to help determine if a new hire has the chops to do the job? I think the single biggest way that this can be accomplished is to prevent new hires from being able to commit code directly to the source tree in that first 90 days. Big Co. or your company should look at the new hires as being still 80% unknowns. There is no telling if the new hire will be overly complex in their code, not follow the company standards, or just plain suck.
I have personally run into the "just plain suck" situation when interviewing people - I personally interviewed an individual that seemed perfectly good on the surface. In the interview he had all the right technical answers - but when it came to actually implementing something all the implementations were mostly done but never complete and they were always buggy and HE WOULD ALWAYS COMMIT THEM to the source tree - which would of course break the build for everyone else. Eventually we had to revoke his commit privilege which lead directly to his quiting.
So here I am saying that while the company decides if you are a good working person - the developers should also be attempting to decide if you can really do the things you said you could do in an interview. For the first 90 days new hires should have a senior shadow - and they should NOT have commit privilege. They should be forced into submitting patches to the code through their company programming mentor.
This has a few benefits:
1) It forces a peer review of the code before it gets into the source tree allowing for a greater discussion about solutions, the why and how of what the programmer new hire has done.
2) It gives the Big Co. programmers the ability to essentially have another way of evaluating the new hire for ability and skill and to really validate if they are a fit.
3) Because in the first 90 days most folk can be fired for almost no provocation it is easier to dump someone who might be a half performer - or might not be the programmer you thought they were before they get ingrained and are near impossible to get rid of.
I know in the end that I would personally have a hard time with this idea myself - but I think I could live with this over taking a test, or other challenge in an attempt to prove what I can do. Just let me PROVE it for real - let me live or die by my own abilities. Both for the company and for myself... I think it could make the whole hiring process better.
Wednesday, May 14, 2008
Over complication?
I was reading one of the links that I get as RSS sent from Ragawald today about JSR-308 (What hath java wrought). This JSR describes some additional annotation on types that would extend the java type system allowing the compiler to do some more static checking work for me. There was a further breakdown explanation that was linked off the "What hath java wrought" article that is also worth reading for a good background on what this JSR could translate into. The additional write up is on Wide Awake Developers titled When Should You Jump? JSR 308. That's When.
Dynamic vs. Static
SO - I took a little dive down The Rabbit Hole, as I am apt to do, and followed a bunch of links on JSR-308. To be perfectly honest I am greatly disturbed by the information that I found. There has been a great deal of discussion about Dynamic languages, static languages and languages that are mostly static taking on some of the dynamic language goodnesses (or vise versa). Both sides (static and dynamic) have some relativly cogent arguments about why their thing-a-ma-gigger should be the one that means the most to the most programmers. Personally, as I have stated in the past, I am a "use the best tool for the job" type of person. Not only that, but I tend to try to bring in the stylistic flavor of other languages into the language I am using at the time, often mixing styles and metaphores as I go. Both arguments are powerful and at the same time equally pointless in the face of just being simple and getting done what you need to get done.
So, in terms of the JSR specifically, let me say that I am disappointed because the JSR I don't think is bringing anything of intrinsic value to the java language. This may be because I am looking for inherntly simple things or it may just be that I am personally a simpleton but lets assume that I give / gave myself the benefit of the doubt in this case. The title of the JSR-308 says the following:
"JSR 308, “Annotations on Java Types”, enriches the Java annotation system"
which I will admit on the surface seems simple, but it SOOOOO very much implies so much more. This JSR would allow the common coder to add annotations on java types and even further would allow the common coder to supply an annotation to a generic type as well. Some people would consider this to be progress... I am personally not so sure. Take the following example shamlessly pilfered from the "Wide Awake Developers" site:
void marshal(@Readonly Object jaxbElement, @Mutable Writer writer) @Readonly { ... }
Can someone please explain to me what this line would mean to some other class in my code? Better yet can someone please explain what are the potential outcomes of having a line like this in my code in an effort to "improve" my overall codebase?
If I had to guess someone can probably explain to me that the @Readonly is telling me that jaxbElement will not change in the method context. They can tell me that @Mutable is telling me that the 'writer' variable will change in the method context and that the second @Readonly is telling me that the method itself can only be called by something else that is also marked as @Readonly. Holy CRAP is that an amazing amount to remember about a single method.
Now I can hear a bunch of people sputtering that this feature would eventually find its way into being managed by the IDE's we may all use and love. I personally say that even if it does, that the value introduced by these new annotations is/will be lost on most people.
K.I.S.S.
One of the first things that I learned in programming and IT in general is that one should always keep a level head and try to look for the simple explanations and simple ways of doing something first. Keep It Simple Stupid is what I was always told. I came to understand that for the most part this old adage holds true. Granted that there are times where it is not always possible to do, maybe it is a particularly hard algorithm that needs implementing or other such item - but even in those cases attempting to be as straight forward as possible will help the person that follows you up in attempting to maintain and support the code. The addition of these new type annotations I do not think is in the vein of KISS. I think that this new JSR is about attempting to solve an ever smaller set of 'potential' coding issues (bad nulls, modifying variables you didn't intend and the like). The value proposition I just don't feel is there.
Specifically I think that this JSR is heading in the wrong direction. While most newer languages these days are heading in the direction of being more dynamic, more human readable and human understandable - this annotation JSR moves java in the other direction. We all know programming is hard but do we really need to make it even more so with something like this? This JSR raises the barrier to understanding what the code is doing in my opinion, lowering the overall understanding of java programmers of how their system works. Keep in mind that we have some other already complex things to solve... things like understanding multithreading and keywords like volatile better, maybe even adding some better multicore-multithreading support into the language... instead and to my dismay we as a community are out there attempting to solve a little niche of a problem. Granted the types of problems that this can solve are plenty hard to find and debug - but for an experienced programmer they are a small amount of an overall codebase.
SOOOO... How does one interpret...
Think about the interpretation of the example line I provided. I once said programming and being intuitive was all about memory / context - the idea of being able to hold in active memory about 7 +- 2 things, if I have to hold onto MORE then 7 items just to interpret what a singular statement is attempting to do and not even a statement per se. but a method declaration - I believe that I have bastardized the language. Why work to make it so hard for someone to just "Grok" what is being done that it is not worth the time it may take to learn to use the new feature. I would venture to say that it may be so hard to use this potential new feature 'correctly' that most people will just skip it altogether, being intent on what they know and understand. It will take the avg. person so long to make good use of the new feature that the language may be long dead before someone really makes it part of the main stream of development in java.
Should people start to think about learning a new language? I am not sure if that is the message I would want to convey (the blogs I linked in the first part of this message think so). I would rather convey that there is power in numbers and power in voices - if you like me think that this is a rather SORRY direction for the language to be heading in over all... SPEAK UP and say so. Send sun messages, get involved in the JSR project and get this sort of thing derailed before it starts. Other wise, the language you are working in right now my go the way of M code, or Cobol.
Dynamic vs. Static
SO - I took a little dive down The Rabbit Hole, as I am apt to do, and followed a bunch of links on JSR-308. To be perfectly honest I am greatly disturbed by the information that I found. There has been a great deal of discussion about Dynamic languages, static languages and languages that are mostly static taking on some of the dynamic language goodnesses (or vise versa). Both sides (static and dynamic) have some relativly cogent arguments about why their thing-a-ma-gigger should be the one that means the most to the most programmers. Personally, as I have stated in the past, I am a "use the best tool for the job" type of person. Not only that, but I tend to try to bring in the stylistic flavor of other languages into the language I am using at the time, often mixing styles and metaphores as I go. Both arguments are powerful and at the same time equally pointless in the face of just being simple and getting done what you need to get done.
So, in terms of the JSR specifically, let me say that I am disappointed because the JSR I don't think is bringing anything of intrinsic value to the java language. This may be because I am looking for inherntly simple things or it may just be that I am personally a simpleton but lets assume that I give / gave myself the benefit of the doubt in this case. The title of the JSR-308 says the following:
"JSR 308, “Annotations on Java Types”, enriches the Java annotation system"
which I will admit on the surface seems simple, but it SOOOOO very much implies so much more. This JSR would allow the common coder to add annotations on java types and even further would allow the common coder to supply an annotation to a generic type as well. Some people would consider this to be progress... I am personally not so sure. Take the following example shamlessly pilfered from the "Wide Awake Developers" site:
void marshal(@Readonly Object jaxbElement, @Mutable Writer writer) @Readonly { ... }
Can someone please explain to me what this line would mean to some other class in my code? Better yet can someone please explain what are the potential outcomes of having a line like this in my code in an effort to "improve" my overall codebase?
If I had to guess someone can probably explain to me that the @Readonly is telling me that jaxbElement will not change in the method context. They can tell me that @Mutable is telling me that the 'writer' variable will change in the method context and that the second @Readonly is telling me that the method itself can only be called by something else that is also marked as @Readonly. Holy CRAP is that an amazing amount to remember about a single method.
Now I can hear a bunch of people sputtering that this feature would eventually find its way into being managed by the IDE's we may all use and love. I personally say that even if it does, that the value introduced by these new annotations is/will be lost on most people.
K.I.S.S.
One of the first things that I learned in programming and IT in general is that one should always keep a level head and try to look for the simple explanations and simple ways of doing something first. Keep It Simple Stupid is what I was always told. I came to understand that for the most part this old adage holds true. Granted that there are times where it is not always possible to do, maybe it is a particularly hard algorithm that needs implementing or other such item - but even in those cases attempting to be as straight forward as possible will help the person that follows you up in attempting to maintain and support the code. The addition of these new type annotations I do not think is in the vein of KISS. I think that this new JSR is about attempting to solve an ever smaller set of 'potential' coding issues (bad nulls, modifying variables you didn't intend and the like). The value proposition I just don't feel is there.
Specifically I think that this JSR is heading in the wrong direction. While most newer languages these days are heading in the direction of being more dynamic, more human readable and human understandable - this annotation JSR moves java in the other direction. We all know programming is hard but do we really need to make it even more so with something like this? This JSR raises the barrier to understanding what the code is doing in my opinion, lowering the overall understanding of java programmers of how their system works. Keep in mind that we have some other already complex things to solve... things like understanding multithreading and keywords like volatile better, maybe even adding some better multicore-multithreading support into the language... instead and to my dismay we as a community are out there attempting to solve a little niche of a problem. Granted the types of problems that this can solve are plenty hard to find and debug - but for an experienced programmer they are a small amount of an overall codebase.
SOOOO... How does one interpret...
Think about the interpretation of the example line I provided. I once said programming and being intuitive was all about memory / context - the idea of being able to hold in active memory about 7 +- 2 things, if I have to hold onto MORE then 7 items just to interpret what a singular statement is attempting to do and not even a statement per se. but a method declaration - I believe that I have bastardized the language. Why work to make it so hard for someone to just "Grok" what is being done that it is not worth the time it may take to learn to use the new feature. I would venture to say that it may be so hard to use this potential new feature 'correctly' that most people will just skip it altogether, being intent on what they know and understand. It will take the avg. person so long to make good use of the new feature that the language may be long dead before someone really makes it part of the main stream of development in java.
Should people start to think about learning a new language? I am not sure if that is the message I would want to convey (the blogs I linked in the first part of this message think so). I would rather convey that there is power in numbers and power in voices - if you like me think that this is a rather SORRY direction for the language to be heading in over all... SPEAK UP and say so. Send sun messages, get involved in the JSR project and get this sort of thing derailed before it starts. Other wise, the language you are working in right now my go the way of M code, or Cobol.
Tuesday, May 6, 2008
Stylistic Intuition - Or not!
A fair friend of mine Raganwald wrote a post on the word "intuitive" stating that at least as it applies to programming languages it just isn't (i.e. it doesn't apply). A similar topic came up at work @ Big Co. in the last week or two in the form of something that company has not had to date... a coding style guide and a list of coder guidelines for how common tasks are performed in code at Big Co.
Perception is Reality
Intuitive means different things to different people. Something that is intuitive is really all about how the person looking at a particular item sees that item. As raganwald put it:
"And this is why it [the word intuitive] is not a very helpful word. Like good design, it means different things to different people."
it seems that this point about it meaning different things to different people is where Big Co. programmers are currently caught up. There are a number of people that have stated that the idea of having a coding 'guide' as well as a best practices guide is just a waste of time. Some have also said that the time spent on this endeavor and the time that may be spent on 'enforcing' a standard are wasted. Specifically that Big Co. programmers should be spending their time working at making things simpler or bringing about more simplicity in the code base. While I agree with the idea that Big Co. programmers and architects should be attempting to make the code simpler I disagree that setting a standard and having guidelines is wasted effort - for the "intuitive" reasons spelled out in raganwald's post. Some other things do come to mind that I think make the effort of value as well.
Memory - Value in commonality
Style guides for source code and guidelines for common programming boilerplate tasks do have value. Specifically they have the value of allowing programmers to "study" what the Big Co. code base looks like. This is important in the same way that updating sections of the code base is, its all about peeling the onion. Everyone has the ability to hold a limited number of things in their head when they are performing a task. Studies have shown that in general the number of things a person can hold in their active memory is about 7 +- 2 items. If all the code @ Big Co. follows a similar guide, I can reduce the number of interpretations I have to make between what my 'intuitive' code structure might be, or the way I may have learned it and over time train myself to expect things in a certain way no matter what type of code I look at when working @ Big Co. Once the 'learning' has occurred it is no longer one of the things I have to hold in active memory when performing a task. The learning has made code style and guidelines something that is automatic and basic ala. training someone to do a repetitive job well allowing room in active memory for other items, like classes related to what I am coding now or refactoring currently.
Programmer Ramp up
The style guides and other boilerplate guides also have value for new hires. New programmers starting at any new job almost always ask for any documentation they can get as well as for access to the source code. The first I assume to be an effort to see how "mature" the company is while garnering information. The latter I see as a way of investigating to see if the code is 'intuitive' to them. If you were to give the new programmer, both the code and the guide - they can level set their expectations ahead of time and possibly get started on things faster then that may have otherwise. The guides and guidelines can provide a needed context that a new programmer @ Big Co. might not get nor see if every new class file they open has a different look and feel. Couldn't all the programmers in the organization be faster if they knew in advance what to expect rather then letting each new source file be a style surprise? It should also be noted that there is something to be said here about not giving new hires immediate 'write/commit' access to the source tree but that is a post for a different time.
Simplicity
Style guides drive simplicity for everyone as well. If there is a common set of guides most IDE's and a good number of text editors these days will allow for configuration. It should be more then reasonable to expect that 'configs' for the commonly used tools in the organization (and even some of the one offs) are available to make the formatting easy. Even if you the singular programmer want to have a different or DO HAVE a different way that you need to look at the source code, there is a step by which you can have your environment of choice put the file back into the 'accepted' guide/standard for the organization. In many respects I consider it more lazy to NOT follow some standard then TO follow one. You could even consider it something I consider a service to my fellow programmer.
I think in the end - a weeks worth of fighting about some things I think is worth it in the end. If I save Big Co. developers 5 minutes of time overall / day it could add up to a significant amount of time saved over time. There is always a point of diminishing returns, but I don't think that this topic is one of them.
Perception is Reality
Intuitive means different things to different people. Something that is intuitive is really all about how the person looking at a particular item sees that item. As raganwald put it:
"And this is why it [the word intuitive] is not a very helpful word. Like good design, it means different things to different people."
it seems that this point about it meaning different things to different people is where Big Co. programmers are currently caught up. There are a number of people that have stated that the idea of having a coding 'guide' as well as a best practices guide is just a waste of time. Some have also said that the time spent on this endeavor and the time that may be spent on 'enforcing' a standard are wasted. Specifically that Big Co. programmers should be spending their time working at making things simpler or bringing about more simplicity in the code base. While I agree with the idea that Big Co. programmers and architects should be attempting to make the code simpler I disagree that setting a standard and having guidelines is wasted effort - for the "intuitive" reasons spelled out in raganwald's post. Some other things do come to mind that I think make the effort of value as well.
Memory - Value in commonality
Style guides for source code and guidelines for common programming boilerplate tasks do have value. Specifically they have the value of allowing programmers to "study" what the Big Co. code base looks like. This is important in the same way that updating sections of the code base is, its all about peeling the onion. Everyone has the ability to hold a limited number of things in their head when they are performing a task. Studies have shown that in general the number of things a person can hold in their active memory is about 7 +- 2 items. If all the code @ Big Co. follows a similar guide, I can reduce the number of interpretations I have to make between what my 'intuitive' code structure might be, or the way I may have learned it and over time train myself to expect things in a certain way no matter what type of code I look at when working @ Big Co. Once the 'learning' has occurred it is no longer one of the things I have to hold in active memory when performing a task. The learning has made code style and guidelines something that is automatic and basic ala. training someone to do a repetitive job well allowing room in active memory for other items, like classes related to what I am coding now or refactoring currently.
Programmer Ramp up
The style guides and other boilerplate guides also have value for new hires. New programmers starting at any new job almost always ask for any documentation they can get as well as for access to the source code. The first I assume to be an effort to see how "mature" the company is while garnering information. The latter I see as a way of investigating to see if the code is 'intuitive' to them. If you were to give the new programmer, both the code and the guide - they can level set their expectations ahead of time and possibly get started on things faster then that may have otherwise. The guides and guidelines can provide a needed context that a new programmer @ Big Co. might not get nor see if every new class file they open has a different look and feel. Couldn't all the programmers in the organization be faster if they knew in advance what to expect rather then letting each new source file be a style surprise? It should also be noted that there is something to be said here about not giving new hires immediate 'write/commit' access to the source tree but that is a post for a different time.
Simplicity
Style guides drive simplicity for everyone as well. If there is a common set of guides most IDE's and a good number of text editors these days will allow for configuration. It should be more then reasonable to expect that 'configs' for the commonly used tools in the organization (and even some of the one offs) are available to make the formatting easy. Even if you the singular programmer want to have a different or DO HAVE a different way that you need to look at the source code, there is a step by which you can have your environment of choice put the file back into the 'accepted' guide/standard for the organization. In many respects I consider it more lazy to NOT follow some standard then TO follow one. You could even consider it something I consider a service to my fellow programmer.
I think in the end - a weeks worth of fighting about some things I think is worth it in the end. If I save Big Co. developers 5 minutes of time overall / day it could add up to a significant amount of time saved over time. There is always a point of diminishing returns, but I don't think that this topic is one of them.
Thursday, May 1, 2008
The Rabbit Hole
I found my self in an interesting conversation just the other day about the commonly and oft wrongly used term for a position in Big Co. called the 'Architect' or 'Software Architect' or 'System Architect', you pick your poison. These days the term 'architect' is over assigned, over used, and overloaded to mean someone that has been in the programming or software development industries for an extended period of time. 'Architect' is being used to indicate that the individuals time 'IN' should equate to them knowing what they are doing and as such that they should be able to 'architect' a good system, or at best design a bit of software now and again from scratch. In the end, this over use and overloading of the word leads to misunderstandings and misinterpretations, and I ran into one in the form of an interesting debate question:
Should an architect also be a coder?
At first I was quick to answer this question in a simple and unequivocal manner: YES!
Then I stopped and thought about the reason for asking the question in the first place and the premise for thinking that an 'architect' should not be involved in any code base, or involved in producing any code for a given system. I then provided what I thought to be a more complete argument then simply answering yes. It went something like:
How can an organization, or any given programmer, expect to have a person or persons be responsible for helping set an over all direction for a system(s) without knowing what it is made of? As a programmer I find out what a given bit of software is made of by digging in and checking out how it is coded. I look to see what the codebase would be capable of doing, what it is resilient against, what code smells might it have - what the over all feel of the code is. I can think of no better way to help set direction and I find it difficult to see the other side which states the 'architects' like managers should not be interested nor involved in how the code is written. That they should only be interested in the high level direction - and that should be their only responsibility. I turned the counter argument in my head into something that I don't like architecture groups to do - and that is to become Ivory towers, or worse yet 'Picture-tecture" groups.
I firmly believe that architects should be involved in code... they should have coding tasks in each and every scrum/sprint/dev cycle (Insert term of choice for your company here). Only in this way can they truly understand the issues and problems and come up with creative and innovative ways to solve them. You might be able to find a unique individual out there who can just "KNOW" a system by hearing it be described - but to me that sounds more like a miracle person then someone I would care to get to know OR take any direction from.
In alot of ways I would hope that an architect would be 'OK' eating their own dog food now and again and being involved in implementing some of the things that they may have at one time put down on paper for someone in a meeting or design session. In essence I think all architects should be ok chasing items down the rabbit hole now and again. Its good for the soul, its good for development and its a spectacular sign that you have someone that is REALLY interested in understanding what they are talking about. An architect interested in a full understanding is what I want - not someone who just thinks they are the shiznit, or like Joel recently posted is an 'Architect Astronaut' or even better someone who is 100% enamored with the title of a blog post. I want to be someone who does really work and ACTUALLY helps programmers solve real problems that let them be faster, and get more done with less effort. I want to chase items down the rabbit hole once and a while - stay sharp and keep current.
Should an architect also be a coder?
At first I was quick to answer this question in a simple and unequivocal manner: YES!
Then I stopped and thought about the reason for asking the question in the first place and the premise for thinking that an 'architect' should not be involved in any code base, or involved in producing any code for a given system. I then provided what I thought to be a more complete argument then simply answering yes. It went something like:
How can an organization, or any given programmer, expect to have a person or persons be responsible for helping set an over all direction for a system(s) without knowing what it is made of? As a programmer I find out what a given bit of software is made of by digging in and checking out how it is coded. I look to see what the codebase would be capable of doing, what it is resilient against, what code smells might it have - what the over all feel of the code is. I can think of no better way to help set direction and I find it difficult to see the other side which states the 'architects' like managers should not be interested nor involved in how the code is written. That they should only be interested in the high level direction - and that should be their only responsibility. I turned the counter argument in my head into something that I don't like architecture groups to do - and that is to become Ivory towers, or worse yet 'Picture-tecture" groups.
I firmly believe that architects should be involved in code... they should have coding tasks in each and every scrum/sprint/dev cycle (Insert term of choice for your company here). Only in this way can they truly understand the issues and problems and come up with creative and innovative ways to solve them. You might be able to find a unique individual out there who can just "KNOW" a system by hearing it be described - but to me that sounds more like a miracle person then someone I would care to get to know OR take any direction from.
In alot of ways I would hope that an architect would be 'OK' eating their own dog food now and again and being involved in implementing some of the things that they may have at one time put down on paper for someone in a meeting or design session. In essence I think all architects should be ok chasing items down the rabbit hole now and again. Its good for the soul, its good for development and its a spectacular sign that you have someone that is REALLY interested in understanding what they are talking about. An architect interested in a full understanding is what I want - not someone who just thinks they are the shiznit, or like Joel recently posted is an 'Architect Astronaut' or even better someone who is 100% enamored with the title of a blog post. I want to be someone who does really work and ACTUALLY helps programmers solve real problems that let them be faster, and get more done with less effort. I want to chase items down the rabbit hole once and a while - stay sharp and keep current.
Wednesday, April 2, 2008
Peeling the onion
A post recently got me thinking about the topic of when it is a good idea to either revisit, rework or at the very least rehash an older "decided" on piece of code in order to make sure that all sections of an application are getting attention. Couple of thoughts around this that stuck me.
Re-visitation
One of the things that I like to do as a programmer is go over other code within a system (especially if it was not originally written by me) and work to understand it. This can sometime be a large and arduous task given the size of some system and the length of time that they have been in production. In the case of really large systems I may take a certain sub-section of the larger whole and attempt to understand just that. My tendency is to do this both on my own and as a result of being asked to 'work' on a given section of the application. Over all I think that this helps me to get a better picture of what the application is doing and can help me to refactor, when needed, to make the system more resilient.
7 +- 2
The above can sometimes be complicated by the fact that despite efforts most people can only hold in their head about 7 plus or minus 2 items or ideas or thoughts. Its a memory thing that is well proven. This point matters the most when you think about how you work on a section of a large application. At any point in time you may be making a spot fix (remembering 1 or 2 points of the application) or a sweeping type of change (attempting to remember how 5-6 or more modules work in concert to get work done). The larger the change you are aiming for the more information that you have to hold in your head. This can get even more complicated the larger the system and or the larger the change attempting to be made.
Pulling back the covers
So with each new dive into the code I get to uncover something that I didn't know and something that potentially I have to 'remember' when I am working in the codebase. One of the things that I love to see is that things that I 'assume' I can take for granted - I can actually take for granted. What I mean is - in working with any code base I have to come at it with a few assumptions and let the code prove me wrong. As a for instance I usually assume that something like connection pooling to a database works in a certain way (ways in which I have seen it work in the past, or ways in which tooling I have used in the past has taught me to think about connection pooling) when the system shows me that it does something different I have to increase the number of things to remember when doing work by 1.
Why memory matters
Programming should let framework be framework and business code be business code. When the code is different then common assumptions and works in a way that is not 'worldly intuitive' (intuitive here meaning in a widely accepted way in the world, knowing that the word intuitive isn't) it means I have one more thing I need to keep in my head when working in the code base. When the code base is really large there are somethings that I would rather not have to worry about. Connection pooling would be one of them. I would want to know that I can grab a connection from the pool and do work in a standard way and then return the connection to the pool. I don't want to have to know that it also performs acrobatics to protect me from not closing resources, or monitors what I am doing or even that it supports the color RED in a new and special way.
No decision should be forever
So, memory, change and refactoring all very important in my mind in thinking about programming. Since I am also a proponent of agile (scrum in particular) I support the idea of constant refactoring as well. I want to always make sure the code I am touching can be resilient to making large changes and always will move in response to the business and the way the business wants the system to work while minimizing the amount of work needing to be put it in to make it do what the business would like. Constant revision and constant eyes make things better over time. Previous decisions may or may not make sense NOW in comparison to when they were made.
Memory is one reason people may suggest changing something, having worked with a tool in the past may be a reason as well. You may even find that people are suggesting certain things based on what they feel is best for the overall codebase. What you can't do is dismiss the efforts to change with the following:
"...And if you don’t even understand what is in place now, then you’re simply not qualified to be suggesting that we move to something standard."
There are different levels of change and different levels of understanding... what is intuitive to one may not be for another. I am not suggesting at all that you dumb down the code to the lowest common denominator - but I am certainly suggesting that when you get enough people saying that something doesn't make sense it might be time to remove that one extra item from memory so that they can get on with making changes that matter.
Re-visitation
One of the things that I like to do as a programmer is go over other code within a system (especially if it was not originally written by me) and work to understand it. This can sometime be a large and arduous task given the size of some system and the length of time that they have been in production. In the case of really large systems I may take a certain sub-section of the larger whole and attempt to understand just that. My tendency is to do this both on my own and as a result of being asked to 'work' on a given section of the application. Over all I think that this helps me to get a better picture of what the application is doing and can help me to refactor, when needed, to make the system more resilient.
7 +- 2
The above can sometimes be complicated by the fact that despite efforts most people can only hold in their head about 7 plus or minus 2 items or ideas or thoughts. Its a memory thing that is well proven. This point matters the most when you think about how you work on a section of a large application. At any point in time you may be making a spot fix (remembering 1 or 2 points of the application) or a sweeping type of change (attempting to remember how 5-6 or more modules work in concert to get work done). The larger the change you are aiming for the more information that you have to hold in your head. This can get even more complicated the larger the system and or the larger the change attempting to be made.
Pulling back the covers
So with each new dive into the code I get to uncover something that I didn't know and something that potentially I have to 'remember' when I am working in the codebase. One of the things that I love to see is that things that I 'assume' I can take for granted - I can actually take for granted. What I mean is - in working with any code base I have to come at it with a few assumptions and let the code prove me wrong. As a for instance I usually assume that something like connection pooling to a database works in a certain way (ways in which I have seen it work in the past, or ways in which tooling I have used in the past has taught me to think about connection pooling) when the system shows me that it does something different I have to increase the number of things to remember when doing work by 1.
Why memory matters
Programming should let framework be framework and business code be business code. When the code is different then common assumptions and works in a way that is not 'worldly intuitive' (intuitive here meaning in a widely accepted way in the world, knowing that the word intuitive isn't) it means I have one more thing I need to keep in my head when working in the code base. When the code base is really large there are somethings that I would rather not have to worry about. Connection pooling would be one of them. I would want to know that I can grab a connection from the pool and do work in a standard way and then return the connection to the pool. I don't want to have to know that it also performs acrobatics to protect me from not closing resources, or monitors what I am doing or even that it supports the color RED in a new and special way.
No decision should be forever
So, memory, change and refactoring all very important in my mind in thinking about programming. Since I am also a proponent of agile (scrum in particular) I support the idea of constant refactoring as well. I want to always make sure the code I am touching can be resilient to making large changes and always will move in response to the business and the way the business wants the system to work while minimizing the amount of work needing to be put it in to make it do what the business would like. Constant revision and constant eyes make things better over time. Previous decisions may or may not make sense NOW in comparison to when they were made.
Memory is one reason people may suggest changing something, having worked with a tool in the past may be a reason as well. You may even find that people are suggesting certain things based on what they feel is best for the overall codebase. What you can't do is dismiss the efforts to change with the following:
"...And if you don’t even understand what is in place now, then you’re simply not qualified to be suggesting that we move to something standard."
There are different levels of change and different levels of understanding... what is intuitive to one may not be for another. I am not suggesting at all that you dumb down the code to the lowest common denominator - but I am certainly suggesting that when you get enough people saying that something doesn't make sense it might be time to remove that one extra item from memory so that they can get on with making changes that matter.
Monday, March 24, 2008
My Years of Experience - An Interview Gone Wrong
so I am just now catching up with some posting that I was fixing to do some time ago. I was reading an interesting article over at Coding Horror pertaining to the myth that when hiring someone it really matters how many years experience that they have listed on their resume. I have to say that for a variety of reasons I could not agree with the premise of this post more. Lemme provide a little background on my last search for a position:
The Setup
I was out shopping for a job and decided this time that I would give a head hunting company a try. I know, I can hear lots of people yelling "NOOOOOOOOOOOOOOOO why would you do such a stupid thing" don't worry, in this case I got one of the "good" companies (JSync). JSync in this case told me that they had several positions currently hiring - one of the opportunities was a position at the Philadelphia Stock Exchange. It seemed like it would be an interesting and challenging place to work. It also seemed as if the description of the position was exactly what I was looking for, the PSE was looking for a talented Java engineer that had X number of years experience with a smattering of other experience required (tomcat and a few other items included) I personally and reflexively skimmed over the total years required and moved right into the things that I didn't have background in to validate that I could learn them without too much effort all seemed in good order as far as I was concerned. JSync set up a PHONE SCREEN that turned out to be anything but.
The Call
The call started while I was out on lunch (specifically because I did not want to have that conversation in the same building I was working at to avoid conflict of interest and all that). The conversation start out well introductions and pleasantries aside the tech guys started their questioning. The questions started out small and my expectation was that they were going to get bigger, instead the questions dove ever increasingly into the extremely minor details of certain items. PSE was interested in the minutia and academia about java and tomcat and a whole bunch of other items. I was one the phone for over an hour. I finally had to stop the interview/phone screen and thank them for taking the time to talk to me but it did not sound like I was the person they were looking for. I interpreted that experience to say that they were interested in someone with either more experience OR someone who knew things that are easily found in a book or on the web. What they seemed not interested in was my ability to learn and self start. Rather then be interested in the process that I go through to gain knowledge in new technology and process.
Jeff states in his article:
"what software developers do best is learn. Employers should be looking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language -- and serving them up interesting projects they can engage with."
This is what I think the interview, er, um, I mean phone screen at PSE should have been attempting to ferret out. Can I learn what I need to in order to do the job that the PSE would need me to do. Their screening process, I do not think, came anywhere even close and as a result left me feeling like the interview was a bust overall. I neither got the job or an offer, I just didn't measure up to their 'experience expectations'.
So if you are in a hiring mode what would you rather have - someone that has experience in software programming or someone who can pick up and use anything with ease and speed when the task at hand calls for it. Would you rather have someone stuck in their way of doing things or someone who can utilize any tool to approach and solve the problem at hand.
Jeff notes:
"No matter how many years of "experience" another programmer has under their belt, there's about even odds that they have no idea what they're doing. This is why working programmers quickly learn to view their peers with a degree of world-weary skepticism. Perhaps it's the only rational response when the disconnect between experience and skill is so pervasive in the field of software engineering."
So like Jeff I pose the question, if you are looking for a job, why would you want to approach a company who is still using the 'years of experience myth' to do their job posting and searching. Like Jeff I find the attempt to be a simply ignorant move to weed out people that the companies think are all fluff and no stuff. Rather you should look for companies are searching for passionate people with a desire to learn. Companies should look for people that have a modicum of experience (6 months to a year) and consider their full experience as a programmer, the "learning range" of the person they are attempting to hire and search for excellence in that area.
In the end if your looking for a job, you'll be much happier and satisfied with the interview when the items above are what the company is interested in... if you are the company doing the hiring you will be much more pleased with the result of your hiring efforts when it comes down to doing actual work in new and creative ways.
The Setup
I was out shopping for a job and decided this time that I would give a head hunting company a try. I know, I can hear lots of people yelling "NOOOOOOOOOOOOOOOO why would you do such a stupid thing" don't worry, in this case I got one of the "good" companies (JSync). JSync in this case told me that they had several positions currently hiring - one of the opportunities was a position at the Philadelphia Stock Exchange. It seemed like it would be an interesting and challenging place to work. It also seemed as if the description of the position was exactly what I was looking for, the PSE was looking for a talented Java engineer that had X number of years experience with a smattering of other experience required (tomcat and a few other items included) I personally and reflexively skimmed over the total years required and moved right into the things that I didn't have background in to validate that I could learn them without too much effort all seemed in good order as far as I was concerned. JSync set up a PHONE SCREEN that turned out to be anything but.
The Call
The call started while I was out on lunch (specifically because I did not want to have that conversation in the same building I was working at to avoid conflict of interest and all that). The conversation start out well introductions and pleasantries aside the tech guys started their questioning. The questions started out small and my expectation was that they were going to get bigger, instead the questions dove ever increasingly into the extremely minor details of certain items. PSE was interested in the minutia and academia about java and tomcat and a whole bunch of other items. I was one the phone for over an hour. I finally had to stop the interview/phone screen and thank them for taking the time to talk to me but it did not sound like I was the person they were looking for. I interpreted that experience to say that they were interested in someone with either more experience OR someone who knew things that are easily found in a book or on the web. What they seemed not interested in was my ability to learn and self start. Rather then be interested in the process that I go through to gain knowledge in new technology and process.
Jeff states in his article:
"what software developers do best is learn. Employers should be looking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language -- and serving them up interesting projects they can engage with."
This is what I think the interview, er, um, I mean phone screen at PSE should have been attempting to ferret out. Can I learn what I need to in order to do the job that the PSE would need me to do. Their screening process, I do not think, came anywhere even close and as a result left me feeling like the interview was a bust overall. I neither got the job or an offer, I just didn't measure up to their 'experience expectations'.
So if you are in a hiring mode what would you rather have - someone that has experience in software programming or someone who can pick up and use anything with ease and speed when the task at hand calls for it. Would you rather have someone stuck in their way of doing things or someone who can utilize any tool to approach and solve the problem at hand.
Jeff notes:
"No matter how many years of "experience" another programmer has under their belt, there's about even odds that they have no idea what they're doing. This is why working programmers quickly learn to view their peers with a degree of world-weary skepticism. Perhaps it's the only rational response when the disconnect between experience and skill is so pervasive in the field of software engineering."
So like Jeff I pose the question, if you are looking for a job, why would you want to approach a company who is still using the 'years of experience myth' to do their job posting and searching. Like Jeff I find the attempt to be a simply ignorant move to weed out people that the companies think are all fluff and no stuff. Rather you should look for companies are searching for passionate people with a desire to learn. Companies should look for people that have a modicum of experience (6 months to a year) and consider their full experience as a programmer, the "learning range" of the person they are attempting to hire and search for excellence in that area.
In the end if your looking for a job, you'll be much happier and satisfied with the interview when the items above are what the company is interested in... if you are the company doing the hiring you will be much more pleased with the result of your hiring efforts when it comes down to doing actual work in new and creative ways.
Friday, March 21, 2008
To Tree or not to Tree that is the Big Co Question
I have talked about innovation on this blog before but a book that I have been reading and a recent post by Paul Graham stating You were not meant to have a boss got me to thinking about the topic of innovation as it pertains to management.
Paul says that there are consequences that happen when any company gets big. I believe he was pointing out that there may be a tipping point to the size of a company at which time the standard way of thinking about organization and management starts to break down leading to an inevitable slow down of everything that the Big Co. is attempting to do. He says the following:
"...companies will inevitably slow down as they grow larger, no matter how hard they try to keep their startup mojo. It's a consequence of the tree structure [of management] that every large organization is forced to adopt."
So my question(s) are thus: IS this tree structure, the org chart, really a necessity of getting bigger as a company? Is there really no innovation to be had in how companies organize themselves and the tasks at hand such that the 'tree' is the only way to go? My answer is NO on both counts - there is some empirical evidence for this in the world so let me see if I can back up my answer.
Ah the wizdom of crowds
Crowds as a whole are really quite something; they have a mentality all there own. One of the things about crowds is that they are really really good estimators. They are good estimators because no one person in the crowd has to be dead on they just have to be close. Taking a look across a broad range of answers to a given problem almost certainly provides a more accurate picture then having a few people (managers) making all the 'big decisions' for a company. This should be self obvious as just common place statistics yet every company I know is set up in the reverse and pays little attention to information to be 'gathered from the masses'. Provided the right information disseminated across a large group of people in an effort to estimate say growth of a sales unit within Big Co. the avg. answer has a much better chance to be closer to reality then the answer that a single smaller group of managers might be. There are a number of reasons for this, not the least of which is the pure and simple fact that the managers of a big co. by and large do not have all the information that may be needed to make an accurate estimate. You could argue that it is possible for the management folk to gather this information, my counter is that the instant it is gathered it might not be pertinent to the estimate. Only the frontline employees have a good feel for certain types of things, thus making them good estimators for a whole plethora of items. Big Co. being typical in most cases will however ignore the wisdom of the crowd in favor of a select few. This is a good case for not organizing in a tree and utilizing the information of the people to get things done. Those people however are going to need additional information that typical management holds tight to the vest.
Free and available Information
Information control is one of the ways that management types can maintain the tree structure and the management dogma. However the free and available information about all corners of Big Co. might spark a line of thinking in someone bringing about ideas that management might not other wise have thought of. Information pertaining to budgeting, staffing, pricing, sales and product can be very useful tools to the entire company. There is however an unwritten rule that this information is reserved for the management elite, those who have been shown to make good decisions in the past. What if those management types were armed with an army of people backing them up? What if that army had the same information management did and were allowed to essentially do what Paul says people (programmers in particular) do best which is invent new things rather then what is typical in Big Co. which is a stifling of what could be great new ideas:
"If you're not allowed to implement new ideas, you stop having them. And vice versa: when you can do whatever you want, you have more ideas about what to do."
All ideas should be welcome, radical ones perhaps more so. However if you lack the information about what direction you want to go in or where there have been problems in the past your new idea could meet with roadblocks and other preventative items. Information, good information is at the base of a great number of really great ideas. Share it far and wide.
Being Democratic
One of the HUGE draw backs to the way in which most large organizations is put together is the tree, the non-democratic way in which people are put into management positions. In a great number of cases people are promoted because they have pleased a singular person - their boss. In reality the person promoted might actually be a complete and total ass but that information did not weigh into the decision because only a small handful of people were involved in the promotion decision. In this particular case it might be an individual’s boss and that bosses boss who made the final call. You could argue that better managers of course might talk to people that have worked with said ass before but the tree structure of it all has the tendency to force that idea to the back burner as unnecessary. Be democratic, just like with the freedom of information and let everyone see what everyone else’s ideas are. Let everyone have a vote on what the company should be doing to increase profits, cut costs etc. Let everyone suggest what the best way to get and retain customers is. Let everyone have a vote. There is certainly no harm in letting the masses vote - you may just find that their wisdom was well worth a small effort to solicit the feed back in the first place.
Challenging Dogma
The problem with most of the items above is that they all challenge the dogma in management and organizational structure that has existed in companies now for a long time. There is some evidence in the world that this dogma can be changed (Whole foods employee based store management as an example) but there is certainly not enough of this type of trend setting work being done. Is the tree the only way? is it the case that your ability to change a company from within is limited based on where you are in the tree as Paul points out:
"...when you're part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you're going to face resistance when you do something new."
I say the tree is not the only way; the items above should point that out. There are ways to organize that allow people to feel empowered to make decisions. There are ways in which Big Co. can allow people to THINK and ACT and INNOVATE to keep the company fast. It is however going to take changes in how management thinks to get there. Go Grass roots - take the discussion to the masses let us innovate management and eliminate the 'boss' as Paul thinks of it today.
Paul says that there are consequences that happen when any company gets big. I believe he was pointing out that there may be a tipping point to the size of a company at which time the standard way of thinking about organization and management starts to break down leading to an inevitable slow down of everything that the Big Co. is attempting to do. He says the following:
"...companies will inevitably slow down as they grow larger, no matter how hard they try to keep their startup mojo. It's a consequence of the tree structure [of management] that every large organization is forced to adopt."
So my question(s) are thus: IS this tree structure, the org chart, really a necessity of getting bigger as a company? Is there really no innovation to be had in how companies organize themselves and the tasks at hand such that the 'tree' is the only way to go? My answer is NO on both counts - there is some empirical evidence for this in the world so let me see if I can back up my answer.
Ah the wizdom of crowds
Crowds as a whole are really quite something; they have a mentality all there own. One of the things about crowds is that they are really really good estimators. They are good estimators because no one person in the crowd has to be dead on they just have to be close. Taking a look across a broad range of answers to a given problem almost certainly provides a more accurate picture then having a few people (managers) making all the 'big decisions' for a company. This should be self obvious as just common place statistics yet every company I know is set up in the reverse and pays little attention to information to be 'gathered from the masses'. Provided the right information disseminated across a large group of people in an effort to estimate say growth of a sales unit within Big Co. the avg. answer has a much better chance to be closer to reality then the answer that a single smaller group of managers might be. There are a number of reasons for this, not the least of which is the pure and simple fact that the managers of a big co. by and large do not have all the information that may be needed to make an accurate estimate. You could argue that it is possible for the management folk to gather this information, my counter is that the instant it is gathered it might not be pertinent to the estimate. Only the frontline employees have a good feel for certain types of things, thus making them good estimators for a whole plethora of items. Big Co. being typical in most cases will however ignore the wisdom of the crowd in favor of a select few. This is a good case for not organizing in a tree and utilizing the information of the people to get things done. Those people however are going to need additional information that typical management holds tight to the vest.
Free and available Information
Information control is one of the ways that management types can maintain the tree structure and the management dogma. However the free and available information about all corners of Big Co. might spark a line of thinking in someone bringing about ideas that management might not other wise have thought of. Information pertaining to budgeting, staffing, pricing, sales and product can be very useful tools to the entire company. There is however an unwritten rule that this information is reserved for the management elite, those who have been shown to make good decisions in the past. What if those management types were armed with an army of people backing them up? What if that army had the same information management did and were allowed to essentially do what Paul says people (programmers in particular) do best which is invent new things rather then what is typical in Big Co. which is a stifling of what could be great new ideas:
"If you're not allowed to implement new ideas, you stop having them. And vice versa: when you can do whatever you want, you have more ideas about what to do."
All ideas should be welcome, radical ones perhaps more so. However if you lack the information about what direction you want to go in or where there have been problems in the past your new idea could meet with roadblocks and other preventative items. Information, good information is at the base of a great number of really great ideas. Share it far and wide.
Being Democratic
One of the HUGE draw backs to the way in which most large organizations is put together is the tree, the non-democratic way in which people are put into management positions. In a great number of cases people are promoted because they have pleased a singular person - their boss. In reality the person promoted might actually be a complete and total ass but that information did not weigh into the decision because only a small handful of people were involved in the promotion decision. In this particular case it might be an individual’s boss and that bosses boss who made the final call. You could argue that better managers of course might talk to people that have worked with said ass before but the tree structure of it all has the tendency to force that idea to the back burner as unnecessary. Be democratic, just like with the freedom of information and let everyone see what everyone else’s ideas are. Let everyone have a vote on what the company should be doing to increase profits, cut costs etc. Let everyone suggest what the best way to get and retain customers is. Let everyone have a vote. There is certainly no harm in letting the masses vote - you may just find that their wisdom was well worth a small effort to solicit the feed back in the first place.
Challenging Dogma
The problem with most of the items above is that they all challenge the dogma in management and organizational structure that has existed in companies now for a long time. There is some evidence in the world that this dogma can be changed (Whole foods employee based store management as an example) but there is certainly not enough of this type of trend setting work being done. Is the tree the only way? is it the case that your ability to change a company from within is limited based on where you are in the tree as Paul points out:
"...when you're part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you're going to face resistance when you do something new."
I say the tree is not the only way; the items above should point that out. There are ways to organize that allow people to feel empowered to make decisions. There are ways in which Big Co. can allow people to THINK and ACT and INNOVATE to keep the company fast. It is however going to take changes in how management thinks to get there. Go Grass roots - take the discussion to the masses let us innovate management and eliminate the 'boss' as Paul thinks of it today.
Saturday, March 8, 2008
"Here there be Dragons"
The title of this post "Here there be Dragons" is what cartographers used to put on maps to indicate a location or place that they either didn't know or had not been mapped by anyone at the date/time their map was created. This wonderful line was also used recently by a speaker that I know so I thought I would bring it up here as a way to make a posting point.
Life in general is a large and wondrous thing. The world is big and there are so many things to do and see that one might reasonably expect to only do or accomplish some percentage of 'everything' within their given life time. Life is also a very scary place, with lots of unknowns and lots of places that should be labeled "Here there be Dragons." The world of programming in a large number of ways is also big and full of unknowns and places that should be labeled "Here there be Dragons."
The title, on seeing it written on a map of old would evoke feelings of fear and apprehension in the sailors that used those maps to chart their course. However there were also that chosen few who would dare to use the map to go right to that location, the place where the dragons were, just to see what existed there. The world is full of both types of people, those who can play it safe and are ok with that and those who would rather take a leap of faith and see what can be discovered.
Fear is a natural reaction to the unknown. You know the butterflies in your gut when you do something a little outlandish or outside the norm? Human kind likes to stick to things they know or have experienced already by their very nature. People VERY much enjoy their routines. There are however a few outlying individuals who like to challenge, who like to push the envelope. A group of people that sit on the up and down slopes of the bell curve, ever dragging it in one direction or the other. A group of people who are naturally more nervous about taking chances and on the other side a group of people not as nervous about such things. Corporate world or outside world doesn't much matter in this case - routine is king for some and not for others.
A fair number of people in the world note that programming as a profession has not been around all that long. Hell computers have only really been around for ~50 or so years, a great deal shorter then some of the greatest life changing inventions in history - life altering stuff such as the wheel, the light bulb or even your avg. telephone. So it should stand to reason that a large number of things pertaining to programming have not yet been figured out. There are plenty of examples of where this bleeding edge work is being done. Arguments about static typing or dynamic. Conversations about threading models - and whether or not it is the next big frontier. Blog postings about languages (yes the many and varied) such as Python, lisp, java, ruby, haskell, OCaml, smalltalk and many more. A great many places for programmers that contain the label "Here there be Dragons."
Now alot of people look in on those conversations and ask themselves if those conversations really matter to them. A great number of people are comfortable with what they do and where they are in the programming realm so what does it matter. Those same people asking are the people who would rather fall into their routine. The people on the other side having those difficult conversations are the people who managed to get the butterflies in their stomachs to "Fly in formation" and overcome their fear of the unknown to attempt to make things better for everyone.
So in the end - maybe you are comfortable avoiding places where Dragons lurk. I for one am not - and will constantly look for where the Dragons are in an attempt to bring a new eye to those conversations. I will look for ways to help clear the Dragons out for others and for myself. I will constantly strive to get my butterflies to fly in formation so that I can make the most of my life both personally and professionally.
Life in general is a large and wondrous thing. The world is big and there are so many things to do and see that one might reasonably expect to only do or accomplish some percentage of 'everything' within their given life time. Life is also a very scary place, with lots of unknowns and lots of places that should be labeled "Here there be Dragons." The world of programming in a large number of ways is also big and full of unknowns and places that should be labeled "Here there be Dragons."
The title, on seeing it written on a map of old would evoke feelings of fear and apprehension in the sailors that used those maps to chart their course. However there were also that chosen few who would dare to use the map to go right to that location, the place where the dragons were, just to see what existed there. The world is full of both types of people, those who can play it safe and are ok with that and those who would rather take a leap of faith and see what can be discovered.
Fear is a natural reaction to the unknown. You know the butterflies in your gut when you do something a little outlandish or outside the norm? Human kind likes to stick to things they know or have experienced already by their very nature. People VERY much enjoy their routines. There are however a few outlying individuals who like to challenge, who like to push the envelope. A group of people that sit on the up and down slopes of the bell curve, ever dragging it in one direction or the other. A group of people who are naturally more nervous about taking chances and on the other side a group of people not as nervous about such things. Corporate world or outside world doesn't much matter in this case - routine is king for some and not for others.
A fair number of people in the world note that programming as a profession has not been around all that long. Hell computers have only really been around for ~50 or so years, a great deal shorter then some of the greatest life changing inventions in history - life altering stuff such as the wheel, the light bulb or even your avg. telephone. So it should stand to reason that a large number of things pertaining to programming have not yet been figured out. There are plenty of examples of where this bleeding edge work is being done. Arguments about static typing or dynamic. Conversations about threading models - and whether or not it is the next big frontier. Blog postings about languages (yes the many and varied) such as Python, lisp, java, ruby, haskell, OCaml, smalltalk and many more. A great many places for programmers that contain the label "Here there be Dragons."
Now alot of people look in on those conversations and ask themselves if those conversations really matter to them. A great number of people are comfortable with what they do and where they are in the programming realm so what does it matter. Those same people asking are the people who would rather fall into their routine. The people on the other side having those difficult conversations are the people who managed to get the butterflies in their stomachs to "Fly in formation" and overcome their fear of the unknown to attempt to make things better for everyone.
So in the end - maybe you are comfortable avoiding places where Dragons lurk. I for one am not - and will constantly look for where the Dragons are in an attempt to bring a new eye to those conversations. I will look for ways to help clear the Dragons out for others and for myself. I will constantly strive to get my butterflies to fly in formation so that I can make the most of my life both personally and professionally.
Subscribe to:
Posts (Atom)
