Top 12 Things Likely To Be Said By A Klingon Programmer

found originally at  Courtney Hentz (CHentz@spinner.com)

1. Specifications are for the weak and timid!
   
2. This machine is a piece of GAGH! I need quad PowerPC processors if I am to do battle with this code!
   
3. You cannot really appreciate Dilbert unless you've read it in the original Klingon.
   
4. Indentation?! I will show you how to indent when I indent your skull!
   
5. What is this talk of `release'? Klingons do not make software `releases'. Our software `escapes' leaving a bloody trail of designers and quality assurance people in its wake.
   
6. Klingon function calls do not have `parameters' - they have`arguments' - and they ALWAYS WIN THEM.
   
7. Debugging? Klingons do not debug. Our software does not coddle the weak.
   
8. I have challenged the entire quality assurance team to a Bat-Leth contest. They will not concern us again.
   
9. A TRUE Klingon Warrior does not comment his code!
   
10. By filing this bug you have challenged the honor of my family. Prepare to die!
    
11. You question the worthiness of my code? I should kill you where you stand!
    
12. Our users will know fear and cower before our software! Ship it!Ship it and let them flee like the dogs they are!
    

Documentation Specialists

*** UPDATE Dec 20, 2010, We ended up using the tool MadCap Flare. I'll post some pros and cons later ***
So, we just hired a new documentation specialist. We're looking at a tool named Help Studio. If anyone has any suggestions please let me know.


I intend to treat her as any other developer (a pig). Currently our workflow is: Engineer Resolves Case to QA and QA Closes case. The new workflow that we will try out is: Engineer resolves case to Documentation, who then resolves to QA, who then closes.

Over the next couple of weeks I will write more about how things work out.

From SVN to Mercurial: Part 1

Recently, we have begun dividing our work amongst several teams on different branches. This prompted us to start moving from Subversion (SVN) to Mercurial.

We have actually had great success with Subversion (SVN). We moved from CVS several years ago and have never regretted it. With it's improved rename and move support and cleaner branching SVN was an easy decision.

Now we find ourselves, once again, pinning for the capabilities of a Version Control System that we don't have. We are also in the throws of moving build servers from Luntbuild to Hudson. So, over the next few posts I'll discuss our experiences with moving from SVN to Mercurial.