One of the things that drove me absolutely nuts when our department was in the same building as the rest of the company was the fact that nobody could quite understand what we were doing. Quite often we would get a data entry person storm into our office and demand that we fix their Outlook or install Unix on their machine (it turned out that he needed Putty, not a true Unix install). Usually these conversation started with “You guys are not doing anything, right?”. So many times I was trying to explain to everyone that it just does not work like this. We are not just sitting here pressing keys at random most of the time. Best and by far most common argument to support their need for our involvement that I heard was something like this: “It is not going to take long, could you just do this for me right now”. One of our duties was writing a variety of Excel macros for people(I should probably post some tutorials on this subject). After all when dealing with massive amounts of data, it is faster to write a macro then do something by hand. We did not mind doing macros at all, what we did not like is when the person was sitting on the project for weeks and then decided to approach us at the last minute. Client expects the project to be completed at 5 PM, so the analyst strolls into our office at 4:45. Never mind that it takes him about 3 hours to explain to us what on earth does he want macro to do. Never mind that it takes me couple of hours to code the macro in some cases(trust me, there were some huge macros). It had to be done and that is it.

Number of times we attempted to find a solution to this annoyances. For instance we created a little internal web site that would, in theory, help users solve many issues like setting their “Away” message on Outlook and server connection through Putty and such. I did this web site in about 3 days when my computer was send away for repair and I was working on an antiquated piece of hardware we found berried in a storage. Was this web site ever used? No, it was not. Office people would still storm into our office saying that they did not read the instructions as they would not understand it anyway.

The worst part of these interruptions was that it would completely break my line of thought. So you are working away on a complex algorithm with close to no documentation on the objects that have to interact together available. You are concentrated on the task 100 percent, not even noticing that that cup of coffee is now cold, and then all of a sudden you have someone storms in and demanding that you fix their radio right away, or else.

The idea that you just had about this nice piece optimized piece you are about to write is gone now. I must admit that couple of times I flipped. It ended up with me yelling at a poor data entry person, calling them names, questioning their intelligence and so on. After I usually worked from home for a day, but at home there was a urgent need for a game of soccer or emergency epic hide-and-seek battle with my kids. I do enjoy those, but working from home was not a big option from the point of getting any work done.

Few years have passed and then our lease was up. I knew that was the moment when inaction would cost me dearly; I begged and pleaded with my boss to get us a separate office. Likely he agreed with me, and for the last two years we are in a different building, about 40 minute drive away from the main office. At first, main office was really concerned with who would be helping them out with daily tasks, but after about a month they learned to do it themselves. That little web site was finally used on the regular basis. We were not bothered with those requests and could finally spent close to a hundred percent of our time on coding and related things. Our productivity sky rocketed, we were producing better code more quickly and everyone was much happier.

The point is – developers can’t be disturbed. It is a process where ideas and thoughts need to be followed and processed carefully to produce what could be considered good code. You must create a barrier between your coders and outside distraction to produce quality software, and after all it is the purpose of any development team.

Have you ever looked at a code that you wrote several years ago? I have to do this all the time, after all I am working on the same application. Not only do I do it to fix bugs, but I do it to optimize the production code. And at times I see my old code and think what was I thinking when I wrote this. You see, with every release our main product grows, new features, core changes, you name it. One can say that we are optimizing the software by adding things our clients ask for and this leads to optimization of code. Optimizing your code is extremely important, normally there are few ways in which a particular problem could be solved, but if you are serious about your work, you do want to pick the most efficient way of doing things. Many books have been written on the subject, simple Google search will produce lots of articles concerning code optimization. Today I am not going to talk about that, instead I will talk about optimizing a developer.

If you are like me – doing coding full time and at times after hours, you want to achieve something which falls beyond simple financial compensation for you work. I want to grow as a developer. I have read somewhere that it takes roughly 10000 hours to master a task – be it musical instrument, a sport or any other activity. I think similar thing is applied to programming. I have been thinking of a way to apply optimization to myself, after all if my code can be optimized, why can’t the writer of the code. Here are some principles that I have came up with. This works for me, might not work for everyone. Once again, just my own opinion.

So here it is – list of things I (or you) need to know:

Data Structures.

Have you ever thought as to why virtually every course on a programming language begins with overview of your Data Structures. Pick up a book on any programming languages, I guarantee you you would find explanation of some basic types as well as more complex types within first 20 pages of the book. Why do all authors bother putting virtually same information in? Data structures are basic building blocks. If you don’t get the data structures, their limitation, advantages and benefits, you might as well stop coding altogether.

Language.

Let’s be honest, it is not that difficult to pick up a new programming language once you mastered couple. At first all you notice is changes in syntax, for instance Ruby is much more “English” like language in my book then let’s say C. But it goes beyond syntax and different names for your data structures. Every language has it’s own ways of doing things, which might not seem all that obvious to a novice. Spend time, learn tricks of the language, you will get better appreciation for the hard work authors of the language put into it. You would also gain deeper understanding of how to solve that problem in the best possible way.

Compiler / Interpreter.

Compilers are mysterious pieces of code that actually make sense of what a coder is trying to accomplish. Every compiler is different, with its own routines for optimization, process handling and so on. I don’t think it would be fair to say that one has to become an expert on his compiler of choice, but more understanding of how your code is compiled or interpreted will give you advantage in writing this code in the most efficient manner.

Community / Ways to solve the issues.

One of the greatest things about internet is that it gives you access to incredible amount of resources. Most of the time a search engine is my friend. When I am stuck on something, I can always search for a solution and even if I can’t find the solution directly, there are always some situation that are different in many ways and could be applied to solve the issue. Here is an example – few years ago I was stuck with a problem. The project took about 3 month to complete, and at the end we found that one issue, which had nothing to do with data, more of a user experience absolutely prevented us from releasing the feature. It was one of those situations where 3 month of your work is wiped out by something that you assume was so easy and obvious, but in reality was completely impossible. Searching for the solution took about 3 weeks, I was not about to give up on 3 month of crazy coding. I had tortured Google, developer communities, message boards, IRC channels, forums (I think I was even banned couple of times for my persistence), finally with a help of paid support we had an answer which was – “this can not be done”. This was a total disaster, but through the communication with paid Development Support at Microsoft, the engineer that was working on the case with me, accidentally helped me solve another huge issue which was a limitation that was scaring away many potential customers. So what happened to the project? We found a hack to have it work, warned users not to do a certain things at certain instances. While the original problem was not fully solved, the other huge issue was, and at the end I learned lots of new things and got to talk to many coders.

As much as I don’t like freelanceswitch.com or other similar sites aimed at converting everyone and their uncle to the holy new way of life – freelance work, there was an excellent article by Leo Babauta of zenhabits.com on simple project management today. I am not going to go into detail on why I think freelanceswitch.com is not on top of my “favorite sites” list, maybe some other day, but the article itself was simply excellent. If you are not familiar with who Leo is, read zenhabits.com, it’s good for you.

Usually when you read about project management, and you should – it is important, it always starts with “Get the software X and do this, this and that, and you shall be managing your projects just like the pros do”. As seen on TV approach that might get you excited, but at the core of it there is a simple sales pitch to move as many units of “software X” as possible. Leo takes completely different approach, no mentions of any software package that would be a silver bullet for your particular situations, just the basic ideas that often gets overlooked when thinking about managing that runaway train that is your project.

Leo’s idea is simple:

• Define outcome

• Setup process

• Focus on the next action

• Send it to the client

• Communicate

• Focus on the next action

• Repeat until done.

And I would like to go as far as to say that it is not really his idea, it is a universally accepted idea on how to manage most of the projects. What really intrigued me was the fact that there was no fluff in the article, good clear explanation that brings you down to the core concept and let’s you decide how to do this in your particular situation.

I would really recommend Leo and his blog for everyone who is serious about his development not only as a IT pro, but as a human being.

Bad code we all do it.

Well, I had written my share of bad code. Couple of weeks ago I had to fix up a class that was written about 4 years ago. For a while I could not believe I wrote this, but the comments on top clearly identified me as a suspect. The thing is we all write bad code sometimes. If you never wrote any bad code, please raise the hand with which you did not do it.

So, going back to the story – I was looking at it and my first impulse was to try to hide it far away so nobody would ever have to look at it. My second impulse was to rewrite it. I figured, it would probably take me about 5 hours to redo this. I did not do any of it. Instead I brewed a fresh pot of coffee, put my pride far away, printed out copies of it for all developers in the office and decided to play a game. My team consists of 4 coders; two of them were with the company for about 3 years, 1 for about a year and one guy just started in September. So instead of hiding it or quietly rewriting it, I gave my guys the printout and asked them to find mistakes in the class. By the way, the comments that contained the name of the author were not printed.

“Who wrote this crap?” this was the first thing I heard. Then in a typical spirit of our development team there were suggestions on what should be done to the author. And finally there were suggestions, many suggestions. Some of those were good, some were pointless and some were plainly wrong but one thing stood out for me – we all came up with different things to solve the same problem. At the end the class was rewritten and suggestions from the rest of the team were used. After it was done, there was a noticeable performance improvement. Let’s say file X would take Y seconds to run through the original class, after the changes the same file X would take Y/3 seconds. I am talking approximate timing, never actually forced any performance testing. Oh yeah, at the end of it I told everyone who was the author. That did create some awkward silence for a minute or two.

Why did I do it – I was quite capable of doing the work myself. As a team lead, it might be a good idea to hide my own faulty code to keep my image, but instead I did the opposite. I choose to do this for several reasons:

• We are all stressed out, the project we are on. We all needed a break from it. This injection of new problem did wonders for the main project.
• I don’t really care about my image, in fact, I would prefer them not to think that I am incapable of making mistakes and can’t be considered a final authority. I wanted them to find their own solutions.
• We all contributed and the result was truly a collaborative effort.
• It was clear that we all have different approaches to the same solution.

The whole experience was good. Bad code is unavoidable, but if you learn from it, it was not just a bad code it was a learning experience.

I have been told many many times that changes are supposed to be good for you (or me, since it’s my situation that we are looking into). I have been a coder for quite some time now. I can’t say that I am absolutely ecstatic about programming. It does not influence my life outside of my office hours and time that I spent at home trying desperately to improve myself. For instance, I don’t watch Star Trek or build some kind of crazy contraptions which could loosely be called a robot in my basement, although come to think of it, that sounds like a good idea; the robot one, not the Star Trek. I don’t wear nerdy t-shirts with BSOD on it. I am not participating in heated discussions like “My IDE is bigger then yours!” and “My OS can kick your OS’s butt” and so on. I can’t say that coding is my passion, it is something I am interested in and it pays my bills. Another factor would be my formal training – I have some in development, but as for the other areas I can’t say that I am properly trained. Lately something had changed in my work – I am doing more managerial things then coding.

When I realized for the first time that this was happening to me, an image of a Pointy Haired Boss came to my mind. I quickly dismissed it, since I got most of my hair intact and there is no boldness that runs in my family. But I assured myself that I will keep on coding despite the changes. It becomes more and more difficult with every day. I still see a lot of code written by the developers on my team, I get to answer whole bunch of questions from developers as to how should they proceed with their task. At times it makes me want to ask them if google is down, but that’s not the point. Even when I get a chance to code, I have to give projects that interests me to some other people. These projects are more complex, take more time and require full concentration, and simply put, I can’t guarantee that I will be able to give these thing time and effort they deserve.

I’ve tried coding for myself – invent some little projects and making them happen – these things simply don’t work for me. I guess there is no pressure, no drive and ultimately no purpose other then to stay afloat. I still read about programming and related fields, and I read a lot, but it will never substitute the real deal – getting down and writing real life code, with all the stress, cursing, coffee spills and the rest.

To be honest, I miss the programming part of my job, but I still can give an honest question to that answer – ” Are changes good for you?”