Home > software engineering > The Story of a Hope-Driven Developer

The Story of a Hope-Driven Developer

May 19th, 2008

A fictitious story about a fictitious “hope-driven” developer… In a sense, it’s fictitious because there’s probably no one single coder exposes all these behaviors of being hope-driven. On the other hand, it’s not hard to find one who frequently displays one or more of these behaviors. Anyway, let’s now travel into the mind of our fictitious hope-driven fellow…



I am a hope-driven developer. I am superior and productive. I love coding and I’m different from others.

Unlike others, I don’t write unit test for my code. I hope my code will work right because I’m so good at coding. Even in the rare cases when it doesn’t, the QA team should be able to catch the defects easily and I will immediately know what happen to make necessary fixes. I hope I will never have to touch most of the already written code again and if I don’t have to revisit it, what would unit tests help anyway?

Unlike others, I don’t check in compilable code into the source control system very often. Instead, I code it straight for several days (or weeks) until finishing my module before checking everything in. I hope my code will not break any code of others and I hope others’ code won’t cause funny behavior in mine. Besides, my colleagues should follow the architecture design so carefully that there are no integration defects between their components and mine.

Unlike others, I don’t follow coding conventions. I believe people are different and should be respected for that. I am not productive following a coding style I’m not familiar with and it’s productivity that I am getting paid for. I hope my peers will understand my code easily because as I mentioned, I’m so good in coding. But I hope I never have to read that code of my peers because they seem to employ very cryptic styles. (Being as tolerant as I am towards people’ uniqueness, I just can’t understand why somebody does not want to include an “i_” prefix for their variables to denote integer type.)

Unlike others, I don’t write comments. I hope that my code is so self-explanatory that everybody can easily understand. How is it possible that one cannot guess from my highly self-explanatory code as to which the pre-conditions of a procedure are, the exceptions thrown by it, and the logic behind it? After all, it’s written in a really high-level programming language. But why should anybody read my code if it is really so perfect? (Encapsulation and loose-coupling, everyone?)

Unlike others, I don’t learn and use design patterns. I hope that my design skill is so good that I don’t need to learn from any others. Even if it is not the case (hardly be), I hope that design patterns overkill for all my design problems. Besides, my problems, which are very challenging and unique, would have no such thing as a proven solution to them. I also hope that the languages I use are so superior that design patterns are just so irrelevant.

Unlike others, I can only start writing code when having every detail of the requirement spelled out and a detailed design document in place. By having comprehensive requirement specifications, I don’t have to change my code frequently mid-course because of requirement misunderstanding or guessing. I also hope that it would make my customers feel less freely to change their mind because all things having already been written down. And by having a good and detailed design document in place, my colleagues’ code and mine will work together smoothly and automatically because the code are mostly a one-to-one mapping from a good and detailed design.

Unlike others, I look down on the so-called 15-minutes daily meetings, during which people in turn report what they had done, would do, and any problems faced. Everyone should be professional enough to know what they are supposed to do for the day and problems should visible to the right people at the right time without requiring a daily teaming-up. Besides, the works of my colleagues and I are usually so independent that there is no need to communicate so frequently. (Just follow the design document and code your way through, guys!)

Unlike others, I don’t learn new things. I hope that the knowledge that I have gained thus far is sufficient for me to address any coding problem. And as I am so familiar with the current tools, I am supposed to be highly productive with them than I can ever be with any other tools. (After all, it’s a famous person, who I can’t remember the name and is said to write that there would be no silver bullet upon the next decade in the software engineering field. I can’t agree more!)

That’s how I get by. Coding productively and passionately. I typically chunk out a hundred or so lines of code per week and if you take into my multi-year software development career, that is a lot of code. I can’t help but feeling so proud of what I have done…

I love coding and I’m different from others. I am superior and productive. I am a hope-driven developer…

Categories: software engineering Tags:
  1. June 22nd, 2008 at 06:39 | #1

    awsome !!! i love this ?
    i want to translate this to spanish and put in the wiiki of my company.
    Is there any problem?

  2. June 22nd, 2008 at 10:54 | #2

    @Santiago:
    Not a problem, as long as there’s a link back to the original article, you can translate and publish it to your wiki.

Comments are closed.