So a friend of mine Mr. Fury recently wrote a little post on "Process" (Yup, thats capitol P process). Specifically, since he and I work for the same Big Co., we was writing about a wonderful framed master piece that hangs on a number of walls at Big Co. This art piece, which he points out, is meant to be inspiring and up lifting is a bit off the mark and is a bit mocking rather then inspiring and uplifting. This picture says simply "Process = Progress", I think attempting to indicate that we are not moving forward @ Big Co. unless there is a process in place. It may also indicate that progress can not be measured without a process - but I am not sure that is the direct meaning.
Now - I admit, that I share some of the sentiment that was expressed by Mr. Fury on this one: process = progress seems to be a little off the mark in the situation that he describes. To the point where for a little while when I would see this supposedly inspirational picture hanging around our building I would take a black Dry Erase marker and add the programmers negation to it ("!=") placing an exclamation mark in front of the equals sign. Thus changing the equation from a equals to a "not equals". However as I think about this situation even more, even the not is a little overkill (just moving to the other extreme).
The Bad
Process used as a shield against new work or used as a way to send people into a wait state - or cause them to circle because they have not paid homage to the process is using it in a way that it should never be intended. Those people are using process to attempt to slow things down because they are overloaded, overworked or just plain a pain in the ass. In any case - it certainly does not equal progress, quite the opposite in fact.
In this sense - I agree with Mr. Fury because he pointed out in his case that the process was getting in the way. In fact it was adding additional time and drag to what he was attempting to get done. In a number of ways this is doing process for the sake of doing it and not because it is adding value to the job or the work being done. Sometimes it is tolerable to allow process to add a 'factor' onto work being done, but when the additional work being done really feels like it is busy work, or work gone to waste - that process should be dropped or changed it is no longer achieving whatever the process' original goal was.
I liken this bad state of process to the current state of Unions. When you are 'not permitted' to do something as simple as plugging your laptop into a network port in a building because that is a 'union job', that is process for the sake of process and is just plain stupid.
The Good
Process that helps communicate amongst many and various groups inside of Big Co. This is the equality that I think the picture is attempting to draw out. As a company grows it will have need to attempt to keep a bunch of separate units all on the same page. The increasing size of any company makes this increasingly difficult. In this case a little process can help and be beneficial. The caveat that I make is that the process needs to be defined and agreed to by both sides of a given communication and has to be helpful to them both. This decision to add process then needs to be revisited on a semi-regular basis to verify that the process has not grown stale and the need for it long since gone away. Only here do I think that process = progress - using process to help progress.
Overall - I am not sure the direct equality makes sense even with my definition for "The Good". A little process doesn't hurt where it makes sense - but when the process goes bad or is dragging other things down by adding to much time to getting something done, that process should be reworked or at least revisited. In these cases process is getting in the way of doing what Big Co. should be doing - which is the work of the company for the customer. Missing that mark overall is tantamount to failure as a whole.
Sunday, February 1, 2009
Tuesday, July 8, 2008
Sorry about the quiet period...
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.
- 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.
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.
Subscribe to:
Posts (Atom)
