In the old university days, whenever I met someone speaking half english half arabic, I usually felt so intimidated of such personalities. I used to think of them as people whom try their best to show off by mixing sophisticated english terminology with verbal mingled arabic pronounced english sounding words. At those days, 3arabeezy for me was a 100% Yukk.
Today, I became one of them (A 3arabeezist). I just cant stop it, I keep mixing english and arabic whenever I speak, I dont know how it came up to be, it just happened. Gradually, I started substituting english words for words that I cant find an arabic alternative for, and vice versa.
It seems that mixing two languages makes me feel smoother. Its not only in verbal languages. Its also in computer languages. You need to write Embedded C in Java code for certain functionalities, and to write PHP extensions using C in others, or even assembly in some C code, mixing languages could be an advantage.
However, mixing arabic and english proves that you are proficient in using both simultaneaously, but very weak in utilizing one at at time.
Even when trying to talk completely in English... one or more 'ya3neeez' have to slip through the conversation. And when I talk in complete Arabic, one or more 'simply', 'basically', 'soon enough', 'I think' have to slip in between.
In funny cases, I'm also starting to use the plural form of arabic words in english form... examples are 'Raheeebz', 'Raw3az', '7abaaaybax' and 'Jee3aanz'.
Lets jump to the lessons learned of this post. I guess there's one really serious lesson to mention. 3arabeezy aint that bad, but could make you look REALLY bad in first impressions. So here's my advice:
1. When introduced to new people, dont use 3arabeezy whatsoever. Stick to one language. Talk professionaly. Dont mix. It will only leave an impression of either a show-off or an improficient talker.
2. In public speech, dont use 3arabeezy unless the audience are people you've worked with before.
3. When dreaming, feel free to use 3arabeezy. Totally acceptable.
4. Sometimes you need to use 3arabeezy when talking to people who know neither arabic or english. This raises the chances that there could be an arabic or english word that sound something similar to their native language.
5. Only use 3arabeezy if you feel that a certain word has a better alternative in the other language that will ease up understanding. Again, this proves weakness in the former language.
Till then, we'll meet again in a next epi-post of 'Lost in the Code Carribeans'.
Showing posts with label Personal Skills. Show all posts
Showing posts with label Personal Skills. Show all posts
Wednesday, May 23, 2007
Tuesday, May 15, 2007
The Long Easy Way Versus the Short Hard Way
Today I had a small discussion with a good technical friend of mine ;) The discussion started with trying to handle an SQL Query with one shot.
The SQL Query got a bit too complicated to handle and needed some extra research, reading and thinking to figure out the correct way to do it. It took two technical brains, good MySQL experience, about forty minutes of work, and at the end some testing. It resulted with a long SQL statement.
Through our work we had another solution, its a very easy solution, get the data you need through multiple SQL statements. Thus, a long but easier way to do it.
We felt so proud that we were able to tackle the short difficult path, but at the end, considering the long easy path we missed, I felt a bit unrelaxed, but as soon as that happened, I was reminded with an important wisdom (by my amigo):
"If you keep choosing the easy and long path, you'll hardly learn anything. It's the difficult short path that provides you with extra skill and power."
Now imagine the amount of skill and power you can gain by choosing the long difficult path. Hmmmm, cool as long as no fatal mistakes takes place.
There's always alternate wisdom supplements when twisting different stories around.
The SQL Query got a bit too complicated to handle and needed some extra research, reading and thinking to figure out the correct way to do it. It took two technical brains, good MySQL experience, about forty minutes of work, and at the end some testing. It resulted with a long SQL statement.
Through our work we had another solution, its a very easy solution, get the data you need through multiple SQL statements. Thus, a long but easier way to do it.
We felt so proud that we were able to tackle the short difficult path, but at the end, considering the long easy path we missed, I felt a bit unrelaxed, but as soon as that happened, I was reminded with an important wisdom (by my amigo):
"If you keep choosing the easy and long path, you'll hardly learn anything. It's the difficult short path that provides you with extra skill and power."
Now imagine the amount of skill and power you can gain by choosing the long difficult path. Hmmmm, cool as long as no fatal mistakes takes place.
There's always alternate wisdom supplements when twisting different stories around.
Sunday, April 22, 2007
Master the Techniques Before Chasing the Goals
Miyagi told Daniel Son while holding the chop sticks:
"You have to catch fly first."
And this applies to any career. Ok, Miyagi was a bit over-reacting here, I mean, if it was not for the 'beginners luck' of Daniel Son, I dont think this movie would have ever ended.
The lesson here is that a career person SHOULD master the techniques of her or his profession. Know it well, do it right, know when to use a technique, know when to drop it, know the pros and cons of different techniques, but most importantly, Master it!
That could be the boring part for some, to master the technique, to know the details, to understand the bits and pieces.
A professional football player knows that mastering a 'pass' weighs much more than scoring a goal. Mediocre players - on the other hand - only care about scoring, this arises from a mentality of greed ... "Need to score, makes me feel good.".
Most low quality environments overlook developing good techniques, and favor jumping directly to goals. Ok, fair enough, the time and budget constraints of 'the start' could force such conditions. But, this symptom easily grows to a disorder when this methodology becomes a continuous habit.
Wisdom of today's post:
"Master the techniques, and make them the solid path to your goals."
"You have to catch fly first."
And this applies to any career. Ok, Miyagi was a bit over-reacting here, I mean, if it was not for the 'beginners luck' of Daniel Son, I dont think this movie would have ever ended.
The lesson here is that a career person SHOULD master the techniques of her or his profession. Know it well, do it right, know when to use a technique, know when to drop it, know the pros and cons of different techniques, but most importantly, Master it!
That could be the boring part for some, to master the technique, to know the details, to understand the bits and pieces.
A professional football player knows that mastering a 'pass' weighs much more than scoring a goal. Mediocre players - on the other hand - only care about scoring, this arises from a mentality of greed ... "Need to score, makes me feel good.".
Most low quality environments overlook developing good techniques, and favor jumping directly to goals. Ok, fair enough, the time and budget constraints of 'the start' could force such conditions. But, this symptom easily grows to a disorder when this methodology becomes a continuous habit.
Wisdom of today's post:
"Master the techniques, and make them the solid path to your goals."
Tuesday, April 03, 2007
Patterns Plus Anti-Patterns
In every engineering science lies the notion of good (design) patterns.
This comes out as a result of repeating good ideas and/or methodologies that work. Once being repeated in different places, a pattern is spotted in which it gets popular between the engineering community and can be safely reused, it even acts as guidelines to beginners.
"Another important concept - but not as popular - is the concept of anti-patterns."
Good Patterns and Antipatterns complete each other. Anti-Patterns are simply the bad patterns that have been spotted being practiced repeatedly and should be avoided.
Its important to note that patterns and anti-patterns do not apply only to software engineering, but rather can be applied to any science. You can even apply it in your own kitchen (strong assumption: you have a kitchen).
I'll discuss here some anti-patterns spotted in the managerial world that have been popular and should be avoided:
1. Fruitless Hoop: The manager who requires endless (often meaningless) data before making a decision.
2. Golden Child: When special responsibility, opportunity, recognition, or reward is given to a team member based on personal relationships or contrary to the person’s actual performance.
3. Leader Not Manager: Being a great leader doesn’t necessarily mean being a great manager.
4. Manager Not Leader: The manager who is proficient at their administrative and managerial duties, but lacks leadership ability
5. Management Meeting Mania: The manager whose only function in the organization is to schedule useless meetings
6. All You Have is a Hammer: One-dimensional management where the same technique is used on all subordinates.
These will do for today. For more you can search google or checkout wikipedia. Keywords Anti-Patterns and Managerial. You can also check amazon.com for good books on the anti-patterns subject.
This comes out as a result of repeating good ideas and/or methodologies that work. Once being repeated in different places, a pattern is spotted in which it gets popular between the engineering community and can be safely reused, it even acts as guidelines to beginners.
"Another important concept - but not as popular - is the concept of anti-patterns."
Good Patterns and Antipatterns complete each other. Anti-Patterns are simply the bad patterns that have been spotted being practiced repeatedly and should be avoided.
Its important to note that patterns and anti-patterns do not apply only to software engineering, but rather can be applied to any science. You can even apply it in your own kitchen (strong assumption: you have a kitchen).
I'll discuss here some anti-patterns spotted in the managerial world that have been popular and should be avoided:
1. Fruitless Hoop: The manager who requires endless (often meaningless) data before making a decision.
2. Golden Child: When special responsibility, opportunity, recognition, or reward is given to a team member based on personal relationships or contrary to the person’s actual performance.
3. Leader Not Manager: Being a great leader doesn’t necessarily mean being a great manager.
4. Manager Not Leader: The manager who is proficient at their administrative and managerial duties, but lacks leadership ability
5. Management Meeting Mania: The manager whose only function in the organization is to schedule useless meetings
6. All You Have is a Hammer: One-dimensional management where the same technique is used on all subordinates.
These will do for today. For more you can search google or checkout wikipedia. Keywords Anti-Patterns and Managerial. You can also check amazon.com for good books on the anti-patterns subject.
Wednesday, March 21, 2007
You've got a bug (Dont take it personal)
Developers have always, are always and will always be in a state of offense when being accused of committing a bug.
Whether they (we) like it or not, the statement:
"You've got a bug."
is an emotionally disturbing phrase for (we) the developers.
The word 'bug' by itself is so phonetically provoking. First of all, its composed from one sylable that pops out all of a sudden. "BUG", "BUg!", "bUG', "BuG", its like microwave popcorn.
It even sounds like you're cursing someone. And sometimes, it sounds like you're accusing someone of having weazels in his hair (قمل).
I try my best to avoid using the literal form of the word 'bug' by replacing it with more friendly alternatives like the words 'defect', 'malfunction', 'problem', 'leak', these words have proved to be more DES (Developer Ear Safe) words.
If you're a quality person, a customer, a manager or any person involved in auditing developer's output, then here are some alternative sentences I've collected through my career to help you out with dealing with such cases:
"The system is acting a bit wierd when I press this button."
"There's a small problem, I dont think you have uploaded the latest code."
"I found this problem, you know what, it looks like a third-party library is going nuts."
"I found this problem, are you sure no one touched the code you wrote?"
"I'm sure you haven't finished yet, I remember you told me you still have work to do in this module, I think this is why all these bugs are showing up."
Also make sure not to use the word 'you'. But always use the passive tense, and talk about it as if its a 'system' problem and not a developer's problem. Not "You've got a bug", but rather, "A strange problem is showing up here.".
Last advice, stay away from discussing this bug with the public; before the bug is fixed, while being fixed and after getting fixed. Dont discuss other people's problems if you dont like people discussing yours.
Whether they (we) like it or not, the statement:
"You've got a bug."
is an emotionally disturbing phrase for (we) the developers.
The word 'bug' by itself is so phonetically provoking. First of all, its composed from one sylable that pops out all of a sudden. "BUG", "BUg!", "bUG', "BuG", its like microwave popcorn.
It even sounds like you're cursing someone. And sometimes, it sounds like you're accusing someone of having weazels in his hair (قمل).
I try my best to avoid using the literal form of the word 'bug' by replacing it with more friendly alternatives like the words 'defect', 'malfunction', 'problem', 'leak', these words have proved to be more DES (Developer Ear Safe) words.
If you're a quality person, a customer, a manager or any person involved in auditing developer's output, then here are some alternative sentences I've collected through my career to help you out with dealing with such cases:
"The system is acting a bit wierd when I press this button."
"There's a small problem, I dont think you have uploaded the latest code."
"I found this problem, you know what, it looks like a third-party library is going nuts."
"I found this problem, are you sure no one touched the code you wrote?"
"I'm sure you haven't finished yet, I remember you told me you still have work to do in this module, I think this is why all these bugs are showing up."
Also make sure not to use the word 'you'. But always use the passive tense, and talk about it as if its a 'system' problem and not a developer's problem. Not "You've got a bug", but rather, "A strange problem is showing up here.".
Last advice, stay away from discussing this bug with the public; before the bug is fixed, while being fixed and after getting fixed. Dont discuss other people's problems if you dont like people discussing yours.
Labels:
Emotional Intelligence,
Personal Skills,
Thoughts
Wednesday, March 14, 2007
Profession(al)?
Having a profession is something, becoming a professional is another. The mental distance between those two is similar to the distance between Irbid and Manhattan.
When building up your profession, there are two parallel lines that you need to maintain and balance:
Step #1: Practice it yourself.
Keep practicing your profession the right way, work smart, enhance your techniques every work cycle.
Step #2: Observe other professional work.
Look at what other good people have done. Understand different methodologies, patterns, techniques and practices. Read, research, find better ways to do the same work.
This bicyclic process is necessary to grow you fast enough.
Dropping line #2 will get you a bit lost and isolated, often resulting in slow progress in your career. Dropping line #1 will simply make you loose your craft.
The most useful tasks I ever got while working in the software industry were debugging, fixing and enhancing existing codebases.
Simply because, I get the opportunity to write code, and to understand how other code works.
Finally, I'd like to end this post with a valuable wisdom:
"Its not what you know, its how good you know it."
When building up your profession, there are two parallel lines that you need to maintain and balance:
Step #1: Practice it yourself.
Keep practicing your profession the right way, work smart, enhance your techniques every work cycle.
Step #2: Observe other professional work.
Look at what other good people have done. Understand different methodologies, patterns, techniques and practices. Read, research, find better ways to do the same work.
This bicyclic process is necessary to grow you fast enough.
Dropping line #2 will get you a bit lost and isolated, often resulting in slow progress in your career. Dropping line #1 will simply make you loose your craft.
The most useful tasks I ever got while working in the software industry were debugging, fixing and enhancing existing codebases.
Simply because, I get the opportunity to write code, and to understand how other code works.
Finally, I'd like to end this post with a valuable wisdom:
"Its not what you know, its how good you know it."
Monday, March 12, 2007
Subliminal Programming
I remember the old days when I used to play billiards, I used to concentrate deeeeeply on the cue, the black eight, the pocket and the cueball ('7asem), trying my best to have them aligned on the correct (virtual dashed line), I then hesitate and give myself a break by sharpening the edge with a piece of chalk, again, I concentrate, think and make a shot, most oftenly, missing the pocket.
Once upon a vivid day, and after some heavy experience, and while on the table, a sudden feeling of confidence came upon me that made me shoot without thinking and made me score just by blinking. No thinking at all, just used my hidden senses to score, score, score. Yippeeee YaYoe! Something happened there, I'm not sure what it is, but I think somehow my experience managed to slip inside the subconcious part of my brain for a while.
I think this what happens with professional football players, or basket ball players, or tennis, or ping-pong, or even judo, jujitsu, guitarists, all the professional people every where, they just do it without thinking, they are experienced enough to an extent that they are able to make moves and decisions without thinking.
I wish I can become like that one day, actually, this happens to me when I'm writing HTML code, it always compiles(1) without any errors.
ref(1): HTML is the only language that compiles without errors.
Once upon a vivid day, and after some heavy experience, and while on the table, a sudden feeling of confidence came upon me that made me shoot without thinking and made me score just by blinking. No thinking at all, just used my hidden senses to score, score, score. Yippeeee YaYoe! Something happened there, I'm not sure what it is, but I think somehow my experience managed to slip inside the subconcious part of my brain for a while.
I think this what happens with professional football players, or basket ball players, or tennis, or ping-pong, or even judo, jujitsu, guitarists, all the professional people every where, they just do it without thinking, they are experienced enough to an extent that they are able to make moves and decisions without thinking.
I wish I can become like that one day, actually, this happens to me when I'm writing HTML code, it always compiles(1) without any errors.
ref(1): HTML is the only language that compiles without errors.
Subscribe to:
Posts (Atom)