Big Ball of Mud

Anti-pattern: Time Machine

The nature of version control keeps track of every change in the source code give software technology team a perception of version control can be used as a time machine.  Thus you’ll hear the saying like “I should be able to check out any version of the history and reproduce the system at that point”. However, at a very general level, especially for modern commercial systems, such a time machine is an illusion.

Modern commercial systems usually constituted of multiple data sources, components,  dependencies, and connections to the outside world. Just by checking out the source code of the system itself is far away from sufficient to reproduce a pass version of a system. For example, it’ll be very hard to roll back the multiple data sources to that specific point one is looking for, let alone sometimes these data sources are external and you don’t have full control of. Another stronger case is when the systems rely on external APIs, such as Facebook or Twitter or whatever black-box-vendor the systems depend on, one won’t be able to roll back the entire universe.

Noted the above argument is based on a very general level of assumption. For the specific case-by-case basis, one can absolutely construct a time machine to travel back and forth in a small scope. And version control can be the backbone of that toolbox. But such a practice shall have a strictly defined boundary, and be knowing what this practice is capable of and what it is not.

Without the value of version control being our time machine, what’s the primary purpose and value of version control then? It’s a collaboration and audition tool, just like bookkeeping in finance. You can audit what had happened in the source code back in the history, and also easily share the every state change in a codebase on a larger scale team.

Thus I conclude: On a general level, bending version control system to work like a time machine is an anti-pattern. It’s an unrealistic expectation for a collaboration and audition tool.

Big Ball of Mud

calculate sum and average of lines of number

Assuming a file contains a bunch of numbers, one number per line, like this:


One can easily calculate the sum and average of all these numbers, by using awk:

cat numbers | awk '{sum += $1; count += 1} END {print "sum:" sum " avg:" sum/count}'


Big Ball of Mud

Copy current git branch into pasteboard (the Clipboard) on Mac OS X

git branch|grep '*'|tr -d '* \n'|pbcopy

Big Ball of Mud

How not to conduct a bad technical interview

This note is primarily written for myself to reference. Most of them are the mistakes I observed (and still remembered of course) during the software developer’s technical interviews. I don’t expect it has any commons with your situation, but if you figured something useful, it must be a coincident.
  • Interview is not a process to prove you are better than the candidate, is a process to find out the candidate is better than you in what ways. Only the people understand this can level up their teams. Those who trying to smash down candidates? Their teams getting worse and worse because they hire the people worse than they are.
  • Don’t try to bend the candidate’s mind into your way of thinking. If you are doing that, then you really have a problem on your end, but not the candidate’s. Everybody should be encouraged to use their own way to solve a problem, that’s where creativity come from. Give them a problem to solve, can be big or tiny, then watch how they solve it, challenge their solutions, but don’t guide them, lead them or force them to think exactly in your way. I suspect even you can’t prove your way is always better than theirs in all situations, can you?
  • Allow the candidates to find shortcuts in your test if they can. If your test is miserably gamed, admit that is your fault(silently to yourself) and refine your test next time. Because you are the one have lot of time to write the law upfront, you should be well prepared. If there is a grey area, it’s your responsibility to fix that, but not abusing your power as a interviewer to ban the candidate exploit your test in just a few minutes. In fact, if that happen, I would say it shows the candidate in better than you in some ways, go and find out and give them credits for that.
  • Give more practical problems you encountered or solved to test the candidates rather than puzzles. Unless you are hiring people to solve puzzles all days for you. Because there is a little overlap but there is no correlation between the ability to solve puzzle and the ability to work out actual problems. The hard part for interviewers is to understand what kind of people they need to hire. Only the interviewers understand that may able (but not necessarily) to test the right aspect they need from the candidates. Then you should design the test specificity for the position or type of people you want to hire.
  • The key thing many people don’t agree with, or they refuse to accept, or they never know, or they don’t really understand what it means is: EVERYBODY ON THIS PLANET HAS GOOD SIDE AND BAD SIDE. The beauty of us comes with a dark side, and the other way around. You could figure out the issues of a candidate, but remember the good side of this person also, the issues of this person is the price you have to pay in order to get the good side from him/her. Of course you may choose the good things you want among a bunch of candidates, but remember any good thing always come with a price and consequences, and you have to learn to live with it. Those who can’t live with the bad things do not deserve, and cannot own the good things. There is no way to get around this natural law, there is always ups and downs, pros and cons, this is how our world is designed (by God or whatever you believe in). Of course you may challenge our nature, it doesn’t matter you don’t believe it or don’t accept it or don’t know it or don’t want to hear about it, it’s the law that always going to bite you. Focus on the good things you really need, and ready to pay the price for them.
  • Keep improving your interview questions, make them fun and challenging. Because when you ask questions, it’s actually an indirect way candidates interview you. There are many people out there just by listening the quality of the questions you ask, they’ll be able to somehow figure out the situation on your end.  The quality of your interview questions is another way to attract talents.
  • Prepare for the surprising questions from the candidates if you allow them to ask you questions at the end, such as: What is the weakness about your business; What is the thing you don’t like about the company/team; Do you really like to work in here; Do you think if he/she will qualify for the position, etc. It’s you decided to give them a chance to ask you question, see that as roles switch: Now it’s the turn they interview you.
  • As it mentioned above, you can somehow extract more information about the candidates by listening the questions they ask. An important kind of thing you can learn, for example, is what is the candidate looking for. What they are looking for will reflects on the questions they ask. Even though it’s the time they ask you questions, don’t lose your attention, both sides are still interviewing each other in an indirect way.
  • Ask the feedback about your interview from candidates when it’s done, and learn to interpret the words they said. Such as if they say your interview is “standard”, that means it’s boring as he/she expected. You’ll be surprised how much you can learn to improve your interview just to hear the people you interviewed.
  • The last one is for those places have very strict non-discrimination act such as the U.S: Unless you know for sure you can afford to risk your time and money to getting into a legal battle, during the interview, don’t ask too personal questions or any questions that can lead to disclosing too much of candidates personal information. An example is if you ask: Tell me something you would not tell your friends or you don’t want people to know about. Well, think about this, if the candidate answer: I’m a homosexual, I’m a republican, I’m a Christian, my mother is a black, I have HIV…Then you are in a very bad situation: If you don’t want to hire him/her due to any other reasons, he/she may sue you for discrimination with every single word above. Of course, if you really die hard to know the candidate’s personal life and insist that’s the only way you can figure out if the candidate is culturally fit, have your attorney ready to back you up.
Big Ball of Mud

Flattening an array in JavaScript

If you have an mutidementional array(or nested array) you want to flattern, you can do it this way.

var flatten = function(array) {
  var result = [], self = arguments.callee;
  array.forEach(function(item) {
      Array.isArray(item) ? self(item) : [item]
  return result;

So now you can run it

//The result of
//Should be
[ 1, 2, 3, 4, 5, 6 ]