Today I observed a pity situation at work. A senior developer with 10 years experience in Java Enterprise solution have been tried to be replaced with a trainee. The trainee had to prepare build script for a Java project, without a standard maven directory structure, with Ext GWT, Oracle , etc. The trainee doesn’t even know how to write Hello World in Java!
Dear managers don’t confuse cows with software developers ! Yeah, I know the cows and software developers give products 
There is a joke for a woodchopper who axes woods with a blunt tool. When the woodchopper was asked why you didn’t whet your axe, he answered that he had a lot of work and had to cut a lof ot woods and no time to whet the tool. The last two months I observed the same situation in software version . The blunt tool was a DB which was more than 5 000 kilometers away of the office and the acess was very slow to it. Every access to the DB for debugging purposes took us about 5 minutes and every one of us lost about 2 hours every day in waiting. We explained to our bosses that we had a problem. The problem was decided after 2 months! The aproximate calculations is that for four developers we have lost more than 300 hours in waiting of the DB which is about 20% of our development time!!! Next time when you rushing in doing something ask yourself whether you have whet your main tool.
There is a situation when you see that the product you are developing is deadly born. Sometimes the reason is the marketing, sometimes it is the bad management and rarely it is the development process. If you don’t believe me read “Code Complete: A Practical Handbook of Software Construction” by Steve McConnell. So why do I have to reduce the software development cycle two to three times due to some stupid mistake which is explained in the first serious book for management and marketing ? Why do I have to listen some apologies that the client is vary capricious ? And every time when I ask myself the above questions I reach to the idea that management and marketing are activities for clever people who can foresee their steps no more than 2 week ahead! So my advice is never start thinking to be team leader, project manager, marketing specialists and some kind of manager if you CAN’T foresee four weeks ahead what must be done for your product.
Recently I tried to start an OpenSIPS server on a Virtual machine, but I realized that I have made some module’s modifications and server probably couldn’t start due to this modification. I didn’t revert the state of OpenSIPS’s module due to rush for next “URGENT” task. Now I can’t remember what were the modifications. Probably I will loose 2 to 5 times more time to fix this mess.
Recently I read about pomodoro technique which is famous in agile community. I start practicing the pomodoro technique which rely on these 6 simple steps.
1) Choose a task to be accomplished
2) Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3) Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4) Take a short break (5 minutes is OK)
5) Every 4 Pomodoros take a longer break
6) Take notes for every interruption and analyse them in a long period.
My first reaction when I start using this technique was to increase the number of pomodoros which I can do every day which is typical out of the box decision. But I asked myself whether it is necessary to increase the number of pomodoros and realized that it’s not enough to increase the number of pomodoros because it will be temporarily and it’s against the conception of this technique. It’s enough to increase the intensity on concetration. The decision with increased intensity is not popular one because it doesn’t show us or our colleagues how hard we work but actually it is the smart one! This type of decisions is “the in box decision” which is more valuable but subtle for estimation. My final decision was to increase the intensity of concentration of working hours not to increase the working hours. Just work smart not hard !
Last week I made a mistake. I confused the meaning of private/public key and their usage in asymmetric cryptography algorithms. I understood my mistake and excused to my colleague with whom I talked. So in the first moment when I understood that I did a mistake I was angry on me. But when I got calm I remembered that I could apply the last posted principle of the software monk. So I started thinking why I made this error and what can I do to not repeat it this mistake and even how can I escape problems with confusion of my knowledge? I considered the situation and understood that I change the knowledge domain almost every week. For the last 2 or 3 weeks I had to start implementing code on Python and Java, modify servers implemented on Python and C which I didn’t know very well and so on. This facts hints me that I have to cut these kind of problems to the root. My decision which I found out for me was to start making a brief review of the basic concepts in every new area where I am making new steps or I haven’t work more than a year. Probably this approach will cut my mistakes a lot. According to my colleague Mircho 60 to 70 percents. My experiment will show me what will be the result !