Funny programming images

Since I said I would post once a week to this blog and am currently in the process of writing “Why my girlfriend needs refactoring” which is taking me hours to write. In the mean time, here are a few funny programming related pictures I hope you enjoy.

The exceptional programmer

Disclaimer: I am not suggesting I am personally an exceptional programmer. This is just what I have noticed after interviewing a range of programmers and what makes them stand apart from each other. It’s only my personal opinion.

Usual programmers as those who show little passion for the industry, they get up, go to work, do just enough, and call it a day. They do not go that “extra mile”, there is no motivation to be the best at what they do, there is no pride in the code they write or a desire to learn more just out of sheer curiosity.

This blog post is an attempt to explain how that “usual” programmer could theoretically transform into an “exceptional” programmer if they wished to. The idea is that some of these ideas will be something you yourself will want to consider doing. After all, you are already on your way to standing out from the crowd because your reading my blog!

Learn a new language – non commercial reasons

There are hundreds of languages you can learn. Many are academic based and haven’t been picked up for mainstream commercial use. However, that does not mean they are of no use.

When picking your next language you have choices to make about the reasons why to chose it. Try and pick ones that are new to your skill set to increase your learning curve as much as possible.

  • Is it a different style of syntax that you have never worked with before? Such as going from C to Pascal.
  • Is it a different paradigm? Such as going from Object Oriented to Functional.
  • Is it specialised in a particular field such as maths, games development, distributed programming, etc?
  • Low/High level? How low or high level is the language? If you are used to high level programming in languages like Java or PHP. Why not try ASM? You will learn a huge amount.
  • Is it statically typed or dynamic? Switching from JavaScrip to a statically typed language like C or Go would result in a large learning curve.

The further out of your comfort zone you are, the larger the learning curve, the more you will learn and the more interesting it will be. Gaps in your overall knowledge will affect your future decisions which may may cost you going forward in your career.

Learn a new language – commercial reasons

This is a hard one since nobody knows the future. However, you can always learn the top languages. Learning C#, Java & JavaScript will keep you employable for many years to come. Even if the one you pocked does start to fade out, it will still take many years for that to happen giving you more than enough time to jump ship! Just remember, don’t spread yourself to thin since companies do not like to employ junior leveled seniors!

Become Social

Help others on social sites to create you a reputation. Facebook, twitter, stackoverflow, github, forums and other social media all help you to gain that reputation and get to know other developers in your industry.

Presentations & Conferences

It’s like getting a job. You need to prove you know your stuff! The best ways of doing this is to inspire fellow developers. One of way doing that is to give presentations.

You can do presentations at work, user groups, business networking and conferences.

Try attending a few first and later on become a speaker. You will probably have to get better known in the industry for larger events such as conferences before you will be able to do so but aim high and you will get there. If you want to become that exceptional programmer, giving a talk at a high profile conference will definitely get you that exceptional badge among your peers (and potential employers)!

Write A Book

It takes a lot of time but it really does help give a good impression. Be careful you don’t write a book that becomes obsolete to quickly. A book that becomes obsolete is “Ubuntu 14.04” – in 5 years time there will be newer, better books. “Refactoring OOP Software” would survive for as long as OOP languages exist. Pick wisely.

Bleeding Edge

Once you learn a language some developers get stuck in a job, keep their heads down and only learn what they need to in order to complete the job at hand. Developers such as these run the risk of suddenly finding they are years behind the industry and soon start getting pushed out!

To remain bleeding edge in your industry, try the following

  • Attend conferences
  • Register to newsletters
  • Follow bloggers
  • Check technology news sites
  • Checkout the latest questions being asked on sites like stack overflow
  • Regularly check the latest enhancements in the latest version of the software/languages you are using
  • Follow the industry leaders on github, facebook, stackoverflow, twitter and any other media they use
  • Read the latest books

If you think you know everything, you will not learn anything! Keep your cup empty and listen to fellow developers of all levels. You will never know everything.

Research – Be Inquisitive

Do not learn just enough to get by. Do not use a library without having further knowledge of how it actually does what it does. If you have to sort something and there is a sort() function. Many people will use it and move on.

Be the better developer and research into sorting. You will soon discover a much larger programming scene than you may have thought. There are numerous resources on the matter including various benchmarks, algorithms, libraries, optimisations, sorting structures, indexes, and so forth.

Research! Research! Research!

Learn Design Patterns & Recognise Your Own

Experienced programmers, regardless of the paradigm will start to recognize common patterns in the language they are using. Many have been published especially around OOP such as Singletons, Factories, MVC, Visitors, Strategy, Template and other variations. Once you pickup a pattern, analyse it and try applying it.

Eventually, look over your own coding habits and see if you can extract some of your own Design Patterns. Try publishing them on your blog and see what other developers think.


Go over some of your old projects, find the bits of code you were proud of and analyse it. Find ways you could improve it, fix design problems, speed up functions, anything to improve it. Nobody is perfect. For larger code bases even just “thinking about it” may be enough. After all, this is just an exercise.

There is another very good reason for doing this. If you wrote spaghetti code, didn’t comment it, and added a lot of indirection and bad practices. You will soon find yourself struggling to understand your own code! This will teach you a valuable lesson on how not to write code. There will be areas of code you thought were good until you realised the comments you wrote were a pile of garbage. Next time around, you will write better comments. Other areas you decided to use inheritance and are finding you’re having trouble calculating which methods were overwritten and following the flow of the code from the sub class 10 levels down. You now realise you should have used aggregation and a shallow inheritance tree instead. There will be many more…

If you want to improve your existing coding style and skills. This is one of the best ways of doing so.

Contribute To An Open Source Project

Working with your own code can be hard enough at times, let alone code from someone else! By contributing to open source you are helping the language you use to grow. The large the community and projects out there, the more attractive it becomes for new people to join the community and use the language. It also helps get you a good name among developers.

Blog  (Programming Related)

People that are passionate about something often have that passion shine through in what they do. Why not show it through a blog?

Occasionally Reinvent

Refuse to use that native function, a library or package. Research and create your own instead! This will give you very in depth knowledge and you may be on your way to becoming an expert in that field.

Read A Book

Buy a programming book and read it! Try doing this every couple of months. Trying to absorb as much as you can, practice what it says and see if you can apply it to your everyday tool set.

You will find that as you research on Google and find fragmented resources around the internet and other media. Many of the sources will be incomplete, fragmented and repetitive.

If you want a thorough and good understanding of a topic and quick. By a book on the subject, read and apply what you learn.

Experienced people often write books and transfer much of the knowledge they have picked up over the years into a condensed form that you can learn in a much smaller amount of time. Once you absorb that, you can apply it as if you had much of the experience yourself allowing you to expand on it. Do not waist time, learn from others instead.

Learn Frameworks & 3rd Party APIs

Existing frameworks in your language of choice always have differences. Some design choices are good, others not so good. The more frameworks and APIs you know (not necessarily in to greater detail), the better your design decisions will likely be because you have recognized them from other frameworks. It also helps you learn the skill of reading other peoples code.

Then attempt creating your own framework…

Suggestions & Comments?

If you can think of other ways in which someone could become an exception programmer then please leave your comment below. I will gladly update this post to include anything I have obviously missed. It’s also nice to hear what you thought of this post :)

How to rip apart a programmers CV

You’ve decided that there just aren’t enough hours in the day and you need some assistance. So you get in touch with a few agencies and the CVs (or Résumé) start coming through. The agency try their best to filter out the bad from the good but bad CVs still make it through.

The quality of what comes through ranges from, “I can use jQuery and so i’m an advanced JavaScript developer” to “I worked at NASA and programmed their space bots”. The first one gets through because they have a keyword “jQuery” that is on our requirements list to the agency. The second gets through because it sounds impressive. What does one do?


When I scan over a programmers CV I ignore the following (regardless of how impressive it may look):

  • Any experience, languages or technology that does not apply to what we need in the team. Let us say we are looking for “A junior front end web application developer”. A seasoned C developer with 10 years experience can not instantly morph into an advanced front end web application developer. Even if they have written driver code for Microsoft or Apple! However impressive it may sound, skip it.
  • Ignore the usual template based CV padding such as “I work well in a team” and “I am a highly motivated individual”. They are just words, you need to look for proof (which i will cover shortly).

Ringing alarm bells

There are a few things that should ring some alarm bells that warn you not to employ this person.

  • Lack of matching keywords is the big one. While i don’t like to admit it and many complain how keyword driven the programming recruitment industry is. Unfortunately it is true. You often need specialists and not generalists. If you are looking for a C# or Java developer. You would expect their CV to contain those keywords, in context quite a few times.
  • It’s obvious they have just been keyword dropping. How you ask? Stand back and look at their CV. You have requested developers proficient in “Object Oriented Programming”. So naturally, they have doctored their CV to include the keyword “Object Oriented Programming”. However, they have failed to mention anything else to back it up. I would expect to see some of the following throughout their CV; Design Patterns (MVC, Factories, Singletons, ActiveRecord), Classes, Objects, UML…

Employ this person

So what do I look for in a good programmers CV? In short, passion, self motivation, ability to learn and worked as part of a team.

  • Personal projects is the big one. You are able to see if they are leadership material and maybe the quality of their code. If you made this person a leader in your team, this may be the quality of work that would be produced. Is what you see, what you would like your company to be associated with?
  • Community participation. Are they on stack overflow? Do they have a github account? Maybe a bitbucket account? Run a blog? Membership on forums? These all allow you to see if other developers respect them (or not), see what their attitude is like, and see that they enjoy the social side of programming. This helps you get a glance at what they are like in a team (even if it is a distributed team).
  • Are they experimenting with cutting edge technology in their free time? If it becomes the next big thing, this person could be the one to keep your company at the forefront!


Remember, this is before you have ever met the person! In the end, go with your gut. I will try and do another part to this post about the interview itself covering topics such as ego, questions to ask, and more…