programming

WALP (We Are Lazy People)

alfasinLeave a comment

laziness

Yesterday, one of my colleagues reminded me that I once said that I’m going to do the minimum to maintain project X. Project X is not its real name but maybe I should back up a few steps and start with providing some background:
one of the things that happens at Netflix pretty often is that teams change, responsibilities shift and as a result projects are handed off between teams. Project X is such project, it was written long time ago (more than two years back which is basically forever in our industry) by a guy that now manages another team, and was handed off to a team that currently doesn’t exist, and when that team was disassembled I was given this project.

So yesterday, the guy who wrote project X reminded my that I said I’m planning to do the minimum to maintain it. I was surprised because one of the things that doesn’t fit me is to come up with such a statement, and then I remembered: WALP.

Some people will describe it like this, but I just rather say that I’ll do the maximum to be in a condition where I have to do the minimum in order to maintain an existing project. Sounds confusing ? well, not really…

Project X was written in Python and had two major components (class-files) which became monolithic: functions that perform multiple tasks (which goes against SRP) with hundreds lines of code, a few levels of nested loops – complicated to follow and understand, a nightmare to debug and horror to test.

So, in order to be able to “do the minimum to maintain it” one of the first things I did was refactoring these two classes: breaking the logic into smaller functions, minimizing the number of arguments, working according to DRY and SRP, renaming variables and functions, adding unit-tests and while I was “shaking the tree” a few bugs were discovered and fixed as well.

There wasn’t much “fun” in it, it’s not like writing a project from scratch which is really tempting to most engineers but usually is a bad idea. It’s tempting because you think “I’ll get it right this time” or “I can do much better than that” and let’s be honest: when you’re maintaining someone else’s code – it will never “belong” to you, that other guy will always get the credit for writing this project – even if the code changed so much that it doesn’t look anything like it originally did…

Back to the story, the refactoring paid off, and it wasn’t even in the long term:
* a few bugs were found and fixed
* bugs that were discovered later on, were easier to debug and fix
* I had to write a few additional features, all were implemented very quickly, easily, without any pain and were easy to test

So yes, I AM lazy, and I’m willing to work really hard to sustain it…

WALP (We Are Lazy People)

20 Tips for becoming a better programmer

alfasin, Leave a comment

1. There should be only one single exit point to each method (use if-else whenever needed).

2. When using if-else, make sure to place the shorter code snippet in the if:

if (cond) {
   
}
else {


...
...
.
.
.
}

3. Do not throw exceptions if you can avoid it, it makes your code much slower, if you feel like throwing something and then catching it – go play ball with your dog. If you don’t have a dog get one – they’re awesome!

4. Do not try to do many things on the same line – when you’ll get an error – it will be harder to debug, example how to NOT write your code:

String result = hasInformation()? getState() : (hasMoreInformation() ? getOtherState() : getState());

5. Look for code pieces that look the same and if you find any – refactor!

6. Meaningful names are a must. If you’re not sure, meditate on it for another minute. Still not sure? ask your colleagues for their opinion.

I’m still shocked everytime I find out that the following is not common knowledge:
7. Whenever you can use HashMap instead of List/Queue – use it!

And on the same note:
8. If you can use caching instead of I/O (usually DB) – use caching

9. If a nice and simple regex can do the job – use it!

10. Do not use regex for parsing (for example: HTML/XML/json) – there are special tools for that in every language, for example in Ruby, Java etc.

11. Print to Log. You should have at least two levels of logging: DEBUG and ERROR. The latter should be the default. Nice tip: you can send your self a text when a critical error occurs, by sending an email to your_mobile@your_carrier – look here for more details.

12. Use stackoverflow – not only for asking questions: Take a few minutes, every day, and try to answer questions – you’ll be surprised how much you’ll learn from it!

13. A rule of thumb: if your method is over 50 lines – split it. If your class is over 500 lines – split it. If you think you can’t split it – you’re doing something wrong. This recommendation is a “language dependent” and shouldn’t be taken “as is”: while 50-line method feels natural in Java/C# – it will be considered very long in more expressive languages such as Ruby & Python.

14. Writing a code which is “self explanatory” is great but also very hard, if you’re not sure how “obvious” your code is – use code-comments.

15. When writing code comments always assume that the reader doesn’t know what you’re trying to do. Be patient & explain. No one is going to *bug* you because your comment was too long…

16. You want to improve? read books, blogs, technical online newspapers join relevant groups on Linkedin, update yourself with the latest technologies, go to conferences, got the point ?

17. Practice makes perfect: solve code-challenges, join hackathons, go to meetups etc

18. Experiment with different IDEs until you find the one that “feels right”, study it carefully and make sure you know the major features (including plugins). Tune-up the keyboard shortcuts – it will make your workflow smoother.

19. Whenever you find a bug, before you fix it, write a unit-test that captures it. Make sure it does.

and my favorite:

20. Don’t get lazy – RTFM

We’ll finish with two quotes:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
– Brian Kernighan

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
– Rick Osborne

Update:
Many thanks for Jeff Grigg, Tom Burton and Keith M. O’Reilly for their feedback which helped me improve this post – cheers!

20 Tips for becoming a better programmer

Silicon Valley CodeCamp

alfasin, , Leave a comment

I know it’s totally geeky, but I’m excited about the CodeCamp this weekend as if I was a kid that his parents are taking him to six-flags…
There are so many interesting sessions, all the timeslots have at least 3-4 talks I’d like to hear…

On a totally different note, there’s a new video-clip that drives everyone crazy calledGANGNAM STYLE and naturally, many people created their own version. LOVED it!
Have a great weekend guys, I know I will ;)

Silicon Valley CodeCamp

What’s the most important thing a small start-up should do?

alfasin, Leave a comment

A small company called Laminar Research, a creator of a flight simulator got sued by an even smaller company called Uniloc for IP infringement. Now, the company I work for, used to work with Uniloc for a couple of years, integrating their license-management solution into our product. Around December 2010 they stopped supporting their product and I believed (until recently) that they were shut down.
Well what do you know? it seems that since they stopped developing and selling their product – they started making the big bucks – sounds weird ? not at all!
Apparently these guys, which are located in Luxembourg, finally found a good way of making money without any hard work: by suing!

The “IP” that Uniloc claims that x-plane (and previously Microsoft) infringed can be described as follows:
“A registration authority communicates with the electronic device. The registration authority has a database of verification data for verifying the license data stored on the licensing medium and provides updated license data to the licensing medium.”

Basically what it says: the patent is of a “LIVE” authentication of a license-key with a license-management server (over the web).

Sounds unbelievable?

After hearing the BS that Apple used against Samsung (for copying features like “pinch and zoom” and the “bounceback” effect), it doesn’t sound that weird anymore. So I’m probably naive, but I still can’t believe that anyone would approve a patent for authenticating against a server.

If you want to read more about Uniloc vs. Laminar Research, you can find the details of the lawsuit here.

Now for the important part: if you have a small start-up, how can you avoid such bogus lawsuits? cause, you know, the minute you’ll start growing – the blood-suckers will come after you…

Luckily, the makers of stackexchange just launched a new beta: patents.stackexchange.com. So before you start developing ANYTHING, better search patents.stackexchange.com, maybe even post a question!

What’s the most important thing a small start-up should do?

Today’s a good day to start!

alfasin, , , Leave a comment

I’m still not sure what I’m going to do with this space, probably share my thoughts about programming stuff, maybe add some cool code examples such as the following code to quick-sort in Erland:

qsort([]) -> [];
qsort([Pivot|Rest]) ->
qsort([Front || Front <- Rest, Front < Pivot])
++ [Pivot] ++
qsort([Back || Back <- Rest, Back >= Pivot]).

Now, here’s a small example of how NOT to write code, the example is in PHP:

public function pdf_read_root(){
   $this->root = $this->pdf_resolve_object( $this->c, $this->pdf_find_root());
}

This line of code is wrong. very wrong. Let’s see why:

    • Even if we don’t know why, the fact that $this-> appears 4 times in the same line should raise a red-flag!
    • Since pdf_resolve_object() is a class method, it has direct access to all the members so we shouldn’t pass class-members in the signature: pdf_resolve_object( $this->c, $this->pdf_find_root()).
  • From the same reason, this method does NOT require a return value, it can update$this->root inside the method and just return.
  • $this->c ? what about a more meaningful name ?
  • And last, why should we wrap this one line that calls to a method with another method that does nothing: pdf_read_root()?

To sum up, we can easily change this line to something much nicer, such as:

$this->pdf_resolve_object();

Ta-ta till next time.

Today’s a good day to start!