Staying Up-to-date : Newsletters and Resources

Software developers and programmers work in one of the most volatile of environments, things evolve fast – API upgrades (which imply code obsolescence :P), new technologies (nodejs is about 4 years old only, yeoman was only released in 2012, Hadoop etc) and the emergence of new language releases and tools.

Programmer have to actively follow new trends to avoid playing catch up with the rapidly changing landscape. Curiosity is a great quality of the programming trade and programmers should ideally itch to learn why things work, how they work and how to improve existing tech.

Here are a couple of resources that I monitor, I enjoy them and I hope they are useful to programmers too.


1.  StatusCode

Status code is one of my favourites – it is an eclectic mix of information about software development, programming languages, tools and libraries. There is almost always something to tickle your fancy in the weekly releases, from advice on programming to tooling tips to new developments. Updates are not limited to the expected Java/C/C++ combo, Scala, Haskell, Clojure and others regularly pop up now and then.

2. CodeProject

The concise daily reports on industry and development news is something I look forward to. A quick scan of the mail allows me to quickly get abreast what is trending for that day in the Software development world.

Web Development – JavaScript, HTML5, …

1. JavaScript Weekly

This carefully curated selection of JavaScript-related articles is simply amazing. The weekly updates contain libraries, tools, presentations, tutorials, videos and articles. Did I mention that jobs are advertised too?

If you are a web developer, front-end engineer, JavaScript developer or are just plain interested in JavaScript; then you should try to follow this. At times, the list of ‘goodies’ might be too long however the short descriptions beside each link should make it easy to decide if you are going to check the link or not.

I keep wondering how the curator is able to keep finding new things week after week.

2. A drip of JavaScript

This awesome weekly post on JavaScript usually has a simple description of a single area of JavaScript. Joshua Clanton does a really really beautiful job at explaining things and making them clear with examples.

I have learnt a couple of tricky things about JavaScript from this and gotten a deeper understanding of the language. I wish there were weekly drips of Java and Python too.

Warning: the brief write-ups are usually dense so you have to dedicate some time to understanding it.

3. Ember Weekly

Ok, I write code using EmberJS and this allows me to ‘keep’ my eyes on the project (they seem to update it rapidly), it also allows me to follow the community and see what is happening there. Like others, it includes links to articles, videos/screencasts to watch, code samples as well as the ever-ubiquitous job postings.

4. Node Weekly

Node weekly is new, in fact I think the fourth issue was only published one or two weeks ago. It contains information on the NodeJS paradigm, there are articles to read and code samples to peruse. Some useful libraries and tutorials are sometimes included as well.

5. DailyJS

This has information on some topics in JS and is available daily. Most times I take a cursory glance at the contents and at times I go to the main website to check out information. Oh, they do have a LOT of articles on the website.

6. HTML5 Weekly

This is strictly for web developers and designers; it is a good source of updates about topics like websockets, HTML5, WebGL, CSS3 and browser updates. There are also links to tips and demos of exciting stuff.


Pycoder’s Weekly

Python projects, jobs, news, new developments, articles and possible upcoming events. It is a cool way to keep tabs on developments in the Python community. Yes, it’s only once a week too so you don’t get information overload.


Well, since I rarely program in Java nowadays (just the odd snippet or Android app at times) I do not actively monitor developments in the community. However I still follow these channels:

1. Java Magazine

This is published once a month and is usually a huge nicely designed magazine available online. I particularly enjoy reading about the interviews with industry experts and the puzzles at the end of the magazine are quite nice too – although I can not solve most of them because I lack the necessary Java expertise.

It is also a cool way to catch up with trends in the Java Community.


1. Full Circle Magazine

This magazine is published by enthusiasts and usually contains one or two columns I find interesting. It is available on a monthly basis and primarily focuses on the Ubuntu class of operating systems (Kubuntu, Ubuntu, Lubuntu etc). The magazine contains news, tutorials, a QA section, some cartoons and the ‘pimp my desktop’ section (I like).

If you know of some other great resources, please do feel free to share them.


The Art of Debugging

I recently wasted a lot of time while attempting to use the amazing Dropzonejs image uploader. I left out a function call in an overloaded function and this broke every subsequent call. More annoyingly, I could not pinpoint the cause of the error as Dropzone was failing silently.

Close to giving up, I decided to give it one more attempt and went to my sandbox – I create a safe area in all my projects for doing ‘risky’ stuff. Starting afresh there, I was amazed to see that everything worked fine. A close comparison of the code samples revealed the bug’s origin – the left out function call. I double-checked to confirm this and that was all about it. Sadly, the documentation does not mention that a failure to call done() in the accept function will break the code silently.

Programmers usually spend a lot of time debugging and it can be a painful experience;  some feel like tearing out their hair in exasperation, smashing their poor computers or even believing that their computers really ‘hate’ them! :)

Actually computers do not hate people and the operating system is not conjuring bugs – the most likely reason is buggy code. Here are a couple of tips on debugging; hopefully these will help to reduce time spent, frustration and annoyance levels.

The Inefficient Way of Debugging: Trial-by-Error

Random guesses? Print statements littered around? Fast fixes that ‘appear’ to work? Do these ring a bell? Welcome to the bad bad way of debugging.

This approach is fraught with a gazillion issues. The worst being the potential introduction of new bugs into the codebase. Lucky bug discoveries offer little learning opportunities and it might be difficult to reuse knowledge gained from such fixes in the future.  Also, such run-of-the-mill fixes tend to be inelegant and stand out like a sore thumb when compared to earlier designs and architecture.

The Efficient Ways of Debugging

1. The very first thing is to create a list of the likely causes of the bug; this usually involves thinking deeply about loopholes and design flaws. Studying program error dumps and buggy behaviour might also help.

2. Go through the list while eliminating disproved hypotheses. Once a likely cause is found, a verification needs to be carried out; this can be as simple as proving that the bug appears only when that cause is activated.

3. Don’t just rush to write a fix – I bet you would not want your ‘super-fix’ to mutate into a monster ‘bug’. Think deeply about the bug and what potential ripple effects a fix could have. Also think about how the proposed fix would work, how it blends into the system’s architecture and possible design impacts.

4. Yes, you got it!! Go ahead and squash that bug! Yuck – I dislike bugs.

5. Not finished yet, you need to go through your code armed with your newly acquired bug-terminating powers. Find and ruthlessly sanitize code likely to suffer from such bugs. Rinse and repeat – always leave code in a cleaner state than before.

Extreme Approaches: When the Efficient Ways Fail

You might apply all the above and still be stuck in a rut; this might occur if you have extra-terrestrial bugs (quite popular in multi-threaded environments).

6. Total examination

The brute force approach is bound to work insha Allaah although it involves painstaking work. You go through the code thoroughly (a debugger should come in handy); this might involve examining all execution paths if possible and trying to pinpoint the issue. Hard work…

7. Start afresh

When everything fails, why not throw out the old code and write it again?

Some other tips

6. Very important, set a time limit

Do not spend 3 days hours trying to fix a bug if you can re-implement the same feature in 2 hours. If you are sure you can rewrite a bug-free version of some buggy code, go ahead with a rewrite and spare yourself the trouble. Time counts.

7 Learn to use tools

Debuggers, memory examination tools and profilers. They will help point out to what might be causing the issue. I once had a really really nasty bug while using jQueryUI, the bug only showed up on a particular browser and only when the page was accessed over the local network; otherwise all was fine.

I eventually had to use a profiler after several failed debugging attempts, I  then discovered that a function was being called several hundred times. Bug case solved!

8. Discuss with a buddy

Find a programmer / buddy to discuss with, discussing your ideas with someone will help you to find design gaps and flawed assumptions; you might be surprised that you get the error spot on without any contribution from your buddy.

Now go ahead and eliminate some bugs :).

EmberJS: The Rant

So I started on EmberJS some time last year; after spending an inordinate amount of time trying to design a prototype with people located all across the world. Finally, after several dreary demanding iterations and lots of work, we finally agreed on an implementation.

One of the dev members suggested using EmberJS or backbone. Based on his review, backbone was the easier choice: it had more support, good documentation, lots of tutorials, books and thousands of stackoverflow questions (a good measure of  tool/framework/concept popularity).

My own review confirmed these but I stubbornly stuck with EmberJS – I don’t know why, maybe I like challenges or maybe I just wanted to be different. Furthermore, my review revealed a few advantages of using EmberJS over Backbone so I dived into it.

I soon came to regret my decision; after a couple of tutorials, I seemed to be getting no where closer to understanding the framework. The problem was the volatile nature of the EmberJS framework, most tutorials would only work if you used the ‘matching’ framework release. The Ember team was most probably working themselves to the death to get it stable, however, for me, it was challenging, frustrating and annoying to use the framework.

Alhamdulilah I finally got it to work – my first attempt felt ugly and inelegant (add whatever else you like ) but it did work and that was fine enough for me. I soon fell in love with all the extra goodies and automatic help it provided; my colleague was soon inundated by my fawning; most probably he got tired of hearing me say ‘EmberJS is coooooooool’.

Organizing the application proved to be another challenge too; I had a huge ugly proliferation of files – controller, templates, views etc. RequireJS, an AMD loader provided a solution but not before nearly driving me crazy; I inadvertently swapped some parameters in the module specification and had to spent the better part of an hour trying to understand why the login object was a registration object. (Imagine trying to find out why a dog is a cat).

So after weeks of development and finally getting the app nicely running, I got another shocker. There was a new release of EmberJS and guess what? It was not backward compatible! To the credit of the guys though; the new release was awesome, had excellent documentation and was much easier but all I saw was the fact that I’d need to rework everything. All my sweats, efforts and tears were going to go down the drain just like that! No way!! I stuck with the old way and old api – it was much easier for me and upgrades aren’t compulsory.

I have learnt at least two things: one, if you use code that is in rapid flux then you are O.Y.O (ON your OWN) and two, stop testing the waters with your feet, just jump in! If you want to try something new, go get it done!

Back to the story; we did a system redesign again (yes, for the umpteenth time). I believe we are in good shape to do a great job now insha Allaah and yes we are upgrading to the latest EmberJS release – we have some veterans now.

Enough said, I have to get back to work :)

Job Hunting 101 for Students

Yes, I am still continuing with my posts on Grad School, research and all-of-that. The big question for most of us towards the end of school is ‘Whats next?’, a lot of us want to get jobs immediately afterwards but realize too late that it’s much more difficult than we thought. Here are a couple of tips.

1. Get the skills you need while you’re still in school

Learn as much as possible: leadership, teamwork, computer literacy, and relevant industry skills. Once you acquire these skills, relentlessly hone them till you stand out. There are always ways to excel: software packages to learn, online courses to take and certifications to earn.

Ideally the learning process should start years before you graduate. However, if no one ever told you this before, then start now! No, graduation is not so far away; it’s much closer than you think.

2. Network, Seek mentors

The easiest way to get a job (in my opinion) is through referrals – Mr. A knows Mr. B and refers him. Be bold and confident, create a really polite email asking to be a protegé and tell your potential mentors about your aspirations and career goals. You’ll be surprised by the amount of help mentors can offer through their network, experience and wisdom.

I have gotten referrals through my friends and mentors, so I know it works, try it out too.

3. Prepare a strong CV and cover letter

Your CV is probably the first measure of your skills that your potential employer will see, so make sure you dedicate lots of time to it. Sanitize your online profiles, review your LinkedIn profile (create one if you don’t have any) and create accounts on job portals.

Ideally your CV should be one page long; if you have more pages you probably should cut some insignificant detail. Jump start your rewrite with these templates here. Create a cover letter too, this might make the difference.

4. Apply to Jobs, internships, everything

Apply for every promising opportunity: the more applications you send out the higher your chances of success. I am not advocating applying to jobs requiring 90 years of experience in alien technology for Saturn – you’ll end up wasting your time and that of the recruiters.

You should have an application strategy, create a list of organizations you like and apply to them. If you don’t meet their requirements, go to step 1 above. Since you have nothing to lose (and a lot to gain), you should apply to other firms too; if you don’t get an offer, at least you’ll have learnt more about the application process.

Important! It’s always better to reach out to the recruiters and/or people in charge of recruiting directly. I’ll give you two stories; someone I know applied for a job and he noticed that the HR manager at that firm looked up his LinkedIn profile. However, when he got no response, he found the email of the HR manager through Google, forwarded a strong cover letter + CV and got an interview request in about 48 hours! Amazing, huh?

I have also met a recruiter who told me they sometimes have to go through 1000 CVs/week, eek! What are your chances out of 1000?

5. Go to as many interviews as possible

You’ll become more confident and better at ‘selling’ yourself and your skills. Another added benefit of this is that you’ll learn how to answer non-technical questions (questions like ‘how much do you want?’, ‘why do you want to work with us’).

It also gives you an external perspective of your skill level and allows you to find the gaps in your knowledge (this might be a humbling experience if you’ve overestimated your skills). If you get the offer and decide to turn it down; do it nicely and make sure you keep in touch. You can always reach out to them or refer people to them – it’s always good to network.

6. Improve, improve, improve

After each interview, schedule some time to review your performance and take note of your weaknesses. Make sure you never make the same mistake twice if you can help it.

Also review the questions, did you answer the tricky questions right? Did you impress the interviewers? Go through the experience again and make notes of what not to do at your next interview.

7. Never Give up

If you don’t get the job, send them a nice email thanking them for their time. Politely ask about why you weren’t chosen and use this information to grow.

Never give up! Also remember to pray to Allaah for help as this is very essential.

How I used Pomodoro to boost My Productivity

My semester started late this year – I made a trip to Nigeria to see my folks after an entire year. On my return, I dedicated some time to planning my goals, readjusting to life as a student and set my goals. Despite my planning, I struggled to find a daily rhythm; I was not working as effectively as I wanted and at times I felt I was just frittering away my time. My renewed efforts and strategies also didn’t work – I  even had to fight sleep to meet my targets at times.

I felt somewhat bad when I compared my productivity levels to that of the previous year; I worked really hard during my first year at MASDAR and always tried to push my limits. I marvel at the energy and passion that kept me going on and on and on; maybe it was because I had just left Nigeria, maybe because I  was a stranger; maybe not, maybe I wouldn’t know. One thing for sure, I was in a new challenging environment, everyone was nice and I had time to dedicate to work and boy! Did I work? I gave my all and rapidly got burnt out often. Now, getting burnt out is NOT good : Avoid it!

Want to achieve high levels of productivity, produce high-quality work and not get burnt out? Try Pomodoro. Pomodoro is a technique that enables you to dedicate 25 minutes to a single specific task and then take a five-minute break. It basically involves setting out 25 minutes blocks of intense focus – yes I.N.T.E.N.S.E focus; you cut distractions such as phone calls, emails, interruptions, focus on just one task and give it your best. The elimination of multi-tasking enables you to perform better and achieve goals within shorter periods too.

I first stumbled upon Pomodoro back in 2011 while I was working at Terragon but I dropped it later on. I rediscovered pomodoro while I was checking out apps on the Chrome web store  (i.e. a form of distraction that is equivalent to wasting time) and decided to give it a second shot. First, it was great to read Francesco Cirillo’s story; his reasons for inventing the technique and then learn how to properly apply the technique. My next steps involved a reorganization of my activities to fit into the model; I then forced myself to adjust – I initially found the 25-minute blocks to be too long.

Pomodoro has helped me improve my planning and estimation – I now know what I need to do every day and have a better idea of the effort involved. It has also worked wonders for my focus: I used to be easily distracted and usually gave up easily. However with pomodoro I know what I want to achieve whenever I start out a pomodoro block and I can dedicate my efforts to achieving the best results or completing the pomodoro (whichever comes first; it’s a win-win for moi). Best of all, I can work optimally for extended periods without getting burnt out; now, that’s  pomo-tastic! :)

You should try it out too; I am not guaranteeing that it’ll work for you ( it has sure helped me to get things done Alhamdulilah) but who knows? It just might…

Are developers better than testers?

A lot of people view testers as second-class citizens; probably because QA guys rarely ‘create’ stuff like devs do (although they sometimes do original work creating test frameworks and platforms). They are more similar to editors who verify the work of authors. However, testers are just as important as developers; without QA the end product is bound to be buggy and might even miss out on the requirements!

Developers usually believe they write bullet-proof code, (after a couple of ‘subjective’ tests which assume some ‘condition’ will never happen and so on…); however as we all know it; this is not true. I believe every software project requires testing – yes QA is that critical. You can’t be really sure that some complex piece of code works properly, you can only be sure that you didn’t find bugs. Even well-known APIs, languages and frameworks have issues, for example, a bug was found in the Java implementation of binary search some time ago.

Testing requires a different skill set from development and all programmers will benefit vastly from spending some time as testers. In fact a Microsoft Test lead said the best developers he knows all started out as testers. This is not far-fetched; such test-devs do more automation of mundane tasks, know more about potential failure scenarios and try to guard against it early in the writing process; moreover they test their own more thoroughly leading to more reliable software.

Testers have to make sure the product is robust, matches the customer’s requirements and find out flaws the developer probably overlooked while writing his code (e.g. passing in wrong parameters, graceful degradations, bad failures etc). They always have to devise ingenious testing scenarios that expose flaws and defects in system design and/or implementation. Contrary to opinion, testing might involve writing code to test code (automation) and building testing frameworks/platforms; some testers probably get to write more challenging code than developers.

Why do devs/PMs etc dislike QA?

Imagine having to tell proud parents that their beloved child is ugly? Sounds tough right? QA guys have the unpleasant duty of pointing out the flaws in the work of devs and PMs. Well, no one likes to be criticized or told they made mistakes after working so hard on a feature. It’s not difficult disliking guys who routinely point out the flaws in the design, system implementation or find out bugs in your code.

Pros of QA work:

  • Testers understand the project requirements and have a wider knowledge of the product life-cycle.
  • They ideally work well and interact with a lot of team members – PMs, devs and other QA guys.
  • They learn to be patient carrying out repetitive work and come to appreciate automating lots of things.
  • They have great analytical skills – well that’s all what testing is about right?
  • They learn how to communicate, how to be impersonal and tactful and how to diffuse tense situations when they happen.
  • Testing skills come in handy if you ever switch to development.
  • Replacing good testers can be a very difficult task… talk about job security ;)


  • As I said earlier no one likes being told their brainchild is ugly even though it’s true. You might have to handle friction.
  • Yes, it might get extremely boring repeating the same things but you can always up your game.
  • Testing experience might not count as development experience.

Well, if you still believe developers are better than testers; that’s fine. Just learn how to test your code properly and save us all the pain of bad software and evil failures. Moreover, don’t feel bad if a tester shows you 7 bugs in your one-of-a-kind-awesomeness-embedded-wonderful-piece-of-code.

Still think testers are inferior to devs? Have your say in the comments.

Clean Code, Dirty Code

Phew! It feels like forever since I wrote a blog post; I have been extremely busy – finished an internship and had to travel back to school. Well, I actually have a couple of drafts but didn’t get to publishing them. Am I too lazy? Na you sabi… :).

I don’t know why I seem to keep talking about code and JavaScript nowadays, I just can’t seem to stop; probably because I think JavaScript is the next BIG thing; what other language is currently experiencing rapid widespread adoption on all major platforms? Read this  and this if you want to know more.

Back to clean code; clean code is what we developers should aspire to write, it is clean, minimal, simple, easy to understand, free of extraneous details, it is simply BEAUTIFUL (there I go again… drooling about software right?). Ideally you shouldn’t be able to remove pieces of it without breaking the system. Less code is always better, the less code you have to write; the better your system. Jeff Atwood actually says the best solution is no code at all.

So what makes code dirty? Anything that makes it a pain to modify, work with or extend. Abstruse code, duplicated logic, global state and variables, tightly-coupled dependencies, contorted flow (I mean those convoluted loops and if constructs), wrongly-exposed variables (it-shouldn’t-be-there-but-I-can’t-help-it-syndrome) etc. In fact, if your codebase doesn’t read easily then you should get into it and clean it up. It’ll go a long long way in saving you painful work in the future. I have worked on a multi-thousand line codebase (> 25k lines and written by lots of people) and found it easy to handle and understand; in contrast I also inherited some smaller codebase (< 4k lines and written by a single person) and it was a pain to extend.

How to get there? Do Code reviews, relentlessly refactor and make sure you don’t leave anything to chance; you have to be professional about your job and code.

Here is an example in pseudocode:

function showMessage(message){
    if(message != null){
        show(defaultMessage); //This is the default action to do

Alright; lets clean this up

function showMessage(message){
    if(message == null){
        message = defaultMessage;

Isn’t the second version just cleaner and easier to use? Here is another example:

        //do Something
        //do Some other thing

The alertUser() function is getting called in both conditional branches so it can be moved out. Less code, simpler code, easier to read. Here is the cleaner version:

        //do Something
        //do Some other thing

I feel that writing clean code is even more important than solving the problem you set out to solve. Most of our time is spent extending code, writing fixes and maintaining existing code. Keeping it simple and nice at the start will go a long way in making your job and mine easier.