Pocobor.

MIT ASSIST Sketch Understanding System

I’m always interested in learning about new design tools since the tools we use are so integral to the whole engineering process. Good tools make design fun, while bad tools keep you up late at night cursing at your computer screen. I recently came across a video of MIT’s ASSIST Sketch Understanding System in action. Basically it’s a smart whiteboard on steroids, that allows you to simulate physical systems simply by drawing their initial states and pressing play. I would love to have one of these in our office.

It was developed by MIT’s Computer Science and Artificial Intelligence Laboratory. You can learn more about that lab here.

Me and My Ninja Ducky

Rubber Ducky Debugging

I was recently introduced to the software debugging practice known as “rubber duck debugging” (I credit this indirectly to this Reddit post).  It’s an incredible methodology with an extremely low barrier to entry – all you need is a rubber ducky. Seriously, all you need is a plastic floatable duck, the one we all know and love (or better yet a ninja rubber ducky). You might be asking yourself, “What can an inanimate floating bath tub toy do for my software?” The truth is that ducky could save you hours of pain and suffering and maybe even earn you a couple of uncomfortable stares from your co-workers.

So How Does This Work?

1. Buy a rubber ducky from Amazon (what don’t they sell?)
2. Place ducky on your desk facing you
3. Explain (out loud) your buggy code or algorithm to your ducky
4. Laugh out loud when your ducky finds the bug

So Why A Rubber Ducky?

Why not? Plus you feel pretty bad-ass when you’re coding with a Ninja Rubber Ducky. Honestly, all you need is a sounding board to sort your code out. It’s pretty easy to get the blinders on when you crank out a couple hours worth of software – from time to time you’ll notice that your brain and your typing don’t align, especially when fatigue sets in. If you are forced to explain your code to someone (even your rubber ducky), you’ll easily find the places where your intended functionality does not match the code you wrote. By using the rubber ducky instead of a busy co-worker, you can sort through the obvious problems without needlessly disrupting the workflow of your company.

Funny thing is I’ve been doing this for years, just not so formally. I am always more effective after the 9 to 5’ers have stepped out because I tend to talk to myself, Mr. Compiler, or Mrs. Computer when I write software. Now I feel open to talk during normal business hours because I’m talking to someone, my rubber ducky. I haven’t decided if it’s more bizarre to be talking to myself or a rubber ducky – regardless, the ducky definitely adds some personality to the discussion.

Software Standardization

Why Standardize Software Styles?

As a mechatronics firm, we write a great deal of software. When handing software over to clients it is important that there is a certain look and feel that is consistent with Pocobor’s standards. One reason for this is that if code is standardized internally it makes it easier for co-workers performing code reviews, because they are used to seeing that style (since it’s the same style they write in!).

Another reason is marketing. A basic assumption is that any code that leaves Pocobor will be robust, dependable, and easy to follow. Having the same style allows clients to become comfortable with Pocobor’s brand of coding. But if our style changes from project to project (or within one project depending on which one of us wrote it) then our clients will not be able to recognize Pocobor code. Furthermore, they would have to get used to a new style for every project.

Why Would it be Easier to Read Standardized Code?

The main reason it’s easier to read code written in the same style is because of consistent naming conventions, function structure, and other stylistic aspects. So, when you see a variable named “EmployeePtr” you know a) that it is a global variable because its first letter is capitalized and b) it’s a pointer because all pointers in your particular style has “Ptr” at the end of the variable name. There are other ways to do this, for instance there could be a software convention where the same variable would be “pEmployee_g” (just an example). In this case the “p” proceeding “Employee” indicates a pointer variable and “g” indicates a global variable. The point here is that if everyone in your firm/lab uses the same style it will be much easier to read one another’s code.

How Do I Standardize My Firm’s/Lab’s Code?

Creating a standard programming style is challenging because everyone develops their own styles and habits through professors they had at college, blogs they read, and just from programming for years upon years. Initially, we thought we would sit down and create a programming style guide from scratch. We immediately realized how foolish that would be because there are already a lot of very good style guides created by experienced programmers.

After much googling and reading opinion upon opinion of what constitutes good programming style, we ultimately decided to go with Linus Torvald’sLinux Kernal C Coding Style“.  If your are not familiar with him, he is the person who initiated the development of the Linux Kernel and now acts as the project’s coordinator.

There are other style guides out there, but we liked and chose this one. The most important thing is to standardize your code style (using an established style guide), not the specifics of the style guide you choose.

What About Concepts not Covered in the Style Guide?

Often, one guide may not be enough to cover every aspect of code. You can fill in the blanks yourself or you can find other documents that discuss issues such as file templates or variable naming styles like camel case (e.g. “employeeName” vs. “employee_name”, where the first is an example of camel case naming convention). Ultimately, the goal for us was to find a style that we thought would produce the best code, and then to make sure we all use it.