2014-12-15

Little things I would teach to my younger software engineer self - #6 The "debugger trance"

Looking back at the various stages of my career, I realized I could have learned some basic stuff way earlier than I did.
Even if I missed the original opportunity, all those little skills I acquired late served me tremendously well ever since.

[credits to my colleague Eamonn McManus at Google for reminding me this one and cointing the term!]


1999-me: We have a memory corruption in this LDAP server implemented in C++, I'll figure it out with the debugger, I am sure, it is just a matter of time!

2014-me: A debugger is a really powerful tool but you need to use it only when it makes sense.




It gives you a very thin slice of what is happening in excruciating details. 

Don't get lost in there, often a log statement correctly placed after some general reflection about where the problem might comes from saves you a ton of time stepping through thousands of unrelated lines of code. It also makes you a better programmer because you'll train yourself to stay on top of those pieces of code growing in complexity.

And BTW, you'll never find this memory corruption, it was corrupting the stack and render your debugger useless after stepping through thousands of irrelevant lines, few days later you'll give up. Instead of that, you should have tried to understand the code, reproduce the bug with a reduced concurrency, dichotomize to focus on the problematic area and figure it out for real.

Any tips you would give to your younger self programmer ? Feel free to comment below !

Little things I would teach to my younger software engineer self - #5 Taking unit testing seriously

Looking back at the various stages of my career, I realized I could have learned some basic stuff way earlier than I did.
Even if I missed the original opportunity, all those little skills I acquired late served me tremendously well ever since.





2000-me: Common, I just need to be productive here: I code, try it a little bit, it looks good. Let's ship it!

2014-me: You are headed to a huuuge pain. After a regression during a bug fix for an initial regression you were just trying to fix for another bug on some horrible code you don't even dare to try to improve, you'll finally see the light and read:

Refactoring: Improving the Design of Existing Code by Martin Fowler

I had a huge code quality bump when I settled and consistently affirm that "Untested code is equivalent to broken code".

Initially, unit tests look like a huge waste of time but very quickly it will pay off:

1. It will give you some assurance that your code is at least working as intended. This will save you some exponential time on manual testing as you add complexity in the code base.

2. It will save you a huge deal of time when you gonna refactor or improve the code base.  The unit tests will tell you instantly what might have been impacted by your last change.

3. It will force you to write single-purpose modules or classes or functions. Once you start to bloat your code, you'll notice it quickly as it will become very hard to come up with a test for it.

Oh, and another tip before you go, when you'll see the light you might become a little bit over-enthusiastic about it. You'll see 100% of code coverage as the holy grail. But no, not really, the last 10% gonna be sooo painful to get and will not add anything quality wise. Test only ~80%-90% of the critical code you know is interesting to test.

Any tips you would give to your younger self programmer ? Feel free to comment below !


2014-12-14

Little things I would teach to my younger software engineer self - #4 Life in the console

Looking back at the various stages of my career, I realized I could have learned some basic stuff way earlier than I did.
Even if I missed the original opportunity, all those little skills I acquired late served me tremendously well ever since.


1993-me: What a misery! I am telnetting from HPsUX to a Tru64 and once again my backspace doesn't work!
AGAIN, I'll have to spend hours trying to fix that POS console by trying out random bindings... Enough of this crap ! I give up, I am more efficient with my mouse.

2014-me: Hang on in there! Few years down the road it won't be a misery anymore, Linux is coming! This will put the power of the shell at your fingertips without this pain.

Check out my current favorite combo at the moment:
 zsh + oh-my-zsh + tmux.




Start with a plain zsh to master the basics, browse and take the simple stuff from zshtips for example.

The main goal of all those little commands is composability, this is extremely powerful. A tool that sorts, another one that gives you the n first lines and another one that monitor a command all have a limited purpose but suddenly when you combine them it is magical:

# this will monitor the 50 first
# alphabetical entries from a file

$ watch "sort myfile | head -n 50"

But wait until you have setup oh-my-zsh to start tweaking your .zshrc.

oh-my-zsh is a plugin system that considerably simplify the setup of zsh and gives you some bindings to a lot of integrations like git, docker, python, etc.
For example with git, you'll be able to see the branch on which you are from the prompt, tab autocomplete the names of the branches when you git checkout etc.
Try to have your console emulator work with 256 colors, it will look less aged.

The last thing is tmux. This is a terminal multiplexer. It serves 2 main purposes: 

1. make your sessions persistent (you loose your ssh connection, you reconnect and magically your session is still there)

2. be able to use several shells/programs from the same session.

For example I use vim on top of a "pane" (a kind of textual window) that I run in server mode. On the bottom I use zsh and I can type vim file.txt and my alias will open it straight on the vim on top, it is almost like an IDE / shell hybrid. See the screenshot above.

Any tips you would give to your younger self programmer ? Feel free to comment below !


Little things I would teach to my younger software engineer self - #3 Git-fu

Looking back at the various stages of my career, I realized I could have learned some basic stuff way earlier than I did.
Even if I missed the original opportunity, all those little skills I acquired late served me tremendously well ever since. 





2008-me: Git? this is black magic for me, I kinda follow recipes, I can make a branch, push stuff, ignoring whatever this ugly thing tells me about fast-forwarding and oh crap I lost it, what is this weirdo state ? Ok, I'll admit it... I zap the entire repo and re-clone it every time I feel too uncomfortable.

2014-me: This is a mistake. You need to realize that git is a superb tool but its authors had such a disregard about its usability that you'll take forever to master it by just using it.

The only efficient way to learn git is to understand how it work from within, go straight to the chapter about its guts. Suddenly everything will make sense.



Any tips you would give to your younger self programmer ? Feel free to comment below !