An event jogged my memory a couple of days ago and provided the inspiration for this blog article. A number of years ago whilst freelancing I rang a web agency to see if they hired freelancers and whether they had a project I could work on.
I told the person in the conversation about my education, my previous work, my company but I also mentioned that I study programming as a hobby also. Immedietly in a raised voice “we are not doing this as a hobby, we do this as a profession, this is not just some hobby!”. At the time I was shocked, what kind of response is this?
I came to the conclusion that this person obviously cannot conceive that programming can be studied as a profession “and” as a hobby i.e. studied in spare time outside of working hours. The reason the person cannot conceive of this is because this is something the person has never done. This person has never worked on a programming project in his spare time outside of work.
The idea that someone could dedicate extra time outside of professional work to programming something they enjoy is inconceivable to him because he does not enjoy it. Surely anybody who enjoys programming and the greatest programmers out there will know that the programmers who also study programming as a hobby are more likely to be more committed to programming than those who only do it for their profession.
This sort of response can be seen across the whole working spectrum, the more the person takes the work “seriously” the less he is interested in doing work. He takes work “seriously” because he does not really want to work, he gets no enjoyment from doing the work so he cannot conceive that anyone else can enjoy doing work.
In reality he does not work take work seriously at all … “we are not doing this as a hobby, we do this as a profession, this is not just some hobby!” has no real meaning. It says nothing as to the quality of the work he is producing, supposing my code as a hobby is of a greater quality than his code as a profession? His statement says nothing, it is just an empty statement stated with the tone of someone trying to be serious but cannot be taken seriously.
Another situation might be the boss who does not let his employees work from home. This can be well rationalized “we do not like our code on other peoples computers it is a security risk” etc. In reality the boss does not let his employees work from home because the boss cannot concieve of an employee who can actually do work when the boss is not watching. You have to be there so the boss can see that the work is being done.
Again this ties into the enjoyment aspect of it. You cannot possibly enjoy work that much that you would go home and work when he is not watching because he does not enjoy doing the work that much and it is not something he would do. It is the joy aspect that is being targetted.
There have been a couple of occasions in the past where I have been working on a programming task in an office and I have looked up to notice a collegue staring at me. One of the collegues was staring at me in joy with a smile on his face, one of the collegues was also staring at me in joy with a smile on his face and he made the statement “you thought you where being clever there didnt you”.
I never thought much of this at the time but the more I thought about it the more it made sense, in those collegues eyes I must have looked similar to this …
No I am not claiming to be some super genius, but what they saw was probably something similar to that in their own eyes. What they where actually seeing was the “aliveness” of myself actually enjoying working on a programming task.
This can also be seen when asked to struggle with a programming task. Say a new developer is being introduced to a new codebase …
This is how I implemented file uploads.
This is how I implemented error handling.
I put these methods in this Model here and they do this and help with that.
I created this helper class to deal with this.
General developer in the industry …
Yea, just look through the code and struggle with it, mate.
A little bit of struggle is not wrong. Sometimes I already more-a-less knew the answer I was asking I just needed confirmation. Sometimes the struggle can create the “fire” to actually do the work.
I am not saying there should be no struggle I am just saying there should be a balance. In this industry I see far more of the “struggle” path than the opposite, even to the point of asking a question no longer gets an answer but the developer is expected to struggle for 2 hours to get an answer to a question that would have taken 30 seconds to answer. I mean how is this sort of struggle productive? In my opinion, it is counter productive.
The “struggle” path developer rationalization to this is always, “well if I had given you the answer I may as well of been doing the work for you”. Yes in some situations this could be valid but in a lot of the situations I have encountered this it was clearly not valid. It is just an excuse for the “struggle” path developers own lack of effort.
In my own opinion all questions should be answered no matter how simple the answer may be. It may not be simple for the developer who is just starting out. Answering the question helps relieve a blockage in the production.
The next arguement could be “how I am suppose to get my own work done if I am answering questions all day” this could be valid, but then it is a management problem, the manager should account for the fact that the more settled in developers will need to answer the new developers questions.
I personally think all “lead developers” job roles should consist of helping / answering developers questions and maintaining the consistency of the codebase / architecture of the code.
That is all the lead developer needs to be doing, the lead developer should act as a “leader” to the none lead developers and as a person who ensures the cohesion of the codebase as a whole releaving blockages in the production by helping the none lead developers.
The lead developer should not have a huge number (if any) tasks on his plate at all and his / her sole focus should be on the none lead developers, leading them. In reality what generally happens is the lead developer has just as much work as the none lead developers have to do.
What happens? No help is given to the none lead developers, tasks take longer by not getting answers to questions, none lead developers look incompetent, lead developers looks good because his work is getting done and generally everything just takes longer.
Developer asks a lead developer a question, answer it. Developer is stuck on writing a block of code, pair programmme with the developer for 30 minutes, relieve the blockage. Lead developer checks the code commits for the day and finds mistakes, point out the mistakes and ask the developer to correct them. Lead developer checks the code commits for the day and finds inconsistencies in the code which would not fit well with the rest of the code, architectural inconsistencies, point out the inconsistencies and ask the developer to amend them.
The lead developers role in my ideal basically consists of leading and empowering the none lead developers. In most companies the lead developer is merely the developer who has been at the company the longest, not really leading anyone at all. The lead developer does the same job as the none lead developers and to some extent is expected to do more than the none lead developers.
What is worse is that the lead developer is given “first dibs” on most projects, this means the lead developers code 90% of the codebase and then it is passed onto the none lead developers to amend and maintain.
Ohh I will give Lead Developer X this project to do, like I did with the last one and the one before that because he knows what he is doing and he gets the work done within the deadlines. Of course he knows what he is doing, he started from a blank canvas. He makes the manager look good.
Once the project completed and passed on the lead developer is then working on his next project which he got “first dibs” on, so he is now “too busy” to answer the questions of the none lead developers even though he is the only person who can really answer the questions as he wrote most of the code in the whole business.
This kind of position is somewhat of a nice setup for a lead developer, even though the lead developer may be writing more code than the average none lead developer.
A solution? Each developer is given his / her own project or set of projects to build and maintain. If the project is absolutely a huge project that requires multiple developers, then the lead developer is the “leader” and the none lead developers are the “developers” doing most of the work.