Anti-Résumé

“People don’t walk around with anti-résumés telling you what they have not studied or experienced (it’s the job of their competitors to do that), but it would be nice if they did.”

— Nassim Nicholas Taleb (from “Why You Should Surround Yourself With More Books Than You’ll Ever Have Time to Read”)

This anti-résumé (together with my résumé) will help me find the best job that fits my current skillset, and it will help you in determining if I am fit for your team or not. That would be win-win for me and you! :blush:


I never experienced being an Algorithmer

In my résumé, I considered myself as an Initiate, based on Terence McGhee’s “Software Ninja Class Hierarchy”. But I never experienced being an Algorithmer, even though it is much lower than the Initiate in that hierarchy — I do not have special knowledge in higher mathematics. My weak mathematics background is the reason why I concentrated on learning how to build what they call line-of-business (LOB) applications (or what is called “representational-transactional systems” here), because these things do not need lots of knowledge in mathematics.

But I can work with an Algorithmer, and I have high respect for an Algorithmer, because I would have liked to experience being an Algorithmer if I had the chance or education to become one when I was younger…

And I believe that working with an Algorithmer will benefit me — I believe that I will learn a lot from an Algorithmer. I’m hoping also that an Algorithmer will learn a lot from me too, if I will be working with one.


I’m not an expert on frameworks

“… Here’s a possible surprise for you. I am not going to recommend that you need to become an Entity Framework guru. Nope, just the opposite in fact. I am going to suggest that you allow the Entity Framework development team to be the gurus, and you just focus on your specific application. After all, your Core Domain is where you want to put your creative energies, not in becoming an expert in Entity Framework.”

— Vaughn Vernon (from “Modeling Aggregates with DDD and Entity Framework”)

You might say, “What! Frameworks are the ones that make us do our work easily and fast! Why are you saying that being an expert on frameworks is not important?”

Wait!… I am not saying that being an expert on frameworks is not important. What I am trying to say is that, in programming, there are more important things to focus on than being an expert on frameworks — such as separating the business rules from the other parts of the system. The business rules in a system are not googleable, so I believe that it is very important to separate them so that it will be very easy to locate them when fixing bugs.

You might ask what my excuse is for not being an expert on frameworks…

My excuse is that frameworks change very often and I do not have all the time to catch up with all the changes. Also, many years ago in our school library, I read this from a book called “The Magic of Thinking Big”:

“It is more important to use your mind to think than use it as a warehouse for facts.”

“The ability to know how to get information is more important than using the mind as a garage for facts”

Today, we already have [the] google [search engine] which can serve as our garage for facts. We have StackOverflow too! And we have documentations for the frameworks we are using that are readily available online.

I would rather spend my time learning about how to write clean and decoupled code, and learning about software architecture and design, and learning about the domain of the project I am working on, than being an expert on frameworks.

But like I said above, I’m still willing to read and study more about a specific framework when I think my job requires a deeper knowledge of that specific framework. :blush:


If your codebase is messy…

The biggest obstacle to improvement in large codebases is the existing code. “Duh.” you might say. But I’m not talking about how hard it is to work in difficult code; I’m talking about what that code leads you to believe.

If you spend most of your day wading through ugly code, it’s very easy to believe that it will always be ugly and that any little thing that you do to make it better is simply not worth it. You might think, “What does it matter whether I make this little peice nicer if 90 percent of the time I’ll still be working with murky slime? Sure, I can make this piece better, but what will that do for me this afternoon? Tomorrow?”

Well, if you look at it that way, I’d have to agree with you. Not much.

But if you consistently do these little improvements, your system will start to look significantly different over the course of a couple of months. At some point, you’ll come to work in the morning expecting to sink your hands into some slime and discover, “Huh, this code looks pretty good. It looks like someone was in here refactoring recently.” At that point, when you feel the difference between good code and bad code in your gut, you are a changed person…

— Michael Feathers (p. 75 of “Working Effectively with Legacy Code”)

I would love to work on new projects where I will have influence on the decisions about the structure of the project (or at least I know the reasons behind the chosen structure), and whose codebase is kept clean from the start.

But most software systems in existence today are in the maintenance phase. And I’ve seen systems in the maintenance phase whose codebase is very messy. It’s so hard to work on such codebases, and I would love not to work on such codebases. I even thought to myself before that “I will never work on any messy codebase again”.

But my attitude towards messy codebases somewhat changed after I read this from an article written by Jonathan Boccara (“The Right Attitude to Deal with Legacy Code”):

I think it is important to recognize that legacy code is not the enemy.

In fact, in most cases, we’re here thanks to legacy code. The early stages of a given project were where it started to grow, capture clients, build up financial interest, and establish a brand that inspired customers. All of this was done with code that may happen to still be around today and that still performs the functionalities that your customers liked you for in the first place. This is legacy code. As its name states, this is your legacy. Without it you would probably not even be getting paid today.

“… consider that the code you’re working on is your code. Even if you haven’t written it yourself, and regardless of how good or bad you think it is, this is your code, and you have responsibility over it.”

Because of that, it’s okay for me to be involved working on a legacy (or messy) codebase on one condition: If you are going to hire me to work on a messy codebase, I will stay working on it for a long time only if the current team involved in it (which will include me) are cleaning it up (or intends to clean it up) bit-by-bit as they work on it daily. :smile:

(If I’m the only one working on the codebase, then I strongly request that I be allowed to clean it up bit-by-bit… except maybe when it is too messy that I do not know where or how to start, then I will not be able to clean it up.)

I’m not saying that I’m already an expert in cleaning messy codebases. I’m not. But I’m studying to be good at it too. And one of the reasons why I want to be part of a team who wants to keep their codebases clean is that I want to learn from them; I want to learn their techniques of cleaning up codebases; I hope they can also learn from me. Another reason why I want the codebases I will be working on as clean as I can make it is because I do not want the programmers who will inherit my codebase to spit lots of WT*s while working on it in the future. :grin: Another reason is because “a well-crafted code base makes me happy to go to work every day”. Another is pride. Lastly, if I stay long working on a project, there might arise a problem someday which will be hard to solve, or will take very long to solve, if the codebase is messy.

Okay… That’s my condition before I will agree to work on a messy codebase. I hope that is okay with you. :blush:


I’m introverted

… Which means that I might be very silent on my first encounters with a person, but will start to speak up when I get comfortable working with that person. :blush:

But there are times where I tend to be not that silent even with people I do not know when the topic of a conversation is something I’m very interested in, such as programming.


I’m not (yet) very good with my spoken English

English is not my native language. So for me, writing in English is easier than conversing using it, because when writing I have lots of time to think on what to write. When conversing using English I need to respond quickly and there is very little time to think. :grin:


I’m not very good with UI (and UX)

… but I managed to work on UIs in all of my previous jobs, so I believe I can still manage to work with UIs when I work with you.

If I will be working with a UI/UX designer, I believe that he will not be having a problem working with me because I intend to decouple my code from the UI (if possible*), so that my code will not be very affected by UI changes, and the UI will not be very affected by my code changes.

(*Please understand that if a codebase is a legacy codebase, and is messy, it might take time before the coupling problem can be fixed — if you want it to be fixed and if it is not beyond my capability to fix it.)