Step 4: Decide whether to create or contribute

As you get closer to settling on a good concept for your project, you may start to wonder whether creating a whole new solution is really the best direction to take, or whether contributing to an already existing one would be the smarter choice. While both are noble in their own right, it is important that you keep in mind that every bit of code you add to your résumé should be an investment into your future. So before you jump into taking on either of them, you should establish which of the two will be the better investment of your time. Let’s begin by weighing up the advantages and disadvantages of each approach.

There are a lot of really great advantages to be gained by creating a new project. Taking responsibility for the entire development of a product from start to finish shows that you are flexible enough to be slotted into any phase of the development cycle. Creating something from nothing also displays a keen ability to take initiative and be creative when faced with a problem. Possibly the greatest advantage however, is the educational benefit of having to learn a subject intimately in order to produce a solution for it. Of course, there can also be disadvantages to this approach. You run the risk of appearing unimaginative by writing something redundant, or perhaps introverted by working alone, but realistically these can be avoided by having a little creativity, and eventually by introducing the involvement of others into your project.

Although I generally lean towards creating, there are definitely advantages to contributing as well. Probably the most convincing argument for contributing to a project is if the act itself is closely related to the job you’re aiming to get. For example, if the reliability of a certain open source project directly or indirectly affects the success of a company you aim to work for, aiding in the development of it could earn you significant favour with them. If the company itself is an open source establishment, working directly on their own projects can be a good way to prove your proficiency in their domain before you apply. Another obvious advantage to contributing is that you will be able to showcase your teamwork and collaboration skills. This however, can be a double-edged sword. Even though patching code can sometimes be more difficult than writing it from scratch, relying on the existing work of others could imply that you need to be carried by them.

When deciding on which direction to take, try not to be swayed by a fear of incompetency. You don’t have to be an expert in the topic you’re writing about in order to produce good software for it. In fact, being an expert can often be to your detriment. I’ve witnessed many accounts where developers have made poor assumptions about the prior knowledge of their audience, and ended up creating products that were too complex for the average person to use. All you need in your arsenal to write good software is a personal interest in seeing the problem solved. Believe me, “showing off” by writing code only you can understand is more embarrassing than it is impressive. Software is most impressive when it takes something that is usually elite or complex, and makes it easy and accessible to anyone.

This entry was posted in Chapter 3: Coming up with a good project idea. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s