30 years later, QBasic is still the best

(5 minutes read)

My oldest son Noah turned 7 three months ago. If he could trade his family for a 2 hour session of playing minecraft, he would do it in a heartbeat. The other love of his life is Super Mario Maker, and it’s been a thrill to see him play the same game and levels that I played when I was his age. About 5 months ago, I left my family for my yearly pilgrimage of ludum dare: a game dev competition during which I lock myself away with friends, return to a state of primitive caveman, not sleep for 48h, and create a full game from scratch (play it at the end of this post!) As I proudly showed my revolutionary AAA title to my wife, Noah was naturally intrigued and I introduced him to the world of code, showing him how simple words (he had just learned how to read) produced an actual game. Since that very day, Noah has been asking me repeatedly to teach him how to make his own video games. And for the past 5 months, I have been looking for the holy grail of language/IDE for kids in the hope of turning that spark of interest into a memorable experience…

My quest has led me to endless forums, through which I have tried countless suggestions: SmallBasic, Pico-8, Smalltalk, Scratch, etc. I have even inquired of the Great Oracles of StackOverflow, to no avail. After 5 months, I ended up with a disappointing conclusion: nothing is even close to what I had back in another era. 30 years later, QBasic is still the best when it comes to discovering programming. 

“OMG please don’t teach him GOTOs!!”

20 GOTO 10

Yes, QBasic is a terrible procedural language. It introduces one to concepts widely considered harmful, uses awkward syntax for implicit declarations, is not case sensitive, is non-zero-based, etc. the list goes on… When developing a skill, it is much better to acquire the right reflexes from the start rather than have to correct years of bad practice. Following this advice, I should have probably started off with the basics of the ruby language which I love. Yet, while most of those QBasic concepts are today generally considered as red flags by our peers, they each served a very specific purpose at the time: to keep the language simple and accessible, a notion that every other language has left behind in favor of flexibility, complexity and logic.

I installed QBasic on my son’s 11” HP Stream today, having to hack a DOSBox manual installation. He double clicked the icon on his desktop and in a split second, we were in the IDE, greeted with the introduction screen which brought back so many memories to my mind:

I then told Noah that there was a very sacred ritual, mandatory for anyone who enters the secret inner circle of programmers, to start off with a program that greets every other programmer out there. As I dictated the formula, he slowly searched for each key, carefully typing with his right finger the magic words: PRINT “hello world”

He pressed F5 and looked amazed as he saw his code being compiled into text rendered on his black screen. He smiled, gave me a high-five, and then scribbled down the code in his little notebook so that he could remember later.

We went on to a couple more commands: CLS, COLOR, PLAY, INPUT, and IF. There was nothing to explain: no complexity, no awkward operator, no abstract concepts, no documentation that needed to be read, no notion of objects/class/methods, no framework to install, no overwhelming menu/buttons in the IDE, no special keyword or parenthesis. It was code in its purest simplicity and form.

After less than an hour, he wrote his first program on his own – an interactive and incredibly subtle application which lets you know the computer’s feelings towards you as an individual and sensible human being:

…which he ran with utmost pride for his cousin and best friend Christian:

…after which he proceeded to easily explain him how it worked and what the code was doing!

And so it was that in a single hour, my 7 year old was able to not only write his first text game, but also to experience the fun and thrill that comes from creating, compiling and executing his own little program. Bonus points, it all fit on a single notebook page:

I was so glad that he was able to understand why I keep saying that I have the best job in the world. My only regret today was to realize that in more than 30 years, we have not been able to come up with something better for our kids: Qbasic has a limited set of simple keywords (the entire help fits on a single F1 screen and is packed with simple examples!), does not distract the coder with any visual artifacts, has a very confined and cosy dev environment, shows errors as early as possible, compiles and executes the code in a heartbeat with a single key, and is extremely straightforward.  We have built more robust and more complex languages/frameworks/IDEs (which are of course necessary for any real-life application), but we have never really made a simpler or more direct access to the thrill of programming than QBasic. Even running QBasic today has become dreadful to the novice that uses a modern Mac/PC/Linux machine, whereas it used to simply require inserting a 3,5” floppy in the A:\ disk drive…

Enough rant, today is all about the celebration of yet another person who discovered the excitement and beauty of programming!


(as promised, my AAA title for which I await EA’s call to purchase copyrights)

The Positive Coder Experiment

(10 minutes read)

About a year ago, we were trying to teach my 2-year old son to go up the stairs one foot at a time. It was interesting to watch him learn.  He quickly got the first half right: He would get his right foot up and push on his right leg with enough strength to lift himself up. But strangely he would never use his other leg. We weren’t quite sure why. Most likely because once he had learned a way to go up one step, there was no need to learn another way! I remember being behind him and telling him constantly: “OK now the other leg… No not that one, the other…” He would still use his right leg. “No, no no! The O-THER LEG!!” No matter what I said, it would always be the right leg. This lasted for a few weeks and what was amusing at first became a little frustrating as he only made use of that right leg. We had tried to lift his left leg to show him how to do it. We had his older brother show him the example. I mean… We just tried so many things in vain… Until something happened.

As we were headed towards the staircase together, he put forth his usual right leg and pulled himself easily up on the first step. But then, instead of targetting my thoughts and words on his left leg, I congratulated him on that easy right step: “Allright!!! Good job Clement!! Way to go! That’s great!!” He paused for a brief moment and listened while I cheered him up. And then, out of nowhere, he lifted his left leg, put it down on the step ahead and lifted himself up! I cheered him up even louder as he quickly went back to his right leg, and hop he went back to his left leg! In a breeze, he was now going back and forth with his little 2-year-old legs.I felt one of those rare privilege moments that a parent feels for his child. It was an amazing discovery for me: my child was much more driven by positivism than by explanation, example, or any other means of education.

A few weeks later, I wanted to try that same experiment at work. In my day to day job, I write code, I read other people’s recent/old code, I perform code reviews, I conduct technical interviews, I share common code with my team, etc. In the end, a lot of what I see as a coder is the output of others. As a software developer, I found that it is extremely easy to look at someone else’s code and focus on the WTF parts. In front of our monitors, our digital world of code is often depersonalized and rarely displays signs of tolerance for errors. I personally found myself being mostly negative when it came to dealing with what others were producing.

At that time, I was struggling with one member of our team who was working remotely on the other side of the world. It seemed to me that no matter what I tried explaining, i ended up being disappointed with what he produced. Most likely the language barrier made it hard for us to exchange clearly on the expectations for quality. His work was uneven: sometimes it was really good and often it was just plain awful. Anyways, he had just completed a feature and was waiting for my code review. I spent a good hour looking through his code. Every time I would see an error, I would mention it. But most importantly, I was now on the lookout for the good parts. I was able to find 3 methods that he had actually written really well. They were clear, concise, well thought out and unit tested. I proceeded to write long comments praising those methods, I mentioned it again in the code review summary, and again in an email. Maybe the impact was amplified by him being used to seeing me grumpy all the time, but boy did I not expect the outcome! A day later, he had made some awesome changes to his code. He had rewritten every other method so that their quality would equal or surpass the 3 methods I had highlighted. All of his code became great code! This was an eye opener for me.

I decided to keep going. With time I quicky found out that while no code is perfect, it always leaves just enough room for positive feedback. In every code review, pull request or answer from interview candidates, there were always positive things to spot and emphasize.

I had to be careful not to encourage bad behavior. This required me to make sure i wasn’t just tossing positive comments out of the blue. Bad code does not magically become good code if left unchanged. The experiment was not about dismissing the bad parts, and I never stopped underlining the bad or erroneous code that I saw. But as I gazed through lines of code, it was all about taking that additional time, sometimes twice the time, to look for and highlight the positive things that I saw: an algorithm which was well written, portions of code which were very clean, smart ways to handle a problem, etc. The aim was to cheer up my peers whenever they produced something good, with the hope that it would carry them one step further. I always made sure to largely outweigh the negative by the positive. If there were 2-3 things to be fixed, I would try to find 4-6 positive things.

The results were quite surprising. What I had discovered with my son was also true with everyone else, me included. Interview candidates became much less stressed out whenever I provided positive feedback on the correct answers they would give, thus increasing the rate of successful interviews. Code reviews which used to require multiple back and forth exchanges now brought much better fruit as the corrections were often perfect right off the bat. The relationship between team members improved and noone was left to code in the dark. The overall quality of our code increased and generated much less issues. I really can’t take any credit for any of it, as the behaviour quickly spread: everyone started doing likewise and most team members were doing it much better than I was.

I am sure that this can be applied pretty much everywhere. The majority of comments on the internet is negative feedback. This is simply explained by the fact that those who agree and enjoy a product or article rarely take the time to mention it, whereas those who disagree feel a natural need to voice out their opinions.

We may all be different as coders, but noone is immune to legitimate and thoughtful positive feedback. To praise a part of someone’s code is to show appreciation for one’s intellect. It increases self-esteem and confidence, it boosts morale and generates a desire to become a better coder. Were you looking for new objectives for the coming year? Take the additional time to look for the positive in what other people produce, and you will not only create greater code overall, but you will also be part of a much greater team.

Thanks for reading, and Merry Christmas!

Ludum Dare – Mr Box

Last week-end, I participated with my brother Max at Ludum Dare. We both worked on individual games. It was a lot of fun, but it prevented me from writing an article. So this week I invite you to try out the game I produced in the span of 48h:

Play the game (WEB / Unity player) : http://nicolasbize.com/LD31/LD31.html

Timelapse: https://www.youtube.com/watch?v=a7p97ZCaTX0

All source code & assets were made from scratch for LD31 and are available under MIT licence on github: https://github.com/nicolasbize/ld31

Download Music:
Intro Theme – https://github.com/nicolasbize/ld31/blob/master/Assets/Music/intro-1.mp3
Main Theme – https://github.com/nicolasbize/ld31/blob/master/Assets/Music/main.mp3
End Theme – https://github.com/nicolasbize/ld31/blob/master/Assets/Music/end.mp3

Tools used:
Unity 4.6 (C#), Photoshop, Blender, Audacity, Bfxr

Harmful Security

I’m in line at the guard post. The lady at the front desk is in her 50s. She speaks German on the phone, then English to the person in front of me. She then asks for my ID in French. I glance around the room. Security guards are keeping the entrance and the exit. Outside the bunker, a gate is also heavily guarded by employees who filter out the small amount of cars allowed to go through.

– Who are you here to see?
– Joseph Leblanc (name changed) from the flight performance department.
– Let me call him in. Please have a seat until he comes to pick you up.

Outside, people pass through one-way gates, using electronic badges to go through. The gates only leave room for one person at a time. Even if they tried, security officers carefully watch what comes in and out. One message is clear: security at Airbus is not taken lightly.

Today is July 1st, 2006 in Toulouse, Southern France. Joseph arrives, smiles and greets me as we shake hands. He then goes to the front-desk, signs a bunch of forms and I trade my ID for a temporary badge.

The M01 building is on the left. It’s shaped like an eight figure. Joseph uses his badge to open the front doors. We take the elevator to the 3rd floor. I get a bunch of forms letting me know that I’m forbidden to carry any USB key or external storage device from outside the premices. I cannot bring in my own laptop and cannot bring home anything from Airbus. Those caught with sensible data will face suspension.

I arrive at my desk and turn on my desktop computer, excited to discover what hardware I was provided.

Crap, it’s at least 5 years old. I sigh and as I greet my new teammates, I notice something intriguing: some keyboards have sticky notes next to them. It appears to be some sort of serial number for each computer…

Back at my desk, I am asked to enter my first password. Not just any password. Ten chars minimum, with a required mix of numbers, letters, uppercase and special characters. It takes me a good minute to think of a solid password I can remember. Done. I then try to install Visual Studio. No admin privileges. “Oh you can’t install anything on your machine, We have to issue a ticket for that.” We do. 2 hours later, some guy from an the outsourcing company remote-desktops to my machine, opens up the network folder and installs Visual Studio. 1 hour of installation passes by.

I go on the internet and start browsing developper forums, but most of the time I am greeted with a “Forbidden Site” intranet page. With time, I realize that the blacklist of forbidden URLs is huge. I am told that “it’s a security measure for everyone, to ensure that noone downloads a virus.”

As the days go by, I notice that people regularly change the serial numbers on their stickers… And within just a few weeks, I am greeted by the system for a new password. Already!? Yes, passwords change very frequently here. Security Measure. When working on things as sensible as the upcoming A-380 airplane flight data, a lot of precaution is taken. I talk with someone about using a rotation number, but they apparently received a security warning regarding that behaviour.

It takes me 2 minutes to create and memorize a new password. Deep inside, I actually have no desire to memorize it, knowing that within a few weeks it will already be obsolete. As a result, I often mismatch it with my first password. With time, I finally manage to forget the first one and remember the second one. And then before I knew it, it was back: “Change password.”

No, I don’t want to memorize yet another password you stupid fat-bordered dialog. Luckily, there’s no harm in me carrying the password on me. I take a pen and write down a random password on a sticky note, which I then put in my wallet. The process quickly becomes fastidious. I am constantly taking it in and out of my wallet… One day, taken by other thoughts, I put the paper back directly in my pocket, outside its protective wallet. The washer seizes the opportunity and destroys the note before I can realize it.

The next day, I’m of course unable to find the yellow piece of paper. It’s OK I’m pretty smart I managed to remember it. “Account locked”. Guess not. Time to talk to my superior.

Joseph: “Aie, that’s not good… OK let’s call IT support and see if they can reset your password”.

We call in. I explain my situation and indicate that I find all the security measures a bit extreme.

I receive a sermon on how critical and sensible all the data is, as well as why all the security measures in place are so important and shouldn’t be taken for granted. The guy is clearly in a bad mood. Either he’s just really French, or I’m not the first one having password issues. He finally resets my password. I get back to my computer, hoping he will choke on a croissant the next breakfast.

I attempt to log on. And there it was again, smiling at me like the clown who never dies in horror movies: “Change password”.

Sorry, but I’m done. I take a sticky note, write down a new random password, and put the sticky note under my keyboard. Another serial number. Guilt and remorse start kicking in. I kick it right back in the face through idiotic self-justification: “who cares anyways, it’s always my team in that open space… everyone does it… it’s ridiculous, they asked for it…”

And there I was, creating yet another flaw in a system designed to be so secure. The security’s absurd rigidity had become its biggest vulnerability.  It was just a start, as I couldn’t work properly with so many websites blocked. I didn’t feel protected, I felt in jail and compelled to get out.

7 years later, I have become a security software engineer. I look back at those times and regret my irresponsible behaviour. I have empathy for the IT guy who was doing his best to educate the employees about the importance of security. Having strong passwords, changing them often, enforcing strong security policies, mastering what is done by the users, etc. are all somehow necessary evils. And yet, having personally seen so many sticky-note passwords around me, I cannot wave away the thought: Creating the most secure system without focusing on its users is like looking for the strongest ciment for a house built on San Andreas Fault.

7 Tips to Speed Up Eclipse

About a month ago, I blogged about my love/hate relationship with Eclipse. I was asked by a few people to share my tips on how I was able to speed it up so here we go… As a side note, this article is not about comparing IDEs, please refrain from displaying your hate for the IDE or your preference for another…  This post is just about optimizations that help Eclipse run faster for those who use it. I’ve described each tip for Windows, Linux and MacOS users. Once you have gone through all the optimization tips, Eclipse should start within 10 seconds and run much smoother than before.

[edit]: most of those tips will speed up your Eclipse experience, not just the startup time. Classes will open faster, jumping from one definition to another will be faster. Viewing method javadocs will be faster… Unfortunately, none of that can be timed precisely so there is no specific benchmark about the actual speed gains for each tip.

Note: I assume that you already have an SSD and at least 8Gb of RAM. If not, look no further for performance boosts…

Tip 1 : Always run the latest JDK and Eclipse.

More often than not, every new JDK and Eclipse version includes fixes and optimizations from previous versions. Make sure that you are using the 64 bits version of Eclipse and of the Oracle JDK. For any web development, you will want to use Eclipse for Java EE and not Eclipse for Java.

Oracle JDK : http://www.oracle.com/technetwork/java/javase/downloads
Eclipse : https://eclipse.org/downloads/

Place Eclipse and your code on your SSD.

Time to launch Eclipse.

Tip 2 : Tune Eclipse Preferences

  • General > Startup and Shutdown : remove all plugins activated on startup
  • General > Editors > Text Editors > Spelling : Disable spell checking
  • General > Validation > Suspend all
  • Window > Customize Perspective > Remove stuff you don’t use or want (shortcut keys are your friends), same for Menu Visibility (how many times have you printed a source file…)
  • Install/Update > Automatic Updates > Uncheck “Automatically find new updates”
  • General > Appearance > Uncheck Enable Animations
  • Stay with the default theme. Unfortunately, anything else makes it really laggy and slow.

I personally turn off autosuggestions so that they don’t slow down my typing. Instead, I manually trigger the auto suggestions using Ctrl+Space when needed. This is done through:

  • Java > Editor > Content Assist > disable Enable Auto Activation. Advanced > Remove all unwanted kinds

Tip 3 : Keep your JDK on a RAM Disk

A RAM disk is a virtual disk or hard drive that is stored into the computer’s memory. It boosts the I/O performance on anything that is on it. Creating a RAM disk uses your RAM even though it just appears as a drive on the computer. Because the memory used will be reserved for the disk and become unavailable for other programs, we will only be putting the JDK on there. 300MB will be enough.

Warning: Don’t put anything permanent on the RAM Disk we will create as it will be erased/recreated at each reboot.

Step by Step for Linux users:

Everything is described here already

Step by Step for Mac Users:

The RAM Disk is created with the diskutil tool:

1. Create a new batch file, for example: ~/tools/batch/ramdisk.sh
Replace x, y, and z with the JDK version you have installed on disk:

diskutil erasevolume HFS+ 'JDK RAMDISK' `hdiutil attach -nomount ram://614400`
cp -r  /Library/Java/JavaVirtualMachines/jdk1.x.y_z.jdk /Volumes/JDKRAMDISK

(Note that diskutil expects the number of 512 bytes sectors to be allocated: for 300MB, 300 * 1024 ^ 2 / 512 = 614400)

2. Save your file and make it executable:

chmod 755 ~/tools/batch/ramdisk.sh

Now run ramdisk.sh to create the Ram Disk:

$ ramdisk.sh 
Started erase on disk4
Unmounting disk
Initialized /dev/rdisk4 as a 300 MB case-insensitive HFS Plus volume
Mounting disk
Finished erase on disk4 JDKRAMDISK

You should now see in Finder the new device called JDKRAMDISK containing your JDK. You can remove the RAM Disk and free its memory by clicking on the Eject button:

Note that if you follow this tip, you will always need to have the RAM Disk in order to launch Eclipse (otherwise you will see the error “A Java Runtime … must be available in order to run Eclipse”). You can configure your system to run the ramdisk.sh script automatically upon startup using Automator or using a launchtl daemon.

Step by Step for Windows Users:

1. Download and install the utility called imdisk 

2. Create a new batch file, for example: C:/tools/batch/ramdisk.bat
Replace x, y, and z with the JDK version you have installed on disk:

@echo Placing JDK on Virtual Disk N:/
@echo off
sc config imdisk start= auto
net start imdisk
imdisk -a -t vm -s 300m -m n:
format n: /q /Y
call xcopy C:\<path_jdk>\jdk1.x.y_z N:\jdk1.x.y_z\ /S /E /Y /Q
label n: JDK RAMDISK

By running ramdisk.bat, you will have created a new disk N: labeled “JDK RAMDISK” that will contain your JDK.

3. Make sure the file is run as an Administrator. Right click on the file, go into Properties and check Run as Administrator.

Note that if you follow this tip, you will always need to have the RAM Disk in order to launch Eclipse (otherwise you will see the error “A Java Runtime … must be available in order to run Eclipse”). You can configure your system to run the ramdisk.bat script automatically by placing the script into your Startup folder.

In order for Tip 3 to work, you will need to add the -vm setting in eclipse.ini (see next section)

Tip 4 : Tweak your eclipse.ini

This is one of the most confusing areas of Eclipse optimizations. There are thousands of online articles preaching different configurations… I’ll just describe the way I tweaked my options and add more to the existing confusion 🙂

Location your eclipse.ini file:
Windows/Linux: located in $ECLIPSE_HOME
MacOS: located in $ECLIPSE_HOME/Eclipse.app/Contents/MacOS

Understanding what’s going on…

Eclipse.ini contains 2 types of properties: properties relative to the Eclipse application and properties relative to the JVM. Those options are different depending upon your version of JDK or Eclipse. Here is the most up-to-date list I was able to find online.

To understand those options require just a bit of vocabulary on Oracle’s JVM. Basically, the JVM memory is divided into multiple memory pools where objects reside with time:

  • The Eden Space (heap) provides the memory for most initial objects. The Garbage Collector passes often through this space containing objects of “young generation”. It removes any objects that hasn’t been used for a while. 
  • The Survivor Space (heap) contains the objects that have not been destroyed after 2-3 passes of the GC in the Eden Space. They are still part of the “young generation” but have moved to a much safer place where they have less chances of being destroyed: the Garbage Collector passes much less often there (it assumes from past experience that objects are used more frequently).
  • The Tenured Space (heap) contains the objects that have been in the Survivor Space for a while.
  • The Permanent Generation (non-heap) contains all the metadata about of the JVM, such as the class properties, methods, enums, etc. Because that data can be shared accross multiple JVMs, the permanent generation has read-only and read-write areas.
  • The Code Cache (non-heap) provides the memory used for compiling and storing code.

In case you are interested, Oracle wrote a great article about garbage collection tuning, detailing all those spaces and roles

The sizes for all those memory pools can be tweaked in eclipse.ini. I have 16Gb of RAM, but these settings will work fine with 8Gb of RAM. 

use the JDK stored on the RAM Disk (use the version according to what you did in Step 3):


disable bytecode verification (risky)


This basically skips the verification of class files (described in http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.10), meaning that the JVM won’t be able to detect the authenticity of the class files you are using. This poses a security threat if the compiled files have been altered. Use at your own risk. (I use that option for hobby projects but not at work)

turn on performance compiler optimizations


increase permanent generation space (where new objects are allocated)


increase min and max heap sizes (which includes young and tenured generations)


increase heap size for the young generation


set stack size for each thread


tweak garbage collection


And finally, here are some other options that you may see online… Personally I didn’t notice much of a boost by using any of them so I’m just stating them for info. You can look at the doc reference to know what they correspond to and then play with them:


Finally, remove all the duplicates as well as launcher.XXMaxPermSize which is useless with the option XX:MaxPermSize.

Tip 5: Get your anti-virus outta here

If you have an anti-virus, make sure that it doesn’t interfere with your code folders. Add the JDK folder, the Eclipse folder, your .m2/jar repositories, and your code folders to the antivirus whitelist.

Tip 6: Keep SVN and GIT out of Eclipse

This is really a matter of personal preference. Some will like the Eclipse integration with the collaborative team tools. Personnally I find them slow, I’d rather have Eclipse concentrate on the dev task than try to do too many things at once… I’m also a sucker for the SVN/GIT CLIs… Anyways,  I removed the integration with Eclipse and found it much more responsive.

Tip 7: Use your keyboard

One of the perks of Eclipse is the trumendous amount of keyboard shortcuts it offers. You can remap them if you are used to other schemes. I usually remap my debugging keys for ex. so that they match the ones in VIsual Studio &  Chrome Dev Env. Take some time to learn them. The less your hands leave your keyboard, the faster your Eclipse experience will be!

I won’t go into details about which shortcuts to know but you can easily find that information online. Just thinking about it, a few must-know shortcuts come to mind:

Ctrl+Shift+R : jump to resource
Ctrl+Shift+T : jump to class
Ctrl+. : jump to next error
Ctrl+Shift+G : search for references
Ctrl+Shift+P : select matching bracket
Alt+Arrows : go forward / backwards
Ctrl+Space : autocomplete
Ctrl+Shift+F : format source
Ctrl+Shift+O : organize imports
Ctrl+D : delete line

This pretty much wraps it up! Without comparing Eclipse to any other tool out there, I find that it can be a very powerful and fast tool to write java code with.

If you have any other tips, I’d love to hear about them!

Coding Alone In The Dark

“Code Smell” is an expression given when glancing at some code and seeing right away potential issues with the way it is designed. Martin Fowler describes it as “a surface indication that usually corresponds to a deeper problem in the system”. It is often tied with the notions of pasted code, anti patterns, over complexity, etc. I personally like the image of the expression: One barely needs to look at the code to know that there might be something wrong with it. Today, there are hundreds of articles that talk about how to detect code smells. There are tools that spit out metrics letting you know what could be improved. You get the idea…

Today I want to talk about another type of code smell : code that has been entirely designed and produced by a single person, code which has never been seen or reviewed by others peers, code that has been produced in the dark is almost always a code smell. (By definition, this excludes anything that is open source). This doesn’t mean that it is bad code, but most likely that it can be improved and perfected if viewed by and discussed with others. Even though there may be some exception to the rule, I have personnally never seen this theory fail once in all my years as a software developer. If you are doing it alone, you are doing it wrong. 

When you are aware that your code will not be seen by others, it takes an extreme amount of self discipline to not take shortcuts. Documentation will be sparse, routines will not be optimized, refactoring might not be complete. You might produce code that works, but if you honestly ask yourself the question: “is there anything I would change if my code was to be open sourced to thousands of developers tomorrow?”, chances are you will come up with a bunch of TODOs.

On the other end, coding “in the light” of others only brings positive things. You will be more careful when writing for others than for yourself. You will worry more about small details, such as the way you name your variables. You will make sure that your logic and algorithm are implemented and tested correctly. Your code will be easily readable by anyone. And once your code is out in the open for others to analyze, it will only improve with time. The feedback from others will make you a more humble and a greater coder. This is, I believe, the true gold that is provided by open source development.

At most private companies, designing the code for a feature usually involves multiple people. Code reviews are done prior to features being tested. Everyone knows the ROI of taking that extra step. Yet every so often, because of time concerns, of pride, or even worse because of fear of appearing dumb, code falls through the cracks, burns bridges and ends up being shipped in your software without having been looked at.

While I’ve had many occasions to avoid putting my code in the light, I found that I never had a good, solid reason to do so. Lack of time? Fear of what other devs might say? Lazyness? Pride? I’ve personnally gone through all these feelings many times. Asking for and accepting feedback is not easy. It hurts to realize that what you found great, others found perfectible. It sucks to realize that you have to spend more time refining code you thought complete. Noone likes to be told that he is wrong. Especially not coders, where personal pride and self justification too often come in the way of building greater code.

You’re probably thinking: “well yeah, you’re just stating the obvious: code reviews improve code quality… yadi yada.” Yes, it is obvious. But it’s not a natural thing for developers to do! We coders are mostly cavemen. We like the comfort of privacy, we need to experiment and create on our own. It is not a natural thing to bring our code in the light. I have heard and seen so many times developers who were left alone to create and publish code, in the name of trust and autonomy, only to realize too late that what they had created was awkward, unstable and prone to WTF moments. Just a few weeks ago, I stumbled upon a database schema that had been created by a mercenary who had only stayed a few months at our company. It contained a bunch of 3-letter tables with each 20-30 columns that had 3-letter names… No-one had a clue of which column stored what. The developer had been left alone for 6 months because of his seniority status. He only left behind mysterious, unoptimized and non logical code. Was it his fault for not showing his code to others? The peers’ fault for not asking? When a team cannot work together to produce high-quality code, it’s more a team issue than an individual fault. Coders shouldn’t feel forced to share their code. They should do it out of desire, because they realize the outstanding positive impact that it can have on his/her own coding skills and on the code itself. 

Don’t code alone in the dark. Talk about your code, write about your code. Share it, ask your peers to look at it, to discuss it, to criticize it. Get everyone involved in the process. A junior developer will build confidence when trusted with the opportunity to criticize code produced by his older peers. He will learn from analyzing good code. A senior i’ve-seen-it-all developer has the ability to look at the problem with a renewed eye and can be a trumendous asset. When given the opportunity, take the time to review your peer’s code. Learn from it. Find what could be done better. Outline the great things that you see, discuss the issues that you find and give constructive feedbacks. 

Beautiful code never comes out of the dark, it is always refined through the fire of analysis and criticism.

[edit] : I received a lot of comments on reddit / codeproject about things which weren’t understood the way I intended them to be. I am not meaning to say that code produced by a single person is bad code or “smells”. I am using the terms “doing it wrong” because there is so much more to gain from working on code as a group of individuals than as a solo dev. I have modified the article to reflect that.

Becoming a GMail Ninja

A lot of you know about the many keyboard shortcuts in GMail. Most of you probably use the most common ones. Today I want to issue out a challenge to you: completely stop using your mouse in GMail. Rely entirely on your keyboard. Not only is it possible but I personally find it more productive. As I always switch browser tabs using [cmd][tab #], using gmail without a mouse can be a time saver.


Let’s start with some settings. I like to use a compact black theme to save up on my laptop battery and display more items. Some Labs will need to be activated:

  • Settings: Display density: compact
  • Settings/Themes: Color Theme dark to save on laptop battery
  • Settings/General: 
    • Default Reply: reply to all 
    • Enable Undo Send
    • Keyboard Shortcuts On
  • Settings/Labs:
    • Enable Undo Send
    • Enable Unread Message Icon

Learn how to use Labels

This is the most useful feature of GMail. Make sure to label your emails as they come through. Use precise filters to automatically label them into categories that make sense to you. This will allow you to automatically sort and process your emails as they go through.

Navigating through common folders / places

Here’s how to navigate between the different places. This is the [alt][tab] / [⌘][tab] of Gmail.

Learn how to quickly go back and forth between them. Here are the ones I find most useful :

[/] – goto search
[g][a] – goto all
[g][i] – goto inbox
[g][s] – goto starred
[g][t] – goto sent
[g][d] – goto draft
[g][l]<label> – goto label, use [tab] for autocompletion
[g][k] – goto tasks
[esc] – close window, reset focus
[q]<contact> – chat with contact
[c] – create a new email

If you are in the chat window:

[shift][esc] – go back and forth between chat and mail
[esc] – close current chat

searching for emails

Once the searchbar has gained focus (hotkey /), there are tens of keywords and operators that let you search through your emails.

Learning a few of them can really make a difference. I only use about 10 keywords.

Don’t forget to use [tab] for autocompletion:

in: <label/inbox/trash/spam/chat>
is: <starred/unread/read/chat>
-in:chats or -is:chat: exclude chats
-label:<label>: exclude label

If you perform this search often, make sure to create a filter for them (More > Filter messages like these)

Selecting emails:

When viewing a list of conversations, it is very useful to know how to make quick selections in order to apply bulk actions.

When the focus is resetted (key [esc]), you can move the blue cursor to make single selection/deselection.

[*][u] – select all unread
[*][i] – select all read
[*][n] – select none
[*][a] – select all
[x] – select/deselect single (blue cursor)
[up]/[down] or [j]/[k] – move cursor

Performing actions on a selection (bulk)

[+]/[-]  : mark as important / not important
[l]<label> : label as label
[U] – mark as unread
[I] – mark as read
[#] – delete

Combining with the previous hotkeys, here are a couple of useful combos:

[g][l]<label>[*][u][I] – mark all unread messages with label X as read:
[*][u][#] – delete all unread
[g][l]<trash>[*][a][#][enter] – delete all messages with a certain label
[g][d][*][a][#][enter] – delete all drafts

Performing actions on a email (single)

(all bulk actions apply as well)

[enter] / [o] – open email
[s] – star
[a] – reply all
[f] – forward
[T] – add to task
[k] / [j] – next / prev

while writing an email:

[tab][enter] – send mail
[ctrl][shift][c] / [⌘][shift][c] – Add recipients
[ctrl][s] / [⌘][s] – save draft
[⌘][;]  last mispelled word
[⌘][\]: remove formatting
[shift][cmd][6] – alter font. By default, the font is Sans Serif, 2 fonts left of Fixed Width. When pasting code you can select the code, then use the combo [⌘][\][shiftcmd6][shiftcmd6] to quickly format it using a clean monospace font.

If you are in the middle of writing an email and want to do something else, then go back to that email: combo [⌘][s][esc]<do something else>[g][d][o]

Finally, 2 useful shortcuts for reference :

[?] – shortcut help
[z] – undo

The Great and Dusty Intentions of TODOs

Another empty can of coke. Just a few hours left before the week-end!! This is looking great, I just have to refactor this small part of the code. Two minutes and I should be done.

Ok. it’s actually more complex than I had thought. 2 minutes won’t cut it. If I refactor this part, I also have to refactor this as well. And there’s no unit tests on that part so I’ll add those. Oh, but this should really be an abstract class. It doesn’t make much sense otherwise. It’d be so much cleaner. Allright let’s see… Ugh, it’s already 6:30pm. Friday night. Everyone has left. My feature works perfectly already. Allright, I’ll just postpone this and get it fixed in the next release. I’ll add this to make sure I don’t forget:

//TODO: refactor the static report helpers.

Having marked my feature as Fixed/Ready in JIRA, our QA then validated it and it all went to production. The next monday I had forgotten about it. I was already working on something else. That TODO comment, along with the piece of unrefactored code were left to accumulate digital dust and slowly turn into legacy and mysterious code.

I never went back…

That was 3 years ago. I stumbled upon that TODO yesterday by chance, as I mistyped the name of a class I wanted to open in my IDE. It took me by surprise and I was amused to recall how I had left it years ago with the good intention of fixing it. I then proceeded to search for TODOs in our code. We have a big code base at Qualys: a few million java code lines and about a million javascript code lines. I never thought we had so many TODOs. Reading through them was like going to a museum. I’d see names of people who’d left the company years ago, I’d see code that noone wanted to touch because noone quite knew the impact it would have. I felt like Indiana Jones looking through the ancient ruins of the undone…

Was it just us? I took a peek at github’s code base:


50,399,137 references and going up every second. If fixing a TODO would take 1h, it would take more than 24000 years of work to complete. That’s a lot of jobs right there!

As more and more code gets written every day, that number will keep growing with time. And while they can serve a good purpose, I’ve come to the personal conclusion that TODOs are hard to get rid of and should be avoided if possible:

1/ TODOs are personal. People don’t fix other people’s TODOs. When your write a TODO, you’re mostly saying to others: “Don’t worry, I’ll do this”.

2/ TODOs usually take a lot of time. If not, they would have been fixed on the fly. They also require to understand the big picture.

3/ TODOs are obscure. They are generally mystic comments that don’t give the how nor the why.

How do you deal with dusty TODOs in your code base? Thinking about it, I will do the following from now on:

1/ Don’t procrastinate great code. If you feel that a refactoring is important, then you are at a point where you have grasped the whole picture. Fix it now before moving your mind to other things. Take the additional time if you have it.

2/ If you cannot fix it now, track your TODO somewhere else than your code. Open a JIRA ticket, a Github issue, assign it to yourself, describe the why/how. Give yourself a deadline to fix it, and make sure you do it.

Leaving TODOs in code is like publishing incomplete code. It’s annoying and irritating, just like someone who starts a sentence and doesn’t

The Code Zombies of StackOverflow

I believe that this is the greatest time to become a programmer. Whereas I remember paying 149$ for an undocumented Microsoft Visual C++ 1.0 twenty years ago, almost all languages and tools have now become extremely accessible, free and well documented. The amount of information that one can find online is bewildering. We now speak in exabytes. There are more tutorials out there than you could read or watch in your lifetime. As a coder, I also doubt that you will find many algorithms in your code that have not already been analyzed and cleanly displayed online. To illustrate this, StackOverflow currently has about 8,3 million questions. 8.3 million… Just think about it for a second… There are 48 times more questions than the number of words in the English dictionary! And while this includes many duplicates, there are still new questions pouring in every day. This means that any time I have a question on any specific code subject, I can be 99% sure that I can find a perfect and constructive answer on StackOverflow along with instructive comments. And while this is in part a wonderful thing, I think that this has turned a lot of us into code zombies, coders who reach their objective without understanding the problem or thinking about the solution.

Like a growing disease, I feel that this has become a growing trend. With so many quality answers at our disposal, developers quickly make the huge mistake of taking away the most constructive part of the problem solving equation: the path leading to the solution.

Now, I am an utter fan of Jeff Atwood and Joel Spolsky. I was closely watching as StackOverflow was being built and seeing their hardware specs, I believe that it is one of the greatest website implementation of all times. I am in no way encouraging you to stay away from it. But if jumping to StackOverflow is the first thing that comes to your mind when faced with a new problem, you are clearly missing out on the best part of programming.

A lot of people tend to rush to StackOverflow for every question they have. Some even hope for a nice prebuilt jsFiddle where they can view the results before even looking at the code. They justify this by time constraints, or by not wanting to waste energy reinventing the wheel. They wrongly believe that they would be wasting time by finding a less-optimized solution than the most upvoted answer out there. They merely think about the problem, and tackle each new algorithm like someone who solves crossword puzzles with the answer page left open. They are delegating the research part of their jobs. While they may still be learning a bit by looking directly at solutions, they learn a lot less, if not nothing, compared to the ones who go through the “painful” process of laying down the problem, thinking about the solution, coding the answer, testing it out, optimizing it and then comparing it with the top answer from StackOverflow.

Bringing research back into your code.

A coder can only become a master of his craft through time and experience, tackling each problem through solution-seeking, testing, error making, hitting walls, going through eureka moments, rebuilding wheels, compiling, and perfecting its own code. Not only do I think that each step is crucial as a learning experience, I also believe that it is vital for personal satisfaction and well-being. In fact, I truly believe that a coder can only be satisfied with its job when the latter stimulates its intellect and forces him to learn something new every day. Depending upon your current tasks, you may or may not be faced with a lot of unknown each day. Here is my personal approach to the problem :

  1. When faced with a new problem, don’t hop on the Google wagon right away. Give yourself at least 10 minutes to try and solve it by yourself.  Take a piece of paper, draw the solution, open a source file, code, compile, test. 10 minutes is not a lot of time, and you will quickly see that the investment pays off.
  2. When looking for information, look first at the official documentation instead of trying to find the direct answer on StackOverflow. The docs usually give detailed and updated information that will help you understand what needs to be done to tackle the problem.
  3. When you find something useful, write about it. Keep a journal, a blog or some written notes about your discoveries.
  4. When giving out a solution on StackOverflow, do not just spit out a jsFiddle answer. Point towards the right direction, write in pseudo-code, help the coder help himself.

If you have become weary of just gluing code together or feel like a zombie writing code, I promise that if you strive to bring research back into your code, you will discover a renewed, instructive, and rewarding experience.


FavIconX : Make progress bars out of favicons.

Last week on my NAS I found some old code that I had created about 2 years ago. It was a small (7kb) vanilla library that enabled you to make progress bars out of your browser tab icons. I never released it because it was so similar to piecon. However it seems that piecon hasn’t been updated for the past two years. Since my library has a bit more configuration options, I thought I could brush up some documentation and open source it for anyone to use.

FavIconX is now yours to play with.