Monthly Archives: February 2016

Tech Woman the Odd One Out

I am neither a hero nor a victim. I’m just a tech woman, the ugly duckling, the odd one out.

Tech Woman The Odd One Out

The world is torn in two directions. On one side I read articles about how difficult it is to be a woman in the world of information technology, I see statistics showing the low percentage of female programmers, studies trying to analyze the facts, find the root cause and give an explanation for this phenomenon. Such „negative publicity” presenting tech women as victims and emphasizing the negative facts does not encourage young girls to follow this path, it rather scares them away.

On the other hand organizations and institutes are dedicated to motivate and inspire girls to follow the path of incredible women who actually became famous in this domain. The heroes and role models are preaching to be strong and not to give up, preparing others for the rough path and fight of their lives. This kind of exaggerated representation of women could have the negative effect of transmitting high expectations which can be easily disappointed later on.

I would like to express my deepest respect to the ones engaged in both directions but I believe that there no reason to portray tech women as victims or heroes. 

In our world full of prejudices we tend to think in stereotypes. It is true that tech women are rare and some say that prejudices are to blame but aren’t also women driven by their own prejudices and so called legends around the reserved and non communicative IT nerds or the cruel, direct and unfair male dominated world?

At the end it all comes down to being the odd out one, the one who does not fit into the picture. The human brain is constantly seeking for balance and harmony thus it automatically focuses on the one disturbing element which does not fit to the pattern. It starts to search for reasons and explanations. In stead of trying to answer the question „Why is the one in the picture and why it is so different from the rests?“ we should rather ask „Why are all others there and why they all look alike? Wouldn’t they look boring without the one?“.

Tech Woman The Ugly Ducking

I know how it feels to be the ugly duckling. I have been confronted with questions like „What sort of creature are you and how did you end up here? Wouldn’t it be better for you somewhere else?“. I grew up in a country where I was a part of a minority. During my scholar studies and later at the university of information technology I was suddenly representing the minority of a minority. I left my native country to start a better life somewhere else and ended up switching countries several times. Now I am woman and I am working in the IT in a foreign country so I guess that makes me a triple minority. The minority effect branded my whole life.

Having everyone’s attention, being the focus of discussions, the target of jokes or left  aside can be difficult to handle sometimes. I know what I am talking about. As a tech woman I had the opportunity to experience such situations. I went through the stages of outrage, acceptance, resignation and ignorance, until I learned to use it to my advantage.

It takes time but with a good portion of tenacity and perseverance I have learned to laugh at typical jokes I did not find funny at all. I have also learned to accept and ignore the jokes about women although some are actually funny. Meanwhile I am trained to talk about or listen to the newest IT trends, frameworks and gadgets, even though such topics are not my main point of interest. Honestly speaking, topics like the latest fashion or the newest make up hype are not that exciting either.

Of course it is easier to judge and blame others for not being accepted and treated how we would like to but let’s face it, women could improve in some aspects as well. Here are some best practices that made my life easier.

Do not take IT personally!

I used to take everything more personally, I felt often offended or misinterpreted some words or reactions. Being sentimental does not help in this business. Objectiveness is something women can learn from their male colleagues. I used to think that I was the subject of discussions or the target of jokes whereas the others had absolutely no intention to offend me. Of course I am asked sometimes to get the coffee rather that to be a part of serious discussions. At the beginning I was indeed not amused but with time I learned to accept it with a smile and ignorance.

Be loud if needed!

I am often involved in discussions with alpha males and I do have difficulties to get their attention and to bring my opinion into consideration. The trick is not to give up, if I am not heard the first time I try again with slightly raised voice paying attention to remain polite and not become sentimental. Nobody will hear a trembling low voice begging for attention. Every beginning is hard, to win respect and acceptance takes time and does not come for granted.

Stop reading between the lines!

With time I learned not to question every single reaction and the behavior trying understand the background of every decision. It often turned out not to be true and I realized that it was a misinterpretation based on my own prejudices. Reading between the lines can lead to disappointment in one way or another. There is often nothing between the lines, just our imagination and the projection of our own thought and fears.

“The things we see are the same things that are within us. There is no reality except the one contained within us. That is why so many people live such an unreal life. They take the images outside them for reality and never allow the world within to assert itself.”

Hermann Hesse, Demian: The story of Emil Sinclair’s Youth

Fill the gap!

Let me tell you about the typical programmer behavior.

Programmers tend to loose themselves in details. Ask them to explain a solution in few sentences and they show you a code labyrinth, ask them to start implementing the best case scenarios and they give you the solution for rare, exceptional cases focusing to solve them before even having a solution for the rest of the cases.

The IT experts tend to overcomplicate the problems and solutions. Striving for perfection they transform the solution into a dissertation covering all possible, maybe not even valid, scenarios. A typical case of „over engineering“.

A true technician does not know compromises, he or she has the vision of creating the perfect system no matter how long it takes and how much it costs.

Nowadays, these characteristics are hardly tolerated in the IT world. Talents and visions are often suppressed by market driven organizations focused on mass production and cost savings. Exactly here I see the potential! The tech woman can be the link between the binary world of the information technology and the versatile world of reality. Having a different mindset they can fill the gap between the hardcore programmers and the rest of the world. A feminin touch can bring some benefit.

Tech Woman the link between two worlds

I experience this almost every day, talking to software users and to programmers who wrote the software. It is rewarding to see how two different worlds get aligned and understand each other and to know that I made it happen.

The life of a tech woman can be a challenge but I confess, I like to be the ugly duckling, the odd one out. My life would be much more boring on the other side.

Software bug, a marvelous creature!

If you like BUGS, your place is in the IT. Imagine spending your time searching for bugs and analyzing them, admiring their complexity and amazing talent to disguise and to transform. If bugs are not the reason why you chose IT, you might find the answer here Why did you choose IT?

Software Bug

Perfection is just an illusion, it simply does not exist and IT is no exception. Same as everything else, a software is also not meant for the eternity and will certainly not fulfill all expectations to the full extent during it’s complete lifecycle. Same as a child, software needs to grow and evolve until it reaches the maturity level. Continuos improvement is the key to survival.

From what I have seen so far (and I have seen IT from outside and inside), I can definitely say, that there is NO software without bugs! Just think about software programs and applications you have installed on you’re PC, laptop, smartphone or whatever small and fancy device you own to make your life more complicated. Once installed, you can hardly escape from the new releases and recommended updates promising you a better, more stable version which brings cool new features with it. They never say that with every new feature, with every new version you will become also the proud owner of new bugs, free of charge.

No program is absolutely flawless. Programs and bugs are perfect symbioses, they are like humans and bacterias, like bees and orchids. Programs are the natural habitats of software bugs, whereas bugs are often the impulse for improvements, enhancements and innovation.

There are two types of „bugs“ in the IT, the true ones and the fake ones. Like in the nature, the true bug is rather rare and the rest are just so called, wanna be bugs.

The Hemiptera or true bug are an order of insects…They range in size from 1 mm (0.04 in) to around 15 cm (6 in), and share a common arrangement of sucking mouthparts. The name “true bugs” is sometimes limited to the suborder Heteroptera. Many insects commonly known as “bugs” belong to other orders; for example, the lovebug is a fly, while the May bug is a beetle.“ Wikipedia

A true bug of the IT world is a problem indeed, causing wrong, unexpected results, sucking the memory or hardware resources, in worse case even causing a system outage. It is actually a flaw in the program, generally a human mistake, a tiny issue which was overseen or forgotten during the creation phase. A tiny issue with huge impact. Producing bugs and learning from mistakes is a part of the natural learning process in the life of a programmer. A good programmer needs to have hands on experience with infinite loops, unhandled exceptions, improper validation of input data and many more.

Several methods and techniques like agile software development, code analysis and review, automated unit testing and all in all discipline can prevent such bugs from being introduced in a software program. The problem is that most people do not realize the importance of such actions and tend to neglect them, using common excuses like: „there is no time for this now, but it is high on our To-Do list! Once the product is launched we will catch up.“ We all know what happens with always increasing To-Do lists.

But what about the rest of the bugs? If the true bugs are limited edition, what are actually the so-called fake bugs? A famous IT sentence comes to my mind: „It’s not a bug, it’s a feature“. There is a drop of reality in it, although it is often misused as an excuse to cover human mistakes. These bugs are not easy to handle as they are not clearly errors but a result of misinterpretation, miscommunication or other unfortunate circumstances.

If I ask you to bring me something to drink and you bring me coffee, whereas I was actually thinking of tea but never said it loud, would you consider it your mistake or my fault? Would you go to a restaurant and ask the waiter to bring some food, something digestible, without saying what exactly you wish for?

The more specific we are, the more the result comes closer to our expectations. If we choose not to, than we need to be flexible and be prepared for surprises. In a perfect world, the perfect IT project would have well defined requirements not leaving any room for interpretation, a clear design thought throw without any gaps and unanswered questions. This would be of course realized by highly motivated professional people with clear understanding, working together as a team. I must mention that in this case the written form is mandatory. Memory fades in time and people tend to misuse the power of the spoken word.

Whether they are true bugs or fake bug, they cannot be ignored, they need to be addressed, understood and corrected. Call it fixing, maintaining, patching, changing or adapting the software, one thing is for sure. Bugs are social creatures, they never come alone. Once you find one, you might encounter another one, or by fixing one, you might create two more. It can be a never-ending story and can drive one crazy. The key is to know when to stop, at least for a while to get a clear mind.

My personal tip to you is:  take a break and do something completely different, immediately after fixing a software bug and solving one problem. Don’t doubt yourself and triple check. If you let your brain rest for a while, you might see things much more clearly. If you keep looking at the same problem and the solution you just provided, I can guarantee that you will find the next bug in the system ending up in a vicious circle. Once it’s fixed, it’s fixed. Of course, I highly suggest to follow the four-eye principle and have the fix reviewed by another colleague. If the fix is actually a long-lasting stable solution or just a quick fix, a so called workaround which you plan to replace soon with a better solution, it’s a completely different story.

Noticing the problem and the symptoms is the easy part, finding the root cause is the real challenge. Some bugs are very tricky and hard to find. Sometimes it feels like being a doctor operating on a live system. We all have our tactics and strategies to find the cause of a problem, but there is one which seems to work if all other have failed. I am talking about the elimination principle, a common practice in the IT. I am sure you heard of it, if not, then I bet you apply this in your every day life, maybe not consciously but by following your instinct. People are not born with this skill but they seem to acquire it in the early years of childhood.

I will tell you a short story that, in one way or another, might sound familiar to you. Imagine  a child, let’s call him Dave, on a playground, surrounded by his friends and playing with many colorful, interesting, beautiful toys. Like any child, little Dave prefers to play with his favorite toy, a red dotted silver shining mini drum he just received from his father. Being distracted for a second by the sound of a barking dog, he turns away and just when he reaches for the drum again, he notices that it disappeared. Looking at all the  children running around and playing, he has only one thought in his mind: he wants to get his toy back.

Dave is a clever boy and decides not to cry but to solve the riddle by himself, without the help of his mommy and daddy. He sits down and starts to play a game. In stead of trying to figure our who took his toy, he decides to take a good look at his friends and think about who could possibly NOT take it. His idea is to eliminate the subjects one by one until only one is left. The sweet Mary is surely innocent, she is a very nice girl and he likes her very much. Without realizing that he could be fooled by his emotions, he shifts his attention to  Raemon, a self confident, very social boy. Dave has his doubts and decides to face him with a direct question, hoping that the surprise effect will force Raemon to tell the truth. This strategy doesn’t lead to success, as the boy loudly expresses his anger being accused by his own buddy of something he did not commit.

Little Dave does not give up, he hopes that with patience and perseverance, excluding several options and alternatives, applying different tactics he will achieve his goal. Although the game is often based on assumptions, he needs to trust his instinct and believe in himself.

However the story ends, if clever Dave gets his toy back or not, it will be a learning for a lifetime, one to help him solve problems later on. He might become a brilliant programmer capable of finding and fixing complex bugs.

Future IT people out there, prepare for an exciting debugging and bug fixing experience!