Error: Twitter did not respond. Please wait a few minutes and refresh this page.
- 11,977 hits
cultivate passion for everything else that goes on around programming
Because my last post was related to a quote from a movie (Remember Me), I thought it would be fun to use quotes from movies for my blog posts and correlate them to Software Development.
Recently I only saw The Tourist, which unfortunately doesn’t have really interesting quotes, but I said, “what the hell, just pick one quote from the Memorable quotes for The Tourist”. Actually all quotes are memorable, because they are (very) short and use simple words, which even my little daughter would understand. (But of course, even if they are memorable, I don’t recommend anyone to memorize them).
So let’s take this quote:
This is exactly why (s)he chose him. To distract us.
What if we would replace him with it and think that us stands for us, our software development team and (s)he stand for the project manager or a colleague. I think it’s pretty interesting to see what connotations derive from the transformed quote “This is exactly why he chose it. To distract us.” when we give “it” several meanings.
There is us on one side and (s)he on the other side. How often did you, as a member of a software development team, thought like this? The project manager (or the product manager or the client) is on one side and you, the poor fellow who has to implement something on the other side. All decisions made by others for you will make you think about why they made that decision. And mostly, you won’t get a satisfying answer to this question. But since this is a question, and you as a software developer always have to get an answer to your questions, you often invent an answer. Not every time the answer is the best one, but you are pragmatic and don’t need the perfect answer, you need an answer that will get you going. One of these answers is seldom (I hope) this one: “To distract us”. This would mean that the decision-making party would have intentionally made a decision to distract you, which I honestly don’t think anyone does. Only perhaps to hide some lacking knowledge of him or to let you think he knows something better, when he in fact doesn’t.
But nonetheless, this would mean that you are living in a black box, where decisions are being made without your implication and everything seems to be done just to distract you.
To distract you from what?
I think that software developers are always distracted from being inventive, from being creative or being motivated when you make a decision without involving them properly. If they do not have a word to say related to a decision, if they don’t have the time to think about possible solutions to a problem or if they aren’t allowed to test and prove their own ideas, they will feel distracted and unmotivated. Let them be analytic and pragmatic. If you, as a project manager, team leader, leading developer or every other title you may have, take each developers decisional role away, they will feel unnecessary and after a time they will only do what they are told to. They won’t be creative any more and they will not search for solutions on their own. This is definitely not something you would like in your team! If you always choose the frameworks to be used, if you always choose your preferred coding style, if you always choose the design patterns to be used or if you always have to impose your class diagrams, your team will slowly, but surely, become unproductive.
My goal is to let each developer come with ideas. Let every developer search for solutions and let them present their findings. If we would always use what is being imposed to us (like for instance standard patterns and frameworks) there would be no more really ingenious ideas coming out. We would start getting to think only inside the box, rather than outside the box. If every programmer has the chance to come up with solutions and to present them, the team will make the final decision. Thus there won’t be a person to blame for an unfortunate solution, instead the whole team would stand responsible for every decision.
Let each programmer think and let the team be his jury. Don’t choose something that your team can choose. Don’t distract them from thinking. Don’t distract them from being open-minded! Let them Find the Box.
I recently heard an interesting quote from Ghandi:
Whatever you do will be insignificant, but it is very important that you do it.
Of course on a micro-scale, your actions might seem important and may have an influence on the near future. But on a macro-scale, your actions and everything you do as an individual, will not change a lot in the universe and will be just lost in time.
But then why should it be important to do something? Why should we even begin doing something, if we know for sure it will not be something that will change the world?
I will try to explain why by describing how this applies to software development. An average programmer doesn’t write that much code. Most of his time he is debugging, testing or reading. Writing new code might take about 10% of his time. Altering existing code might take even more than 10% of his time.
When a developer changes existing code, he has a goal: make the code do what it’s supposed to do. But this could be done in a quick & dirty way: just fix the code with a minimum amount of effort (because it will be just an insignificant change after all, isn’t it?). Even if a quick fix does the job and the developer might even get appreciation from his not-so-clever-looking-into-code manager, this simply isn’t enough.
You, as a professional developer, should do the following additional tasks when fixing a bug or every time you look over existing code:
Everyone of this actions are insignificant compared to the whole project. But it’s important that you Do Them Anyway!
I have developed software applications for about 14 years. I have written code in Pascal, PHP, C++, C#. I used VCL, MFC, ASP.NET, WinForms.
I always wanted to do a little bit more than just writing code. My goal was to manage projects and to be in charge of the whole aspects of a software’s life cycle. Fortunately, my current employer offered me the chance to advance from being just a developer to being team leader, then project manager and then site manager. This all happened in a relatively short time: about 4 years. Now I can proudly say I have reached my goal!
But my professional life changed a lot in this time. I have a lot of different tasks to do now. Talk to customers, talk to clients, talk to employees. Take part on meetings, do interviews, coordinate activities of different departments, go on business trips. Have an overview on all active projects of the site. Coordinate and manage difficult projects. Be informed on latest technologies and development methodologies.
Compared to my activities I had 4 years ago, what I do now can be seen as a complete turn-around (although I still have days when I spend 8-9 hours in front of my computer). Thinking about my new activities, I can say I really enjoy them all. I like doing all those new things. I like talking to people, I like managing projects, I like having administrative meetings or development meetings. I like meeting new people at hiring interviews. I like knowing and understanding the problems of running a business in the software branch.
But I also like writing code!
Writing code has been always something I enjoy. Although I’m most certainly not the best programmer, I find a lot of pleasure writing code. Having had some time to look at other people’s code, I think I also found out how to be a better programmer. Now I definitely understand topics like Scrum, TDD, Dependency Injection, Inversion of Control, Refactoring, Design Patterns, Unit Testing a lot better. I’m pretty sure that I became a better programmer by not programming. By reading about this topics, by implementing them in the projects I manage, by seeing the benefits of them, the urge to write code is even bigger now. Doing a code review always makes me want to just check the file out and start refactoring code! But I have to force myself not to write code, and instead suggest to other developers how they should write better code.
So how will my job look like in 10-20 years? Will the CodingPleasure go away? Will I still have the desire to write code?
To remind myself about the coding pleasure, I named my blog CodingPleasure. The name of the blog is also a word-play to Jeff Atwood’s CodingHorror. Many thanks, CodingHorror, for your truly inspiring blog!
This blog post from CodingHorror proved to be true so many times!
It still helps when I forward the link to junior developers, who always think the framework, the IDE, the libraries, etc. have some bugs in them 🙂