Category Archives: programming

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!!”

10 PRINT “OH NO, WHAT ARE YOU DOING?!!!”
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!

Cheers!

(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

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.

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:

https://github.com/search?o=desc&q=%2F%2FTODO&ref=searchresults&s=indexed&type=Code&utf8=%E2%9C%93

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.

Cheers

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.

Cheers!

The Best IDE in the World

First of all, I apoligize for the lack of recent posts. Brushing up things for the Qualys Security Conference took all my free time away for the past 3 weeks. I really want to get back on “the one quality post per week” rhythm so expect more things coming your way in the future!

One of my most memorable experiences in software development occured to me about 8 years ago when I started working for Airbus. I was fresh out of college, all pumped up with my master’s degree in network engineering. I had been swimming in code for the past 15 years (though it was mostly self-learning and small hobby projects) and therefore thought firmly with boasting over-confidence that I was an amazing coder. The truth is… I was clueless about how to produce great, maintainable code. The main issue with someone that is overcome with pride is that it always finds itself faultless, rejecting any type of failure onto something or someone else. For me, 8 years ago, it was always Eclipse’s fault.

In an effort to trend towards open-source usage and cost reduction, Airbus had started shifting most of their software development from C++ and VB/C# to the Java world. Most of the code and testing was also slowly shifting from internal development to outsourcing. I entered Airbus in that period of transition, and downloaded Eclipse for the very first time in 2006.

As an advocate of Microsoft products, Visual Studio was to me the pinacle of the IDEs, making the transition to Eclipse incredibly painful. It was slow: autocomplete would take multiple seconds, it would often freeze… The integration with maven was never working. The layout was awkward. Spell-checking ON but line numbers OFF as defaults?! I was repulsed by it. Everything about it made me feel like it was created at the time when dinosaurs were still on the earth. I hated it with my life. In fact, I hated my job for having to use Eclipse. I was a miserable coder who knew deep inside that it was all Eclipse’s fault. I thought that things would get better with the days, but they didn’t. I kept dreaming about creating the site http://www.ihateeclipse.com/ three years before it was even born.

Two weeks had passed, and then came along Ludo, a whiz kid about 5 years older than me down the hall from me. He had heard me curse at the IDE and asked if he could help. I replied with assurance: “Pff there’s nothing anyone can do about it, it’s just Eclipse who’s being a piece of *junk* once again. I’ll fix it.”. He then asked: “What do you mean once again?” after which I started a 10 minutes whining about how awful Eclipse was and how slow it made me as a coder. I was trying to fix a bug and Eclipse was just throwing random errors.

He listened carefully and then asked if he could take a look at the issue at hand. He picked up a chair and I gave him my mouse and keyboard. Ludo then started typing extremely fast, opening up the preferences, changing a bunch of options, tweaking memory usage, server settings, etc. His hands never left the keyboard. All of a sudden everything on my computer, Eclipse included, seemed so fluid, so fast and so responsive. For each specific action, Ludo knew the exact procedure, the right shortcut. The dialogs would open up and close within seconds. Within a few minutes, he had identified the issue, fixed it, tested it and commited the fix. Before leaving, he said: “Eclipse is just another tool. They are only as sharp as you decide them to be.”

I was blown away and became transformed by that experience. Back with my keyboard and mouse, Eclipse seemed slow again, but now I knew that if I learned how to use the tool well, it could be extremely powerful and fast. And not just Eclipse, but every other tool as well! My OS, my text editor, my browser… Everytime I went back to Ludo’s desk, he was only working through emacs and a linux terminal, something I had never thought possible before. But he had mastered those 2 tools to perfection and was faster at producing efficient code using them than with any other tool.

With the years, I have come to master a small number of tools. For example I know all the shortcuts in Photoshop, I am fluent in Visual Studio, I never use the mouse in Eclipse, I use my own Sublime Text plugins and hand-made extensions in Chrome’s dev console. Just like learning to play an instrument, mastering any tool is hard and requires dedication and a lot of time. I have tweaked Eclipse and Visual Studio in so many ways that not a lot of people can use my instances without feeling that they are a bit awkward. I have modified/treasured the tools in a way that they have become a part of me as a coder. I improved my typing so that I could be fully efficient in both french and english using any type of keyboard layout. And with the years, I have come to the conclusion that one of the best ways to become a better coder is to learn to master the tools that you use. And this is not a learn-everything-in-24-hours type of thing.

Even today we still see a lot of open debates about Eclipse vs Netbeans vs IntelliJ, about .net vs java, about rails vs django vs laravel, the eternal conflict of PC vs Mac, etc. And seeing a title like “the best [insert any word here] in the world” is enough to bring people to frenetic behaviour. To those who seek which tool is better, I want to quote again from the amazing and inspirational coder I met at Airbus 8 years ago: “Tools are only as sharp as you decide them to be”. Now pick an IDE, a browser, an editor that you feel good with, and go master it. Make it your own. Make it the best tool in the world.

The Oyster Effect In Software Engineering

Studies have shown that people value the products they own by how difficult they were to obtain. Things become more valuable when a sacrifice of money, time or energy was provided in exchange. This notion has given birth to hundreds of marketing techniques. This week for example we saw how the organized limited stocks in Apple’s new iPhones generated lines of thousands of fans accross the world. Even if you thought the phone was expensive, the mind somehow justifies the value and price when it sees how difficult it is for someone to actually purchase a brand new iPhone 6.

This marketing tool is used throughout many fields, including product packaging itself:

We’ve all been there… You buy a product and then spend minutes of frustration trying to open a package, using objects at hand such as nails, teeths or car keys, cutting yourselves on the plastic edge and bleeding to death while cursing out loud at the engineers and designers who came up with such a horrible packaging idea…

It turns out that because the package creates a frustration, the achievement of opening it provides a reverse satisfactory effect that continues throughout the initial usage of the product. This marketing technique is one that the French call the Oyster Effect, even though it only makes sense if you like oysters.

Well, I have now grown weary of such practices. In a world where the most valuable resource has become time, I feel like wasting time on opening a package or learning how to use a counter-intuitive product makes the product more expensive than its price tag states. In the equation, I feel like the Oyster Effect actually brings out more negative than positive.

Last week, I downloaded an app to sync up my electric car. After downloading it, I had to register the product before using it. I then had to go through an online 2-pages signup / confirmation process. I then had to set up the default settings. I then had to go through an initial tutorial. Finally I had to figure out how to sync up the car, entering lots of long alphabetic strings of random characters (think UUID) on a tiny keyboard. The whole process took me about one hour. All those steps were time-consuming. It was like trying to find the right scissors to cut through the package. Every step was enforced without any possibility to skip them, using a combination of ackward design and horrible usability before I could even have the app running. It only left me with a sour taste and a sense of frustration for the app itself. And yet I hadn’t even started using it.

One of the most challenging exercice is to ship software in a way that people can use it right away and feel right at home the second it starts.

While there are a lot of guidelines on how to achieve this, here are five that I like to follow whenever I ship a new feature or product:

Give access first. Ask for configuration later.

Noone wants to take some time configuring something they simply want to try out. Keep signup forms to a minimum. Prefer reusing accounts to storing new passwords.

Don’t do this:

Always provide logical and non-obtrusive default options.

If you ship a programming IDE, make sure you ship it with spell checking OFF and with line numbers ON… Do not subcribe your users to anything unless they have desired to do so…

Don’t do this:

Make your software intuitive

Don’t attempt to revolutionize the standards by coming up with another icon for the Save button, or by remapping the shortcut keys that everyone is used to…

Don’t do this:

Aim for simplicity.

Limit the number of clicks required for each action. Keep the displayed information to a strict minimum.

Don’t do this:

Allow for flexibility

Provide advanced options / configuration to provide for all the other use cases you took out when refining the step before.

This week-end I played The Stanley Parable. For those who haven’t tried it, it’s an amazing experience that I don’t want to spoil. But besides providing an awesome game, the guys at Galactic Cafe provided a perfect example of simplicity, intuitivity and usability that you experience as soon as you start the game for the first time. It only takes a few seconds from the time you click Play on your OS to your first Wow.

The main reason why we create software is for our users to use them and enjoy them. The less is required of them to use the products correctly, the better the experience for both the creators and the users. As the French poet Antoine de Saint-Exupéry stated 75 years ago:

It seems that perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Look at your Old Code.

The internet is filled with questions regarding how to become a better coder. And the answers are pretty much the same: read books, do peer reviews, participate in open-source projects, etc. All those are excellent answers, but one issue that remains unanswered is how to measure your improvements as a coder throughout time.

One thing that I always encourage peer coders to do is to archive all the personal code that they write, no matter the language or subject. Put it somewhere safe (ie. git/svn) and keep it as long as you can. Then once a couple of years have passed, take some time to look at it. There is nothing more gratifying than looking at some old code and thinking: “OMG my code was so stinking awful!!”, nothing more satisfying than executing old handmade programs and games.

For example this past week-end I was looking through my archives from 7 years ago and found an old fizzbuzz.rb file laying around with some other ruby source files! I was pretty excited to look at it since I’ve never been a huge fan of it:

# I am part of the chosen 1/200th!!!! :)
# http://blog.codinghorror.com/fizzbuzz-the-programmers-stairwa
y-to-heaven/
(1..100).each{|i|
    if i % 3 == 0 && i % 5 == 0
        print 'FizzBuzz'
    elsif i % 3 == 0
        print 'Fizz'
    elsif i % 5 == 0
        print 'Buzz'
    else
        print i
    end
}

It still executes fine:

$ ruby fizzbuzz.rb

12Fizz4BuzzFizz78FizzBuzz11Fizz1314FizzBuzz1617Fizz19BuzzFizz22
23FizzBuzz26Fizz2829FizzBuzz3132Fizz34BuzzFizz3738FizzBuzz41Fiz
z4344FizzBuzz4647Fizz49BuzzFizz5253FizzBuzz56Fizz5859FizzBuzz61
62Fizz64BuzzFizz6768FizzBuzz71Fizz7374FizzBuzz7677Fizz79BuzzFiz
z8283FizzBuzz86Fizz8889FizzBuzz9192Fizz94BuzzFizz9798FizzBuzz

No major WTF moment. I looked at my code and actually had a couple of positive thoughts:

– I’m glad I put a small comment in there, it helped me remember that I wrote this code after having read Jeff Atwood’s article back in February 2007. This was the first time I had read about it and my reflex was to put it to the test.
– The code gives out correct results.
– The code is pretty readable.

And now I was also glad that 7 years later, a couple of things jumped out at me:

– The if conditionals can be rewritten so they are more readable
– The modulo math operations are performed twice
– The code has a bunch of magical numbers 1, 100, 3, and 5, preventing any easy change in the problem text.
– Nothing is tested

In a couple of minutes, I knew which parts of the code I could improve. Some of the stuff that I didn’t know about 7 years ago had now become reflexes. I then proceeded to write my new perfected version of FizzBuzz and hope to look at it in 7 years.

You never realize how much improvement you’ve made as a coder until you’ve looked at yourself as a coder a few years back. It lets you become the user of your own creations, and it usually brings back some fond memories. A month ago I fell upon this game I created back in college 10 years ago and had a blast finishing it even though it has many bugs (don’t try to skip the intro!!):


You can try it here: ICWars Java Web Start
(self-signed, might trigger some security warnings)

(In game: arrows to move, space to shoot. In starport: arrows to move, enter to select)

Your old code shows your creativity, your weaknesses, your strengths, your evolution and your improvements. It helps you stay humble and patient towards others coders. It’s your history in the byte world. It is precious. I urge you to keep it safe.