“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!
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 had I given the chance (education) to become one. 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, if I will be working with one.
“… 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.
(I intend to someday become an expert on some frameworks of course.)
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.
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.
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. Another reason is because “a well-crafted code base makes me happy to go to work every day”. Another reason is pride. Another reason is because 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.
… 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.
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.
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.
… (have you noticed that I did not include CSS in my résumé?) But I managed to work on UIs in all of my previous works, 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.)
… But a coleague of mine once said that it is just almost the same as clicking the build button in an IDE.
So if I am tasked of deployment and no one else is to guide me, I will just google how to do it.
Today, perhaps the only method I have in mind to honestly estimate the time to be spent to finish a project is to do at least two of the most important features of the app, then use the time spent on those two features to estimate the time that will be spent on the whole project.
But even then, my estimates might still be far from accurate.
When it comes to security, I only know about SQL injection, and I know that it can be prevented by not using string concatenation when building SQL queries. But even though I know that using string concatenation is wrong when building SQL queries, I still do it sometimes — when I’m tired or bored, and there is an existing code in the project that I can just copy-and-paste. But if you already have a set of guildelines for coding which I need to follow, or you practice code review or pair programming, then this will not be a problem.
Oh, I also know about not storing passwords in plaintext, but instead hashing them before storing them. And I also know about not sending forgotten passwords to users (because, of course, if we do not store passwords as plaintext, we will not know what password to send to them), but instead send them link to a form/resource that will let them change their passwords.
I also read in the past about Cross-site Scripting (XSS) and Cross-site Request Forgery (CSRF), but I have to review them to bring them back to mind.
But I have a copy of the book “Foundations of Security: What Every Programmer Needs to Know” (but I have read only some chapters from it). So if you need me to become familiar with software security when working at your company, I can start with this book (or with any material you can recommend me to consume).
Thank you for your time!