I hate “how to make a blog in 20min” tutorials

Those tutorials are good to show the potential of the framework when is used by someone that have experience with it. But it doesn’t teach you much about the process of building your own application. And watching a lot of those can damage your perception of the learning curve needed to build something because you think that it’s easy.

I really like the approach of Michaael Haart in his RailTutorial, because he explain all the things that can go wrong and how to solve them. Because that is learning, trial and error. When you start a project by your own, you will have to face a lot of errors.

I told you this because some years ago I tried to learn ruby on rails thinking that it would be easy, I watched the zombie tutorial, tryRuby, and some 20min blog but when I tried to make my own application I felt frustrated and dumb for all the errors that I faced. But then I changed and some month ago I started again, but this time I approached it thinking that I will have to deal with the errors and my own mistakes , and that there is no easy or fast way to learning, just the old Try and Error.

Beat procrastination with Kaizen

The greater the task, the greater the resistence to do it. One way to avoid this is making it in small steps, as small as possible. Do you want to exercise each day for 1hr? Just thinking about it creates resistence, so make a small step, aim to just 1 minute of exercice per day. Maybe while watching TV, or  you can just walk in front of it.

This is Kaizen, a method that you can apply in almost anything. I highly recommend this book  “One Small Step Can Change Your Life: The Kaizen Way

My daily routine consist in 5 minute tasks:

-5m blog writing : Maybe a paragraph.
-5m learning: Some new function
-5m for one of my personal projects: Write some code lines, or fixing a little bug
-5m studying: I like studying with cards, so in 5m  I can make 1 card and reread 3 cards
-5m reading a book: 4 pages

In just 30m per day you can advance in 5 different aspects of your life. It could look small but in a month this means:

-2 o 3 new blog post
-10 new functions
-100 new lines of code and some bugs killed
-30 new study cards  and 30 rereaded
-100 pages readed

And the most interesting thing about kaizen is that thinking about doing the task for only 5 minutes let’s you pass the initial resistance (even thought you might end up spending much more time on it) and enjoy doing something that you might think is dull.

So if you are interested check the book One Small Step Can Change Your Life: The Kaizen Way

Clean Code Book – top 5 tips

Some month ago I read the book: Clean Code, I highly recommend it. Here are the best tips that I found.

  • Boy-scout Law: Leave the campground cleaner than you found it. The cleanup doesn’t have to be something big.  If you have to modify something, try to improve the readability of nearby code
  • Functions:
    • Must be short (5 lines)
    • Better without arguments or less than 2
    • Should do only one thing, do it well, and have no side effects
  • Variables
    • Better with long and descriptive names
    • Be consistent. Don’t use get and retrieve for the same
    • Use constant. Like MAX_NUMBER_LINES instead of just 10
  • Comments
    • It’s better to write a descriptive function than a comment
    • Outdated comments confuse
    • Instead of comment an ugly function, try to refactor it, so it express clearly what it does
  • Classes
    • Small classes (200 lines)
    • Line width < 120

edit: These are my notes from the book “Clean Code” ,Robert C. Martin. I know that some tips are polemic so I wanted to share it to know what others think about it. You can read  clean code articles  by Robert C Martin

edit2: I want to share more info about the “less that 2 arguments” and 5 line functions.

The author says: “The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification — and then shouldn’t be used anyway.”

A really good stackoverflow ‘s thread  about the “5 lines functions”

Today is demo Day!! and then CRASH! (My checklist to avoid it)

Today is demo Day!, you and your team are excited to show to some potential customer, all the awesome things that the new app can do .  The demo start good, but then CRASH!

We all have been there, the bugs like to show up in demo’s day, it’s a software law. But you can avoid it with a simple checklist. This is mine, you can create your own.

1) Before demo don’t touch the code!

This is one of the most common errors. One developer discover a simple bug, then tries to fix it before demo. He fixed it , but he didn’t  test the others 10 scenarios. So of course in middle of the demo, it CRASHES!

protip:  Use Test Driven Development, or at least test your code. So when someone refactor something or fix a bug you have confidence that all the code works as expected

2) Check the demo environment

Sometimes your dev environment is full , there is no more space, so in Demo Time you have a nice error like this: “Storage limit exceeded” . This happened to me when coding some Salesforce Apps.

3) Prepare your demo data

We are awesome and funny coders, we like to put strange names in the records like “ababshaha” or “Bruce Willis” , that is nice but in demo day  it is better to have clean and nice data to show.

protip: While you are coding try to fill the forms with meaningful data. There are browser plugins to automate this or some test tool too.

4) Have a list of what to show (focus on the client).

We like to tell the client that we have an algorithm that work 10 time faster that the old one, but you know what? They don’t care. In demo day focus on the client side, show things that they care. This is usually the opposite of what you care about. For example, you spend two days working on the new and great algorithm to sort things, but the client loved the way that the jquery plugin slideUp some popup (that took you 2 minutes to setup).

5) Bring only the important people to the demo.

If you are the project manager don’t waste developers’ time inviting all the project developers, invite just the ones that can help you.  From client’s side it is also better to have few people invited. If you run the demo using the phone and screen share, it can be really annoying communicating with a lot of people.

I am not a Rock Star developer

Rock is chaos , destruction, go against the order. I love rock and roll but I am not a Rock Star coder

So when I see “ We are a rock band business, ready to take the world, so we need a Rock star developer to rock the world with us”

Well that really turn me off.

If you want to capture  my attention write something like:
“We are two guys and a Girl building our business,  we are looking for a Violinist coder, who execute clean notes, pleasant sounds and harmonious music”