What I see in IT

What IT has taught me

2008-03-26T08:33:00.000-07:00

Eat your own dog food

This saying states that you should use your own products internally, as much as possible. Not only does this show pride in your work, but you also get to know your product from the user's point of view. Every company should do this, and this way you can get a first hand experience of how to improve the software, what other features to add, and whether those "life-altering" features that you decided to add, actually alter the user's life for the better.
One should not shy away of using the products, and also checking their compatibility issues with other products. It is quite unfortunate that people who build software for specific reasons, that they cannot use them each and every day. It might be an adequate punishment in Dante's Inferno ,seeing some software developer having to use their own software each and every day. If you were to be the one using that software each and every day, maybe you would put less images, and bigger text. Or maybe you would make that airplane boarding software less fancy, and more responsive. Or maybe you would make that online booking system less Web 2.0, and more reliable.
And even if at the end of the day you get to use your own software, and you like it, do not forget the blind people, or colour blind individuals, or people who have problem using a mouse, or people who do not understand your main language....
if everyone working in software were to consider a bit more the users, and as many of them as possible, I am sure that the quality of it would greatly improve.

Open Source

2008-03-17T07:27:00.000-07:00

Open source! One of the best inventions, ever! If you do not know what it is, or you think you know what it means, but are not really sure, read the article in Wikipedia, and then continue reading here. A difference one must understand is in the definition of free software. Free can be in the sense of free beer, and it can also be in the context of free speech. What I am really interested in is as in free speech ( although free software is a very good idea too).
An interesting article is this one.
Open source is a good way of testing your own skills, and of getting involved. It helps you stop whining about the current state, and actually do something about it. Also the software can be trusted a bit more, both because you can avoid malicious coders, and by knowing how secure it is. Also you feel more product ownership in something you helped create. However most products you use are not created by you, but you can feel better by knowing that you can modify them, understand them, and upgrade them easier.
In open source you get a natural society, where everyone works for the common good, and also people help each other, and try to build a superior product, to improve people's lives.
This ideology can be used in way more places than software development. Open source religions already exist, maybe politics is the next logical step? We need to keep evolving ourselves, and even our ideas. As Bill Hicks used to say, "You know, evolution didn't end with us growing thumbs".

Psychology and IT

2008-03-14T05:22:00.000-07:00

There two fields are closer than one thinks. When studying Computer Science and Artificial Intelligence, I had to cover many topics that fall under psychology. From how human memory works, to neural networks. From communication, to language learning and acquisition. However another area where it is of massive importance is at the workplace. it is of vital importance to remember that at the end of the day, we are working with human beings, who have dreams, feelings and agendas. Their language is ambiguous, and their APIs are inconsistent. Their IDE tends to be hard to use, and sometimes what they say is hard to compile ( or rather interpret ). Humans also do not have one generic protocol for communication, and their source code is unmaintainable.
Which is where the psychology kicks in. One needs to wear extra gentle gloves when dealing with humans, and also, one must not forget his or her own feelings and problems. Projects do not only fail because of lack of knowledge of the available technologies, or because of coding standards. Projects also fail because of human nature. Some people find it hard to get along, other absolutely cannot work together. Some people are hard to understand, while others suck at team work. Everyone has a personal character, and when working with such people, get to know their "documentation" and their "API calls", because ( and trust me on this) you'll need them later.
Recently I was trying to explain to friends of mine ( who do not work in IT) what a retrospective is. The reactions this got were mixed, and they ranged from people not believing it works, to people not believing it is needed.
From my personal experience, I find these little exercises to work. it is good for a team, as a whole, and as a new temporary family, to try these exercises together, because after all, improving the team structure and internal working, will improve how the team works as a whole.
It is good to know what other people did.
it is good for other people to know what you did.
It is good for every team member to feel appreciated.
It is good to see that past failures are being worked on.
It is good to get your voice heard.
It is good to take a short time off, and reflect.
It is good to learn from past mistakes, otherwise they are lost.
It is good to laugh together, as a team.

And finally, it is always to look back, before looking forward. This is why the Roman god Janus has two faces, facing different directions.

Unexpected problems

2008-03-11T09:21:00.000-07:00

Sometimes we set off to take a very big task, and prepare ourselves for the worst. We look at certain areas that we think to be hard, and expect a lot of problems to arise from them. However, ironically, the biggest problems arise from areas we thought to be hard, or else from areas we did not even think might pose problems.
So much just like real life. After worrying a lot about something, what really hits you hard, is what you did not even consider to ever be a problem. Just as said in this song...

" Don't worry about the future. Or worry, but know that worrying is as effective as trying to solve an algebra equation by chewing bubble gum. The real troubles in your life are apt to be things that never crossed your worried mind, the kind that blindside you at 4 p.m. on some idle Tuesday. "

Well, in my case, I have two example in my head right now. These are Unicode, and TimeZone issues.
When working on data, many times you get stuck on issues related to Unicode, and this is why it is a very good idea to read about it beforehand.
And when working on getting data from across the globe from point A, and then handle it in a script on point B, store in a database in point C, and then read it from points D and E, it is good to know about timezones, and think beforehand how to standardize this data, and also when the data is updates, and when the peak times are in those areas.
Just my two cents...

About me

2008-03-05T10:02:00.000-08:00

The most dreaded question, in my humble opinion, within a job interview, is when they look you straight in the eyes, and ask you, "So, tell us something about yourself." This question is normally meant as an ice breaker, and also as a way to give a synopsis of your character. From here normally one tries to understand a person's background, which means from where a person is coming, and also where a person is going.
I despise this question for the simple fact that I do not know how to summarise my life, my achievements, my past, present and future, in a single straight answer. This for me, is nothing short of impossible. So normally I start with my name, education, some characteristics, and then start to stumble about dreams, wishes, ... and this is where they normally interrupt me to start asking other questions, some which are even more dreaded, like... "What is your worst character trait?"
But well, it is good and practical to be able to describe yourself. Whether it is to do so at a cocktail party, in an interview, or on a blog, it is something one should be capable of doing. So let the description begin.

I consider myself to be a smart person. I am also very entushiastic. I love challenges and I love problem solving. I do not know everything in life, but what I lack in knowledge, I make up in curiosity.
I am a very friendly person, and this is said not just by me. All team members I have worked with have commented on this. I really appreciate this. I believe that every person should help those around him to have a better work environement. And a good way of doing this, in my opinion, is by being a cheerful person. Something is bound to go wrong, always, in any environement. Projects fail, people clash, and sometimes these happen in the worst timing possible. So a good way of dealing with all this, is by being a friendly person. A smile would help, and also sometimes cracking a joke. Lightening the mood will help those around you, and also their relations towards you.
I also appreciate people who are friendly, and enviroments that help such people succeed. Some places just kill that joy within people. Try never ever ever to work in such a place. Your personal happiness is worth much much more than that.
You should work to live, not live to work.

The science of testing (and debugging)

2008-02-28T11:56:00.000-08:00

I was amazed (but after thinking about it, it seemed pretty obvious, how much the scientific method, and testing, have in common. Testing, and once something goes wrong, debugging, are naturally scientific ways of observing a system. Taking the steps directly from Wikipedia, one can observe how similar the steps are for testing.

Define the question
Gather information and resources (observe)
Form hypothesis
Perform experiment and collect data
Analyze data
Interpret data and draw conclusions that serve as a starting point for new hypothesis
Publish results
Retest (frequently done by other scientists)

First the question needs to be defined. In our case this means that during testing, be it Black box or White box, one needs to know what is going on. What am I looking at? What is it supposed to be doing? Is it doing what it is supposed to be doing? A system can very easily do the wrong thing in a very good manner. In such a case, the testing is said to have failed nonetheless.

The obervation part is the actual testing. Here yo uare expected to interact and observe the system itself, noting down what is happening, measuring the results, and all this without inflencing the actual execution.

Then the hypothesis comes. From the previous data, you see whether the test has failed or not. If it succeeds, you understand why. If it fails, you need to understand why too. You might need to rerun some tests.

The fourth step refers to performing the experiments and collecting the data. Try toggling some setting. See when the results are the same, and what is common in all. This is like detective work, and this is where bright mings normally start to shine and be seen as the geniuses they are.

Now we need to analyze the data. When many programmers, QA people, testers, or any other person, looks at the facts, they all see the same data. But the information is not the same to all. To some the problem is hard to find, and they are as short sighted as bats. While some other person would scream "Eureka", and go rummaging through some forgotten folder, tweak with some random setting that is forgotten by all, and smile at seeing the bug solved, while others just stare at his face asking what the hell just happened.
This contains all the last steps. One needs to come up with a hypothesis, try to dis/prove it, and act on the results.

As usual, science helps us in al situations. =)

Scrum

2008-02-27T04:37:00.000-08:00

Before I started working, I had never heard of this approach for working. I had heard of Agile, and I had read a lot about DSDM. But Scrum for me was a new word. So when I got to know that now my work would be dictated by this approach, I went home and did my homework. I researched it, read some material, and tried to understand what it really is. And I liked what I found.
A fact that people that push Scrum like repeating a lot is that it is not a methodology. (They also like to say that it is not a cure-all/panacea/silver bullet). Scrum is a form of Agile. In Scrum everything is time boxed. You are given a finite and unmovable amount of time, and you say what you will achieve in that time. You have the product back log, from where you choose what work to do. This is chosen based on business value, which means how much it will help the company. Then you have your iteration ( which in our case is normally two weeks), during which every day you say what you have done from the last meeting, what you plan on doing till the next meeting, and any impediments that might be keeping you back. The team can also have some tool to help them keep in touch on who is doing what.
Before the iteration the user stories are estimated, and at the end there is the review, and retrospective. An important factor is that the team is self managed. Two important roles in Scrum are the product owner, and Scrum Master. I will not explain what they do, because all over the Web there are definitions. I don't have a lot of experience as to what to compare Scrum, but I can say that in my case I have found it to work very well, and I like the way work is done efficiently and responsibly under it.

Free for all

2008-02-26T08:00:00.000-08:00

It is nice to see that other people agree with your point of view.
In this case Bill Gates is describing some cases where it was young people who were the pioneers, and they were the ones coming up with important discoveries or inventions. He mentions Isaac Newton, Charles Darwin, Albert Einstein and also ( more recent ) Steve Jobs, Sergey Brin and Larry Page. He explains this occurrence with this paragraph...

"Why do young people play such an important role in innovation, even though older people have greater breadth of knowledge and a deeper understanding of their field? My theory is that young people aren't as constrained by traditional ways of thinking. They haven't yet completely absorbed the "right" way to do things, so they are free to pursue ideas that seem impossible to those of us with more experience."

Another article that I found interesting was this one. I have always had a dream of a world where services would be free, but ad driven. Cinemas can be free, and you pay for the pop corn... Even computers themselves can be free one day. It is nice to finally read an article which discusses such a concept. It even mentions Radiohead's new approach to selling music. Their new album is freely downloadable. However if you want the actual CD, you have to pay for it. Also, once fans that like the music attend the concerts, then they are making a profit anyway. Email services are free, searching on the Internet is free, and even air travel can be free. Radio is free... so why cannot all TV be free? What about music?

"The huge psychological gap between "almost zero" and "zero" is why micropayments failed. It's why Google doesn't show up on your credit card. It's why modern Web companies don't charge their users anything. And it's why Yahoo gives away disk drive space. The question of infinite storage was not if but when. The winners made their stuff free first."

Missing Links

2008-02-25T07:32:00.001-08:00

The good thing about IT is that it is easy to stay up to date. Everything is happening on the Internet, and almost everything is reported there. This is why it is good to research as much as possible. Forums offer an endless supply of help on any problem you may bump into. And by endless, I actually mean it. This is due to the fact that if you do not find what you were looking for, you can pose your own question, and then people will answer you. Once they do, the answer is stored forever, for anyone else in the future who shall meet the same problem.
This is a beautiful cycle, and we are the first generations to witness it. It is more than beautiful... It makes me happy. Recently I was sick, and I stayed home from work for three days. So I decided to take all my university notes, go through them, and throw most of them away. Eventually this task turned out into a "throw everything away" party. It made me feel lighter, and refreshed. The tears strolling down my face were more of happiness, than of melancholy (or at least so I hope). The reason that an information squirrel like me felt totally fine with throwing everything out, is a one word answer... Google! My point was, Why keep all those archaic pieces of rusting paper in unaccessible useless cumbersome box files, when the same information is so easier accessible from Google in 0.03 seconds, or from Wikipedia. And this information is portable everywhere. And free. And updated. And referenced. Man... I love the 21st century!
Speaking of Google... I doubt that ever before were there so many possibilities in information gathering. I have always been fascinated by this topic, in fact I based my thesis on information acquisition, and presentation. This topic for me is immortal.
Blogs are another fantastic way of staying up to date. Obviously I do not refer to the boring and tedious blogs were people decide to drone on about at what time they woke up, and what they ate, or placing pictures of their pets. But rather to the more technically oriented blogs that one can find on the web. So today I will start sharing with you some links that I like to visit frequently, and I find to be informative.

http://www.codinghorror.com/blog/
Some discussions about current ideas, and also some important ideas. Also discusses some problems programmers face ( 0r cause ).

http://www.randsinrepose.com/
An interesting blog that helps people out with dealing with programming in the industry. Also speaks about topics like interviews. It is technical, without diving too much into technical details.

http://channel9.msdn.com/
Meeting place for people using Microsoft technologies.

http://thedailywtf.com/
Good place to learn from other people's mistakes... and laugh at them when no one is looking.

Beautiful Book

2008-02-21T13:09:00.000-08:00

It is a well known fact that one cannot learn anything new by looking at his or her own code. You might find some bugs, you might wonder what the HELL you were trying to do in those lines of code, but for sure you will not learn anything new. That is why it is important to peek at other people's code, and from there observe their way of doing things. You can learn new tricks, new workarounds, or also new approaches.
It is with this frame of mind that I approached the book mentioned above. Beautiful Code is a book full of peeks into the brains of people well known in this industry. They all share their thoughts, experiences, and some problems they might have had in the past.
I read this book from cover to cover, without jumping any chapters. It read fluently, and it was interesting.
I like reading and running through books that speak about code itself, because it is a good way of learning new paradigms and ideas, however I love reading books like this one even more, because it does not get stuck on an IDE level, but instead focuses more on a human level... on what some people were going through when working on a project - because after all we are humans, before we are software developers.

I simply hope I get to read more books like this in the near future.

Just my theory!

2008-02-19T13:33:00.000-08:00

We geeks love to code. It is our life. We love to create, give life to our dreams, and check what is possible, and what our boundaries are. We love programming, and if we could, we would do it all day long. We look for jobs where we work in software development. However the truth is that we would pay to be able to hack away all day long.
My theory is that companies pay us to keep us away from coding. They all know how much we love coding, so they pay us, to lock us away, near a computer, but too busy to code. Meetings.. conferences...emails...questions... all part of a conspiracy theory to keep us away from our new toy. The next time that you are stuck in a meaningless meeting, that seems to just drone on and on.. think about this theory. =)

Since I am in the mood of joking, I would like to share this link with you. http://www.youtube.com/watch?v=zJOS0sV2a24

What IT has taught me

2008-02-18T04:51:00.000-08:00

Modularity helps

Many times in life we are faced with problems, that seem to be huge. We stare at them, and think that they are beyond us. The first reaction to such a situation is to give up. Every person has his limits, and in such moments we feel like we have reached our limits, so we want to give up. Such a problem can be a favour asked from us by a friend, handling a difficult person at work, or maybe even a car that will not start in the morning.
However for all of these problems, there is a simple solution. At least it will make a good starting point. This solution is modularity. No matter how big the beast that you have to kill which is right in front of you is, it can always be torn down into little pieces... small enough for you to handle.
This is very important when it comes to programming. Many times when I look at the requirements for a new system, I gasp for air. Most things look hard, while the rest look impossible. Some problems are so big, that it feels outright impossible to even start considering trying them out. However, luckily for us, we can break this down into modules. And if we still believe it to be impossible, we break those modules further down. Eventually, after enough divide and conquer, we would have gotten somewhere where we have MANY pieces, which however are of a size which is small enough for us to chew. ( This technique works pretty good also with food.)
The good thing with this approach is that it works with other real life problems too. Whenever there is a big problem in life, even though it is not a programming one, breaking it down always helps. If you have a very busy day, with too much work to do, breaking down all the tasks that have to be done helps. Even with relationship problems, breaking them down in such a way that you can handle all the small ones, one at a time, is always better than giving up.
So when it comes to solving problems that at a glance seem to be too huge for you to handle, the trick is to do the following.
First start by breathing in, and out. No matter how busy you are, start by clearing your mind, and keep breathing.
Second, do not give up. This is the most important step. As long as you do not give up, you are on the right track.
Third, break the problem down, until you can handle the little modules.

That is all you need to do. Then start handling module by module, making sure that every one you build, works the way you want it to work. Finally fit all these modules together, like a Lego castle, and you have finished the whole system.

What IT has taught me

2008-02-15T05:18:00.000-08:00

KISS!

No, this is not a blog entry related to St. Valentine's day. It is not a sentimental essay about the beauty of relationships. It is related to the KISS Principle, one of the most basic in life, yet for me, also one of the most important. KISS stands for Keep it Simple, Stupid. Simplicity is key to improving quality, and also to avoid future frustrations. It is always important to keep in mind Occam's razor.
When one fails to be simple, one is opening Pandora's box. After doing that, nothing can be guaranteed. Debugging is harder, upgrades are harder, sharing of code is harder, anything you have to do will become harder. You are simply making your life, and of those around you, harder. Complexity should become a four letter word, and everyone should fear it.
And when I am speaking of simplicity, I am not referring only to the design, or the architecture, but to the whole process. Well, even the process itself should be simple. And the final product, and its graphical interface.
The message is simple... keep it simple! Whenever there is a lack of simplicity, find the source of it, and tackle it immediately. Just like the discoverers of the double helix, I have a fundamental belief that any correct artifact, needs to be simple.

In IT, there are many tools that aid in this. In coding, there is OOP. In design there are hierarchies and abstraction. But more on those on another day... There are also tools to measure complexity. Such is the need to keep it under control. Everyone should try to strive for minimalism.

To conclude I shall leave you with some quotations worth sharing...

Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away.-- Antoine de Saint-Exupéry

Everything should be made as simple as possible, but not simpler. -- Albert Einstein

Simplicity does not precede complexity, but follows it. -- Alan J. Perlis

Computer Science is the first engineering discipline in which the complexity of the objects created is limited solely by the skill of the creator, and not by the strength of raw materials. -- B. Reid

Simplicity is the peak of civilization. -- Jessie Sampter

What they didn't teach you

2008-02-14T05:35:00.000-08:00

A working week is very short!

Something which you definitely need to get into the industry to appreciate, is how short a working week is. When one looks at a working day, one is amused by how short this is. Considering how much time tasks take, and also how much time is lost in some activities, like meetings and also communicating with other team members, one has to ask himself how people manage to actually get any work done.
A very important skill to be learnt is always how to manage this little time effectively, and make the most out of it. Time management is a very important skill at university, and even more so at work. Deadlines approach very fast. With only 5 days a week, and 8 hours a day in my case, every minute is important. So when you hear that a deadline is a whole month away, when you come down to the maths, you realise how small that is.

A bad worker...

2008-02-12T07:39:00.000-08:00

The saying goes that A bad worker always blames his tools. And nothing can be more true. Many times, when an idea fails, we all look around to find what to blame. We search for a scape goat, or some other person silent enough to blame. However, people have the nasty habit of defending themselves, and try to get out of that mess. That is the good thing about the working environment, you can blame it as much as you want, it will never respond.
Many times at work you see colleagues shouting out "Damned IDE, how stupid of it!". Or you see enormous forums bashing some silent OS. How many times did we point fingers at our tools, and felt a sudden rush of desperation, feeling powerless over its idiosyncrasies. Later on however, after calming down and looking deeper into it, we blush when we realise that it was all our bug, our mistake, our fault!
Therefore it has become my rule of thumb to never ever blame my tools. No matter how obvious it is, how much I am sure that it is not my fault, I always assume it is my fault, and try to prove it. Too much self esteem can be damaging while working. Being too sure of your work, and never taking the blame, is the first pitfall that captures way too many people.
Many statements that I hear way too much, are "It is the fault of my predecessor", "Management screwed up", "The tools are lacking in this area." Whenever I assume upfront that the fault is simply my fault, and try a bottom up approach to find the fault, rarely am I proved wrong. In fact I would throw out a number as low as 1%, even though this is based on no real studies done, just a gut feeling.
The problem with blaming your tools, is not that something innocent is taking the blame, but more the fact that a fault is being allowed to survive, when in reality that bug should be squashed. Also people tend to look for newer updates, which is also a problem, since any update, solves old bugs, but also creates new ones. Other prefer to look for different technologies, which is also a problem, since this leads to time wasted in research and training.
Now I have to leave you, since I have some more debugging to do.
So in conclusion, the lesson of the day is, Never blame your tools.

Food for thought

2008-02-11T07:12:00.000-08:00

"But I called this a minor cause; the major cause is... that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming had become an equally gigantic problem. In this sense the electronic industry has not solved a single problem, it has only created them, it has created the problem of using its products. To put it in another way: as the power of available machines grew by a factor of more than a thousand, society's ambition to apply these machines grew in proportion, and it was the poor programmer who found his job in this exploded field of tension between ends and means. The increased power of the hardware, together with the perhaps even more dramatic increase in its reliability, made solutions feasible that the programmer had not dared to dream about a few years before. And now, a few years later, he had to dream about them and, even worse, he had to transform such dreams into reality! Is it a wonder that we found ourselves in a software crisis? No, certainly not, and as you may guess, it was even predicted well in advance; but the trouble with minor prophets, of course, is that it is only five years later that you really know that they had been right."

The Humble Programmer, Edsger W. Dijkstra

Familiar?

2008-02-07T08:30:00.000-08:00

I met this comic online. The link is this. Funny... yet depressingly accurate.

What IT has taught me

2008-02-06T12:09:00.000-08:00

If you have a hammer, the whole world seems like a nail

When trying to solve problems, it is very important to be equipped with the right kind of tools. So if you need to cut a loaf, it is better to have a knife. If you need to nail a picture to the wall, you need a hammer, and if you need to crack some nuts, you need a nutcracker. However many times was I in a situation where I did not have the right tool for the job at hand. In such situations, I try to solve the problem the other way round. I see what tools I have, and how they can be applied to the task I need to solve. This can lead to some creative insights, and can result in some really wonderful new approaches to old problems, and in the past lead some people to come up with new wonderful discoveries.
However today I am not going to discuss the upside of this approach, but rather the darkside of it. Sometimes we get caught in the situation where we only have a hammer available, so we start pounding away, as if everything were a nail in need of being put deep inside a wall. Many times people are stuck in a rut, using the same technology for any task required of them. Some people prefer Python to C#. Others prefer Java to C++. Some people feel more comfortable using one technology as opposed to another one. However every technology, every language, has its own reasons for being. Everything has its own niche market, and it would be stupid, and sometimes even a fatal mistake to mistake a plate for a nail.
If one language is meant for prototyping, it should not be used for a mission critical piece of software. The same can be said for methodologies, team structures, and also ways of researching information. Sometimes a new approach is greatly needed. And if one tries to look, the signs are pretty obvious.
Many people are afraid of change in their life. They might fear thatthey would feel inadaquate, or even are afraid other might make them feel obsolete. This is not true. All technologies are great, however it is yet a greater skill knowing when not to use your skill. And it is always good to learn new ideas, and new ways of doing the same old tasks.
It is important to stay up to date, but most of all to have an attitude which is an open one. Do not try to shoot other ideas down, just because they are different. Which approach is better can easily be measured and observed, and let the winner be declared as so.
So the next time yo uactually feel like your ideas, and your ways of doing work are being threatened, simply ask yourself why. Then remember how good it has always has been to learn new stuff, and let yourself go with the flow. If you still feel like your way of doing things is equally valid, then fight for your right. But if you feel like a hammer is not what is really needed right now, simply put it away, and go and buy the appropriate tool. But do not lose sight of that hammer just yet. It still has its purposes.

The Zen and the art of Programming

2008-02-05T14:16:00.000-08:00

In his book Zen and the Art of Motorcycle Maintenance, Robert Pirsig speaks in depth about the idea of a gumption trap. He defines this as something which is a thought blocker.
"Throughout the process of fixing the machine things always come up, low quality things, from a dusted knuckle to an accidentally ruined 'irreplaceable' assembly. These drain off gumption, destroy enthusiasm and leave you so discouraged you want to forget the whole business."
In his case he was speaking about fixing and maintaining motorbikes. He described how while trying to fix a bicycle, sometimes he used to get stuck. Maybe he was looking from the wrong angle. Maybe he was just looking at it from too close. I love reading this book, and I make it a point to read it every Summer. It has thought me more about programming than most of the books I have read. It does not speak about techniques. It speaks about attitudes. In this book, Pirsig comes up with similar gems like:
“It is a puzzling thing. The truth knocks on the door and you say, "Go away, I'm looking for the truth," and so it goes away. Puzzling.”
“The only Zen you find on tops of mountains is the Zen you bring there”
“The Buddha, the Godhead, resides quite as comfortably in the circuits of a digital computer or the gears of a cycle transmission as he does at the top of a mountain or in the petals of a flower.”

I do not normally subscribe to ideas that pretend to be new age, spiritual, or that offer some kind of instant Karma. And the fact that I love this book is pretty much proof that it is none of these. Here Pirsig goes through all the pain of explaining to us how it is best to tackle a problem. And also how sometimes, the best way to solve a problem with your bicycle is to take a walk away from it, where you cannot see it. Or maybe an eight year old can solve it for you. Or what about a soda can that costs cents?

To me this is all relevant to my daily life working in IT. It is very important to clear your mind before working. You cannot carry problems from the outside world in with you. Your desk cannot be a disaster area. Ideally you have a quiet room, without interruptions. The mobile is on silent, the chair is now squeaking, and you are fully concentrated. The desktop is not full of many useless icons, you have least distractions possible, and also few applications open. And I always feel like I need some good music, to help me concentrate. If not for that, at least to filter out the rest of the world. Some Pink Floyd would be perfect, or maybe some Opeth would do the trick. Anything that eventually blends in with the background, and I am allowed to accelerate to my normal speed of life. It might take me a few minutes to get started, but once I am on my top gear, there is no stopping me.
After saying all this, there is still a problem, which is where Pirsig comes in. That damned gumption trap. Like the main character in Pi, waiting for the break through to come. Sometimes one gets stuck on a problem, which seems impossible to overcome. What is my trick in such situations? Walking away! Forgetting about the problem. Nothing is as much a mood killer for me as a monitor, specifically one with some IDE open, with a string of characters splashed on the screen.
During the thesis I would take a break, and go jogging. Or when it was too late ( after three in the morning) , I would open up Quake, or Grand Theft Auto, and vent some frustration. At work, a simple walk around the building helps. Or going for a quick coffee, or checking out book. Anything, as long as it takes me away from that monitor.
Many are the times when I had a breakthrough in the bathroom, sitting relaxed trying to think. Or while standing on the bus, on the way home after a refreshing night out. So the message that I learnt in all this, is that sometimes, you just might be trying too hard.

What IT has taught me

2008-02-04T14:38:00.000-08:00

If it's not broken, don't fix it.

Many times in life we look at something which works, and we wish that we could improve on it. We see something, and as the geeks we are, we try to imagine how it works. In our minds we strip it to its bones, and there it lies naked in front of the eye within our mind. We play with it, and understand it, and look at it for its beauty, not in aestatic way, but more in a practical way. However many times, unfortunately, our thoughts do not stop at that step. We choose to take it that little bit forward, and think of what features we could add to it. We try to see how we can "enhance" it. And the word enhance is used sarcastically, because more often than not, it simply adds a layer of complexity, which does nothing but turn off both engineers, and normal users.
How many times have we ( me included ) stared at something that works perfectly, but feel compelled to tweek with it? I remember, even as a child, looking at any toy I was given, and thinking of how I can tear it apart to make it run faster, last longer, shine brighter, or simply make it better in all ways possible.
What was the result, more often that not? A non functioning toy, a crying child, and angry parents. Even as children we feel a need, as geeks, to improve all technological stuff. It might have something to do with our need to understand, or maybe it is a thinly veiled attempt at feeling control and ownership over such items which we do not understand, and, admittingly, scare us. Or maybe we are just plain stupid.
However with IT I learned a simple rule which made all this obsolete. If it is not broken, do not fix it. And of course the fix it refers to playing around with it enough to make it unusable. Many times, I am sad to say, have I seen a syndrome in IT people, that they want to tweek with something until it evantually becomes unusable. In IT it is called feature creep and it is indeed a creepy concept. It makes the software be perpetually in beta, thus making sure that everyone involved ends up frustrated.
The answer to all this, is quite simple. If it is not broken, I will not fix it. Repeat it many times. It will improve your life. Your personal life, your intellectual life. Even your work life, and everything else around you. If you know a technology which works, keep using it. Do not be blinded by all the sparkles of all the new hypes. There are many in IT, and I can guarantee you there will be many more. Also, if any software you use, has a new version coming out, stay loyal to the old one, unless if you really need to migrate. After all, the new software will be full of bugs, and unknown issues. The one you used so far, works. How do I know it? Well, you managed to get by with it so far... so why leave it behind?

So in life, be it in coding, in technologies, or even in any other personal issue you might feel that you have, remember the golden rule, that IT has taught me. Be it with your car, or a relationship... be it clothes, or the remote control. Don't fall in the too familiar pit trap. Otherwise you end up without your dreamed-of versions, and even without the initially working remote control. Be minimilastic with your items. Make sure they do one thing, and one thing well. The more complecity you add around it, the more points of failure you add. The more points of failure you add, the more the whole system ends up looking like a house of cards.

What IT has taught me

2008-01-31T04:52:00.000-08:00

Being good is not enough to be good.

Sometimes in our field, we meet people that are nothing short of geniuses. They can do in half an hour more than you can do in one whole working day. They seem to know all there is to know, and they have got a lot of experience and knowledge, which would make you stare in awe. I know that in my life I have met some of these people, and I always treated them with the highest of respect. However, sometimes such people seem to let you down, and the reason for this is that they fail in other areas.
So you might look at a person, and realise that he or she is very good at coding in a specific language. This person is very productive, and produces code at a very fast rate. Such a person, left to run under his own steam, will do a lot of work. However, one day you would need to work on a project that such a person had started. And this is where all the trouble starts. Such a person would not have adhered to coding standards. The code would be a mess, unreadable, no comments.... and it reminds you more of a plate of spaghetti than of work. This is a dreaded situation to be in. Also, to make it worse, variable names are meaningless, of course there is no documentation available, and the system in unscalable. This will all help in making you look even more unproductive, since you have a lot of work to do, before actually starting to do any real work.
Another problem with such a person can be the social skills. Maybe this person is not a good team player. Maybe he always wants to be the one shining, does not have any clue as how to explain himself. Such a person makes it hell to be working with him, unfortunately. These reasons have made me lose respect for a number of people in the past. This is due to the fact that at first you realise how good they are, and what they are capable of producing. But then at the end of the day, when you go to look at these people from another point of view, you realise that there are many problems underneath it all. These are the kind of people whose design ( or lack of it) reminds you of a Rube Goldberg device.
So the lesson that I learnt is that many times, an average software developer, that however is good to work with, and can follow standards, is way better than a person who knows it all, but cannot really control it.

What IT has taught me

2008-01-30T06:03:00.000-08:00

If you're going to fail, fail early!

Whether it is in a relationship, or in a project. Whether it is in a life plan, or in organising a picnic, the best thing to do, if you are going to fail, is to fail as early as possible. The reason for this, is that it is much much less costly over there. In the beginning, there is less commitment. There are less resources tied down to it, and also less items that depend on it.
Sometimes some things in our life are just not meant to be. Maybe the person you are with now is not meant to stick by you for ever, or maybe some dream of yours is just doomed to fail. In such cases, the sooner you realise, the better it is. And also, something else that I did learn is that failure does not always have to be bad on you. Just make sure that you learn at least one positive thing from the experience, and that failure would not have been for nothing. Failure is an F-word, but it is not a four letter one.
During university life we are all presented with the graph, of how much it costs to fix a problem. We are all shown that if something takes X effort to fix in the first stage, it would take 1000X in the later stages. It is important that such lessons learnt on the school bench, are not forgotten, or even worse, applied only for work life. They hold true for real life too.
As a result of this, one of the first stages in software development life cycles is the feasibility study. In this part we all say, "Thanks for showing me your idea. It is indeed nice. But now let me sit down for a while on my own, do some number crunching, and see whether it would actually make sense to try it out."
There can be many reasons why a project is not meant to succeed. Maybe you are assuming to have available technologies which do not exist yet. Or maybe you are expecting a different user. Or maybe there isn't the budget you would need. So in such a case, it is better to stop before you would have invested too much.

What they didn't teach you

2008-01-29T04:49:00.000-08:00

Sometimes cutting corners is OK.

When a person is still a student, there is a lot of work to be done. This includes assignments, studying, research, reading, and also trying to hold together a life. You know... when you are trying to do YOUR stuff. So at that period of your life knowing how to juggle is considered an asset, because you have many things going on, and you need to do your best in all of them. You cannot do well in exams, but then not do assignments. You cannot do assignments, but not turn up for lectures.
However when you start working, I found it important to realize that this perspective on life does not hold true for the industry. Over here, it is sometimes good to cut corners. In fact sometimes you are encouraged. I do not mean that you should hand in substandard work, or that you should fail deadlines and do what you want. What I am referring to is the fact that sometimes you have to lose some to win some. Sometimes you need to scrap an idea if it failed. Sometimes you need to compromise speed over security, compromise interface over speed. And so on. You cannot do everything in life, and sometimes you have to dedicate your effort in doing a few things, even though it would mean neglecting other areas.
However, after having said all this, I do not mean that you should scrap ideas randomly, or that you should just do what you feel like, and not obey orders. Everything should be driven by business value. Everything should be dictated by how much worthed it is to the company, and at the end of the day, how profitable it is.
As a geek you might feel attracted to take on the challenging stuff by the horns, and tackle it to the ground. However that might not be what is needed of you. Maybe something which for you is trivial, might make other people at work more productive, so maybe you need to do that first.
And after all, the biggest difference between student life, and working life, is that when you are a student, handing in assignments is where it all ends. Once that is done, ideally on time, the project is over. In real life, handing in the work, is where it all starts. Once the system is deployed, you start getting requests, complaints, and you need to maintain the system. So frankly, here, just making it compile will not make anybody happy.

We don't work for NASA, do we?

2008-01-28T05:39:00.000-08:00

When you are at work, it is very important to remember where you are. And I do not mean where you are, as in how you are improving, but rather literally. Where are you? What company are you working for? This is always important to keep in mind. Most probably you are not a mechanical engineer, and most probably you are not working for NASA. Therefore, you should not be creating rocket science. And this point is a very important statement to remember. In fact it would be better if you can write it on a post-it, and stick it onto your monitor. Or tattoo it on your wrist. Leave rocket science to the rocket scientists. As for you, you should be coding.
What I am trying to say, all sarcasm aside, is that it is always bad to complicate beyond needs. Many programmers tend to do this, and this always has a detrimental effect on the work that they produce. The reason for this is much more fundamental than one might assume. As software developers we are always taught to think, to generalize, and to think of all possible situations.
For example, you are asked to sort an array of numbers. Immediately you ask yourself what you should do in case of negative numbers. What about numbers that are repeated? And what if an input is string? Should I prefer space over time, or vice versa? Most programmers would consider this, and that is good.
However some take it to the extreme, and this is where the problems start. You cannot think of all possible problems, all possible situations, because if you did, you would end up building rocket science. Code should be simple, and context sensitive. If the numbers shall be input by another module built by yourself, you can know what to expect, so you can assume some facts. If you are asked to build a system, your code should avoid being too complex, and with a lot of rocket science within it.
Somewhere in between these two extremities lies the Zen of programming. Somewhere in between making rocket science which is very general and caters for many non-existing problems, and between making code so simple and fragile that it fails on most inputs.
If you are asked to build a house, you should look at your surrounding before starting building. Does it make sense to worry about floods? Even if you are building it in the middle of a desert that hasn't seen any rain in millennia? Build a house that is suitable for its environment, and only then can yo usay that you have succeeded.
A system which is way more complex than it needs be, is harmful in many ways, more than can be seen at a first glance. Not only is it harder to build, it is also harder to test, maintain, and use.
So do not be like the Knight in Alice in Wonderland, that had inventions on his horse that catered for all possible situations, including mice traps and unusable boxes.

What I see in IT

What IT has taught me

Open Source

Psychology and IT

Unexpected problems

About me

More links

The science of testing (and debugging)

Scrum

Free for all

Missing Links

Beautiful Book

Just my theory!

What IT has taught me

What IT has taught me

What they didn't teach you

A bad worker...

Food for thought

Familiar?

What IT has taught me

The Zen and the art of Programming

What IT has taught me

What IT has taught me

What IT has taught me

What they didn't teach you

We don't work for NASA, do we?