Hey, just checked compatibility of Pithos client with Firefox 4 and uploaded the new version for deployment. Enjoy!
Download Pithos Firefox Extension from here.
Archive for May, 2011
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.
The Guardian
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.
Epilogue
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.
Acknowledgments
I would like to thank Diomidis Spinellis, Marianthi Theocharidou, Dimitrios Mitropoulos, Panagiotis Louridas and Dimitrios Liappis for their comments.
