Oct 27, 2012

Get your head together


Ideas are what moves this world forward. The special thing about ideas is, we all have them.
The difference is made when you act upon an idea instead of just forgetting about it.
One reason people choose not to act on an idea is a feeling of the idea being incomplete.
Most times they are right, an idea is rarely fully functional at first and the first idea is almost never the best.
To act upon an idea you first have to groom the idea, give it time to grow and look upon it at different times while in different emotional states.

An obstacle in this is finding a way to catalog your ideas.
Most of the time people trust themselves not to forget their ideas. While this can be true for the basis of the idea, the details of an idea are easily lost. This means you always have to start from scratch, disabling the possibility of ever creating a meaningful idea to act upon.
A second common practice is scribbling an idea on a piece of paper. This is a vast improvement over the memorizing technique but still isn't flawless. Unless you are a very tidy person you're bound to lose some or all of your loose papers. Even if you manage to keep them all together it's easy to get them out of order which can create confusion when going back to them later on.

Now, the solution to this will be different for everyone, but I have found a way that works well for me.
Contrary to what you might think it isn't a digital system, mainly because an idea isn't always definable in words.
Secondary because an idea can occur anywhere at anytime and computers aren't always at my disposal and I don't own a smartphone.
Before I can get into my solution I have to define what I mean by idea in the context of this article.

When I say idea I mean any form of thought that can spark a future project. This can be a drawing, a basic premise for a game, a robust outline for a main character, a possible solution to a problem you're struggling with at the time, etc...
It can also mean a thought process you are currently going through. For example a step by step rundown of a solution you are defining as you are writing it.

Using this basic definition for what I mean when I say idea I need to make a second side note to my solution.
While the basic implementation is the same, I have to divide my method into a professional approach and a personal one. This may not always be the case, but it is for me, solely due to the difference in nature of the ideas needed in these contexts.


Phew, now that we got that out of the way I can sum up my solution in a single phrase : write everything down in a hardcover book. I guess you were expecting something more radical or life changing than this but allow me to explain why this is a game changer.

  • It's easy to lose a piece of paper, it's far less easy to lose an entire book. It's not impossible of course but if you're anything like me this book will become an extension of your brain and you'll regard it as a very valuable possession.
  • Books are chronological by nature, meaning you will always be able to determine what part of an idea sparked a different part of it.
  • A book is highly mobile. Mobility is a big buzzword these days but books had this figured out ages ago. You can always fit your book in a bag or even in your jacket and whenever an idea pops up you can simply write it down. No need to frantically start a search for paper.
  • My final reason, and this is a big one, is that you can review all of your ideas when you have some time to spare. You can read up on what you've been writing at any time and this might help solving a problem you first believed impossible to solve. Often I find an idea I scribbled down ages ago which I totally forgot about, sparking a new idea that would never have existed if it weren't for my book.


Now for how I use it. This is highly personal and you'll have to find you're own way of doing things. In the long run this book will resemble how you think about stuff and how you link things in your mind. I will start of by explaining how I keep my personal book which only has a few rules and end of with my professional book which is far more structured and even has a legend.

I use my personal book mainly for drawings and game concepts.
For these I only write down a title, a number of occurrence and a date. For example if I had an idea about a game where you play a monkey jumping from tree to tree the title could be Tree Jumper.
The occurrence simply shows how many times I've written about this idea. So if I had in the past written down the basic idea and now I have an additional idea to add bananas to the concept that grant you extra powers I would title it Tree Jumper #2.
The date doesn't need explaining. Knowing when an idea was written down can give you an indication of how long something has been on your mind and what state you were in when writing it.

In my professional book I write down meeting notes, database models, contact information, coding examples, thought processes, etc...
In this book it is very important to be able to find a certain item quickly and to easily refer to items from within other items.
The basic title is build in the same way as in my personal book : title + occurrence + date. However it is preceded with an overall index. The very first item in the book starts with 1) title + occurrence + date, the second 2) title + occurrence + date, etc... This makes it possible to refer to an item from within another item by simply adding #itemIndex. For example, "the database model for this project can be found at #18".



Another addition is labeling the items with icons and project numbers. I don't do this in the title but in the bottom corner of the page. One icon I use is '|-|', meaning a meeting. I can quickly go through the book looking at the icons in the bottom corner of pages in search of meetings for project 1 by looking for |-|P01. The first page of the book lists all used icons and projects.
A last trick is to write down all the dates used on a page at the bottom as well. This speeds things up if you know you worked on a certain project in a specific month without having to look at the titles.





As I said, this is a highly personal approach and everyone will have different systems to find order in their book but I know this has uplifted the quality of my work and freed my mind of having to memorize all my ideas. I know other people who also use a book to keep track of their ideas and use it in very different ways but have been benefiting from it as well. I can only advise you to give it a try, keep it up for a few weeks and I believe you'll be surprised with the results.

Oct 25, 2012

Don't let the bedbugs bite


If you've been a developer for a number of years you'll have come to terms with it by now : you will write bugs... often.
When writing a piece of software you tend to work towards one solution and get in a state of tunnel vision not seeing clearly the effects this new code can have on other features.
This in itself doesn't mean you are a bad developer. It is how you deal with those bugs that defines the quality of your work.
In past years I used a number of systems with various degrees of success. In this article I will describe my own experiences with these different approaches. These experiences may (and very likely will) be different from yours so feel free to comment and discuss in the comments below.
Also note that a bug tracking system can only be as good as the way you implement it in your workflow, something that most likely tainted my experience with at least one of the systems below.

Basecamp

The company where I started made use of Basecamp.
For those who don't know, Basecamp is a project management tool which allows you to share information, milestones, assets and much more with clients and colleagues on a project to project basis.
Or how they put it on their own website :
Basecamp keeps all your projects, data, and people in one place. No matter how many projects you have, or how many people you have working on them, Basecamp keeps everything organized.
As you can see it's a behemoth and one of the industries standards. For our purposes however it failed to please. We were a small company needing only a fraction of what Basecamp offered and for many projects clients insisted on using their basecamp, scattering around our to-do's in multiple places.

Taskii

Because the development team was getting frustrated with bug tracking in basecamp an intern got asked to create a lightweight todo program. This idea had been tossed around the development team for quiet some time but never found it's way to someone's desk.
The aim was making a standalone tool that could be installed on a developers machine in which they could manage their own todo lists. If you had the right permissions you could also add or modify todo's for colleagues.
The arguments for making our own tool were

  • no costs (except for the development cost, which was underestimated)
  • adaptability
  • keeping our todo's on our own server
  • in the long run even commercializing the product.

Even though @WWWillems made the most of Taskii with what we gave him the project was never fully operational. We had vastly underestimated all the small features a good bug tracker has to offer without really being noticed. After an initial testing phase and the conclusion of @WWWillems internship the project was abandoned.

Code Base

In the years that followed we mainly returned to basecamp untill codebase was coined as an option.
Starting from essentially the same promise as basecamp it's weird that codebase took our hearts by storm. Keep in mind that at this point we weren't only looking for a bug tracker, we also needed a place to safely store our code (svn) and track our time.
Codebase seemed to cater to all our needs and became a centerpiece of our development workflow.
It has to be said that at this point everybody on the team was convinced for the need of a bug tracking tool, something that hadn't always been the case. As stated earlier : a bug tracking system can only be as good as the way you implement it. That can't be overemphasized.
One way to get the most out of codebase is connecting your tickets to your source control system, milestones and time management system.
But in regards to bug tracking codebase has one major flaw: it can be difficult or even impossible to filter tickets in just the way you want it and getting to your tickets isn't a one click operation.
I still use codebase to manage projects I'm making in my free time. It's not overly expensive and gives me a place to not only track bugs but also store assets, ideas, code and documents and makes it easy to access them from any computer connected to the internet.

Mantis

I changed jobs at this point and in my current job there is no need for many of the feautures codebase offers.
Code is stored using Perforce on an internal development server while documents and assets are kept internally as well.
So when it came to choosing a bug tracker, codebase was deemed too heavy for our purposes.
Instead we went with Mantis, a bug tracker my colleague had used in the past.
Mantis is a bug tracker, nothing more, nothing less, but a very good one.
It is a little daunting to start out with as an empty Mantis database results in a home page only showing a vast amount of filters and no data. But once a labeling system is agreed upon and bugs/feature requests are starting to fill the system you can easily see how Mantis speeds up development time.
In addition to the default filters, you can create your own labels to add to issues (for example 'Reporter age' if you wanted to sort on bugs reported by kids of a certain age)
Once a filter is created you can store it as a permalink, a custom URL that allows you to bookmark the filter and access it in one click anytime you need that particular set of issues.
If you're looking for a good bug tracker and you don't need any other features I can highly recommend Mantis.

Pen and paper

To finish things up I have to add pen and paper as a last bug tracking device. Most developers I know have a habit of scribbling down to-do lists on different pieces of paper and often using them throughout a project.
This practice is sometimes necessary because you don't want to lose your train of thought by going to a bug tracking tool and filling in a detailed issue report while working on something else.
However, keeping to-do lists exclusively on paper is a dangerous practice that can lead to forgetting about certain bugs or even forgetting what 'label not correct' referred to in the first place.
So it's important to add these notes to your bug tracking solution of choice whenever you get the chance if you don't want to smack yourself in the head afterwards.

Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Powered by Blogger | Printable Coupons