Behold, my new blog entry in XRDS: Language Bureaucracy
Laziness, impatience and hubris are the three great virtues that each programmer should have, at least according to Larry Wall . My experience so far showed me that he was right. All programmers have these characteristics, if they do not, usually they are not real programmers. Since they are expressing these values with the usage of several programming languages, they tend to compare them. Usually this comparison ends up with a phenomenon called flame wars …. read more
and a small article I recently wrote and published in LinkedIn: Revenge of the SQL
The mainstream is always under attack. So is SQL and in general the various RDBMS’s that implement its various incarnations. After the golden age of MySQL and the LAMP (Linux-Apache-MySQL-PHP) stack, various NoSQL databases appeared, preaching that the data storage as we knew it was coming to an end … read more
I have a few ideas in my drawer and plan to write a few more and revisit some older ideas. Stay tuned.
If you have an old enough mac computer (with mavericks) and you try to download the “free” version of iMovie, you need to pay 13.99 euros. Nice, huh.
Maybe they could have calculated the iMovie price along with the mavericks upgrade fee, because right now it is quite funny to pay 25 euros for the operating system upgrade, and 13.99 for the iMovie only (I will comment that all the pages, number etc are also free for only the new mac computer owners).
Today I posted my initial blog entry on XRDS blog. I am very happy and proud joining this group of brilliant people. Let’s do stuff that matters!
Based on a true story …
You are a software engineer. Great! You have already worked on numerous low-impact, low-innovation projects and now you have polished your skills and want to work with the big guys. Large teams in various corporations that all want to deliver a big and very complex project. Your job is to design and implement a software component that does serious business. A software component that will save the world, maybe.
For that task you are using all the gizmos that a software engineer could want: version control systems, modern software development methodologies, bug/issue tracking systems, wikis, complex IDEs and many more. Those resources are the easy ones to pick, the one that are under your control.
What you cannot select is your co-workers (at least at this stage). Most of them will be honest, hard-working people that at first are eager to cooperate with you (at most times) and help you surpass all the hardships of modern software development.
When they don’t, you have to be careful and remember: “do not fall to the dark side of the force”. This order will help you to mentally prepare for these situations, expose the behavioral patterns of such people, and make you keep the hatchets deep buried and get the task done.
The Standards Zealot
Those are people that like coding standards. Oh, they love them. In fact, they love almost every document (in electronic form or not) that can be described as a “specification”. They think we must follow them, because the standards offer a common way of doing things. You know what, they are right. But like all religions, there are some followers that want to make big issue about minor things. For example, let’s consider that you do not follow the naming convention in some variables or you are forgetting to leave a double space after each class declaration in your Python code. They will be the first to remind you that you are wrong. They tend to focus on regulations and coding standards and not on the job that needs to be done.
Tip: Ignore them. Ok, it is nice to follow a coding standard, but it is not the end of the world if you accidentally forgot that empty line at the end of the source file. Sometimes they have something interesting to say, but in most cases tend to focus on the irrelevant. Do not forget to fix those discrepancies though and do not begin a flame war with them, you can lose a day and achieve nothing.
The Cowboy Programmer
The cowboy programmer is a guy that thinks he is alone in the whole project and maybe in the universe. He usually commits and break the code of others and if you ask him the answer is one: “I think the changes were necessary to achieve the required functionality”. Cowboy programmers think their way is the only way. They tend to simplify things they cannot understand and over-engineer things they found exciting. In addition, they drop commit-nukes. They work silently and will try to avoid revealing their designs and code, until it is too late.
Tip: Do not try to explain things to them. It is a big waste of time. Instead, contact their manager (the sheriff for that matter) and make them follow a formal commit-review-testing process with his support. Enforce unit testing on the development process and make them revert their unwanted changes themselves. Be careful, they are prone to engage in commit wars!
The Comfy Developer
This is usually a guy that wants only to make a living by his profession. No, he does not want to create a superb system and he could easily write in Visual Basic 6.0 until his retirement, if that would afford him a steady income. He knows one way of doing things, he will not experiment and he will absolutely do nothing, unless it is strictly required. When you try to talk to him, he is eager to listen but less eager to do anything outside his comfort zone.
Tip: I like those guys and I usually want to see them write boiler-plate code. They are born to do it. Do not intimidate them, but try and explain what you want in a relaxed and polite manner. They will sometimes break the code in the repository, but no worries, they will help to fix it. Just tell them. Take them by the hand and point the way to the right directions, they will follow.
The Technology Expert
Those are software engineers that know an area of technology very well. If their expertise can be used in the project, then you are lucky. If not, they will eventually compare everything with the technology they know. Do not try to convince them about flaws related with their area of expertise. They will not believe you, cause they are the experts after all!
Tip: Usually, those kind of people are there when their expertise is related to the project. Exploit them! Do not engage on big talks with them, unless you have the guts to hear all related terminology in 10 minutes talk, just ask them specific questions and get specific answers on corner cases.
The Systems Guru
There is a category of software engineers that have more experience with systems and scripting than in software engineering formalities. These are great guys, but they have two big flaws: they do not respect software development processes and they tend to use whatever tool makes their job right. This usually ends up on causing inconsistencies in the build and testing process, along with many unwanted dependencies. They act like commandos, they can save the day, but they cannot be restrained easily.
Tip: Never ask their advice regarding technologies, they tend to go where the wind blows, and their advices are focused on just answering the question, not answering the question in the context of the project. Let them work on the tools that support the development process, but not on the project itself. Do not, at any circumstances, engage in a flame war with them.
The Hitman Coder
Usually contractors, coming from other companies temporarily to give a boost to the development effort. They are not loyal and will focus only to the task they are given. They do not like to get into trouble and will avoid to do things that will embarrass them or their employee, typically a consulting company. They value their rate, most of all. In fact of those things, they are usually very skilled and competent. They will answer all your questions with sincerity. They are experts on “task dodging” and they will often try to convince you that this is not their job.
Tip: They will never sacrifice their good name in the market to argue with you. So, use that for your advantage. Exploit the fact that they are very experienced and have worked in various companies to enrich your way of doing things in the software development process. The key is to make them participate and propose things, but do not forget, it is not their job to make the big decisions, nor they will share the burden if they are wrong.
Usually a developer that becomes very intimate with his tasks. He never accepts comments or suggestions from others. These guys live in their fortress, behind close walls, they actually guard their work. Unlike the cowboy programmers they know what they are doing, but since they are humans like all of us, if they are missing something, you will know it when it is very late and it will be very difficult to convince them to change their masterplan. There are some guardians that want to prove themselves to the team and feel important by adopting more tasks than they can handle.
Tip: If you have one of these guys in your team, then you are in trouble. It is then an absolute necessity to adopt an agile development methodology and begin with pair programming and small iterations. Never argue with them, be strict, but polite. Ask them to do things not by asking, but by issuing orders. They are prone to flame and commit wars.
Those are just few types of people you can encounter when you are part of large development effort. Many of them will get on your nerves, but remember you are there to get the job done, not to compete with your colleagues. My advice is, “first listen, then argue”, do your work with professionalism and get results.
Two months ago i was thrilled. I discovered that Alfred Brendel was coming to Greece, in Athens, for one of his recitals (btw the announced that he will be retired after his scheduled performances in 2008).
I went with my friend Dimitris and bought our tickets and then waited for the big day. Alfred Brendel was scheduled to play Haydn, Schubert, Mozart and Beethoven. The detailed program follows (played in that order):
- Haydn: Piano sonata in c minor, Hob. XVI:20
- Beethoven: Piano sonata No. 31
- Schubert: Improptu 1 & 3
- Mozart: Piano sonata K457
At last the time had arrived, i went to Athens Concert Hall, sat patiently at the designated seat and waited to enjoy the recital.
The first 10 seconds was extremely wonderfull, then the audience decided to transform the piano recital to a piano concerto, and the orchestra (orchestra of coughing i’d say) was the audience and their coughs. When Mr. Brendel ended playing the first sonata, he actually noted that “there is a constant noise from the audience”. He continued to perform (he seemed irritated), but no-one seemed to bother, since the coughing continued.
After the break, the audience creativity really reached the sky. I heard people sneezing, modile phones, doors closing, personal items dropping, people chatting, and some others just playing with their bags producing a variety of noises. One lady (very old) fell asleep during the performance and she dropped her walking stick.
The disrespect for Mr. Brendel continued and after the end of performance. When the recital ended, and the audience applauded (in excitement, maybe because Mr. Brendel passed the test of patience, performing in front of uncivilized baboons), some of them left the hall. The problem with that was that the performer was still thanking the audience. This situation continued (people left all the time) for a few times, and since the applaud continued, Mr. Brendel played a bonus piano piece. Then the recital ended.
I really have to congratulate Mr. Brendel for his performance and patience and i must really say a very HUGE “SORRY” for the disrespect that the audience showed him (when he commented the noise fact, i was really ashamed). His performance was divine, and i cannot imagine what he really could offer, if he played in more friendly environment.
“The statistics on sanity are that one out of every four Americans is suffering from some form of mental illness. Think of your three best friends. If they’re okay, then it’s you.” — Rita Mae Brown
- Commander, you know everything about your stone garden. But clearly, you have not spent nearly enough time looking at it.
— Delenn to Sinclair in Babylon 5:”The Gathering”
- And so it begins.
— Kosh (to Sinclair), “Chrysalis”
- I am a scientist. Nothing shocks me.
— Indiana Jones in Indiana Jones and the Temple of Doom
- A programming language is for thinking of programs, not for expressing programs you’’ve already thought of. It should be a pencil, not a pen.
— Hackers and Painters, Paul Graham
- Win, lose or draw, this thing’s going to know it was in a fight.
— Garibaldi in “Infection”, Babylon 5
- Our situation has not improved.
— Henry Jones, Indiada Jones and the last crusade
- Make everything as simple as possible, but not simpler.
— Albert Einstein (1879-1955)
- We are not retreating – we are advancing in another Direction.
— General Douglas MacArthur (1880-1964)
- Research is what I’m doing when I don’t know what I’m doing.
— Wernher Von Braun (1912-1977)
- Wit is the epitaph of an emotion.