Using techniques from statically typed languages in JavaScript

September 2, 2014 – 8:48 pm

I wrote an article discussing some techniques from statically typed languages. Head over to SitePoint to check it out!

Here’s what you can expect:

Head over to SitePoint to read the article

In order to become a better developer, you must first become a teacher

August 18, 2014 – 1:20 pm

The headline might sound pretentious, but what is the most important skill for a developer besides actually writing code? Communication.

What do you typically do when you communicate as a developer with someone else?

You explain problems, you describe solutions, you talk to non-programmers about what you’re doing. You could also say that you’re teaching others about what you’re doing. Heck, when you’re writing code, you need to comment it and that is also a form of teaching – teaching someone what your thought process was when writing this code.

Being a good communicator is often completely overlooked. Sure, you might see a job placement ad wants someone who has “good communication skills”, but what does that even mean?

Let’s take a step back and think about why it’s really important for a developer to be a good communicator, and then we can come back to how you can become a better developer by teaching – but don’t worry, this process will only require a small amount of effort, although if you enjoy it, you can absolutely spend more time on it too, and reap bigger rewards!

First, let’s figure out what it means to communicate well with other developers. Of course, this includes things such as discussing problems and solutions, explaining your reasoning behind the choices you made when building out some systems, and things like that.

But what is the core skill that you need to be able to do all of the above things? The ability to truly understand all the moving parts in your code – to be able to have a mental image of how it’s structured and how all the pieces fit together to form the whole of the application.

Without this understanding, you can’t explain it to someone else. Sure, you could show them your code, but that’s not really explaining it – you’re just letting them figure it out on their own, maybe pointing at a few functions to push them in the direction you want.

This is why understanding the code and being able to communicate well go hand in hand. Beginning developers will often think about algorithms in a much lower level… “I need a for loop here, and if clause there”… but experienced developers think on a higher level “When a condition is true I need to iterate through these”. Notice how there is no mention of the actual programming language level constructs. When you gain this sort of understanding, you immediately become better at communicating how the systems you’re creating work.

The good thing is that when talking to other developers, you can show them the code even if you’re having difficulties explaining all the things. However, what if you have to explain it to someone less technical? If you’re working in a team, you could probably let someone else deal with it, but if we actually want to become better developers, then this is something we would need to try to do.

People who aren’t developers will not understand all the technical details. You need to be able to take the nitty gritty details of your code and move it into a more abstract level of thinking. Perhaps you can use analogies with something the other person is familiar with to explain things, but again in order to be able to do this well, we need to have deep understanding of the code first.

You might think how does this relate to me? I just like to write code and do cool stuff. I sometimes felt like that as well, but wouldn’t it be really nice to be able to write code and do cool stuff AND get paid for it? The stereotypical case that you might be thinking of here is of course some big corporation because everyone knows they’re full of people who don’t understand anything and blah blah. That is the wrong assumption however.

Some people enjoy big corporates, but for many of us, the dream is to work at a cool startup, or maybe at Google. What is the common thing about these sorts of dream jobs? They get a lot of applicants for all their openings. There are many good coders who get interviewed, but which ones are the ones who stand out? The ones who can also communicate well. A job interview is one of the situations where you generally need to listen, ask good questions, and explain your decision process and choices well.

This exposes another facet of communication: Listening. It may sound really obvious, but listening can actually be difficult. For example, if you explain a program’s flow to some very experienced developer, they can probably picture it in their heads at least partially, even if you don’t explain it perfectly. Explain it to someone less experienced, and even if they listen, they may not really get the full picture.

And now, we can finally come back to the part about teaching. How does teaching relate to all of this?

Teaching requires all of the skills above. You need to listen well to understand the questions. You need to be able to formulate a clear solution, and then explain it in a way the other person can understand.

Now, I’m not saying you have to go to a school and teach programming there. Of course not. What I’m talking about is just helping other people with their questions, even if you’re not an expert. I’ve spent a large amount of time doing this, and it’s one of the reasons why I know about a very wide range of topics.

Helping people with their problems, even when you might not be an expert, will improve more aspects of your skillset than just communication. You might have to do a Google search to help with some topic you’re not completely familiar with, so you learn something new. Maybe the question just gives you a new way to think about some problem.

This is important especially if you aspire to become a team lead, CTO, software architect, or some other similar role. In roles like these, it’s very helpful to have a wide range of knowledge, even if you’re only passingly familiar with it. People in these roles will often need to mentor other developers, figure out solutions to new problems nobody else is familiar with, discuss business requirements, and all sorts of things where knowing that something exists and could help can be very important even if you’re not 100% familiar with its inner workings.

As with all aspects of programming, the best way to improve communication and your ability to reason about code on a higher level is practice. Thanks to the internet, all you have to do is go to Stack Overflow and answer a question. You can answer one question a week and get some practice like that, or you can answer one question a day if you like it… This is what makes teaching a very accessible method of getting practice for communication, and it only requires as much effort as you want to put into it.

So just go out there. Go to Stack Overflow, answer questions. Go to Reddit, answer questions. Talk to people on IRC or forums. Write a blog post. It’s interesting and fun, so why not?

Ever feel like you're stagnating, and not sure what to do next to keep improving? Sign up for my newsletter!

Join now and learn the things that make a good developer become great

  • The key concepts for writing code that doesn't suck
  • How to stop getting overwhelmed by huge projects or complex problems
  • What to do when you want to make your code more reliable or easier to maintain

We will never sell your information or spam you, ever.

How to reduce bugs in JavaScript code by following the rule of consistent types

August 11, 2014 – 6:22 pm Tags:

One of the most annoying type of bug in JavaScript code is when the code doesn’t have logical types. Oh hey, I’ll just sum these two numbers… NOPE! They’re actually strings! That just makes me so angry. To make matters worse, this is something I’ve had to deal with a lot with a codebase I’ve been working with recently.

JavaScript is dynamically typed, and it doesn’t care what you do with its variables. You can have a variable contain a boolean, then put an array into it… then put a number into it… but this does not mean you should.

Your values should have one type only

Sometimes you see code like this

function getNames(person) {
  if(person.firstName == '') {
    return false;
  }
 
  return [person.firstName, person.lastName];
}

At a glance, it doesn’t look like there’s anything wrong with it. However, it breaks a very important rule you should follow to keep typing-related bugs away from your code.

In a language with static typing, the above would not work. The problem is that the function has inconsistent return types. What this means is the function can return both a bool value, and an array value. That kind of thing would never fly in a statically typed language, and there’s a very good reason why you should never do this in a dynamically typed language either.

Inconsistent types will give you a headache

When a function returns different types, you can’t make any kind of assumptions about its output. As a result, it will cause a mess, both in code and possibly in bugs as well.

Let’s say you take the above function and want to combine the names…

var result = getNames(person);
var combined = result.join(' ');

Now what will happen when the function takes the first path and returns a bool? A “true” or “false” value does not have a function join in them, therefore it will cause the code to throw an error. In order to deal with the possibility of a bool instead of an array, we have to add all this useless fluff into the code

var result = getNames(person);
var combined = '';
if(typeof result != 'boolean') {
  combined = result.join(' ');
}

Now, the example above is very simple. If you have ever worked on a large JavaScript codebase that broke this rule, you already know how bad it will get in a real application.

Always be mindful of your types

In order to fix this problem, we can simply rewrite the function like so

function getNames(person) {
  if(person.firstName == '') {
    return [];
  }
 
  return [person.firstName, person.lastName];
}

By keeping the return type consistent, we reduce the likelihood of bugs being caused by incorrect types. We also reduce the amount of code that you need to write, and less code is always better than more code.

Working in dynamic languages like JavaScript gives you great freedom, but with great freedom comes great responsibility. Save yourself the headaches, and keep your types consistent!

Are you tired of having to deal with bad JS code?
Sign up for my newsletter and learn how to fix that

  • What's the best way to architect large scale JavaScript apps?
  • Automate common development tasks and save hours of your time
  • Refactoring that horrible mess into something more manageable
  • Etc.  

We will never sell your information or spam you, ever.

Hello World Open 2014 thoughts

June 19, 2014 – 2:26 pm Tags:

I participated in the coding world championships, or Hello World Open, 2014. The challenge was to write an artificial intelligence for a slot-car racing game.

I wrote my bot in Haskell, and managed to rank 11 out of 856 competitors in the first qualification round, and 78 out of 203 in the second qualification round.

Read on for some general thoughts and a bit of analysis on the algorithms my bot used.

Read the rest of this entry »

Book review: Dependency Injection with AngularJS

February 16, 2014 – 11:29 am Tags: , , ,

Are you in the market for a book on AngularJS? Here’s my review of the book Dependency Injection with AngularJS, written by Alex Knol and published by Packt Publishing.

Disclaimer: I was sent a free copy of the book for review purposes.

Read the rest of this entry »

Tips for taking screenshots with PhantomJS + CasperJS

February 5, 2014 – 7:38 pm Tags: ,

It’s quite easy to use PhantomJS to muck around with pages, especially if you use CasperJS which provides you a bit nicer API.

It’s also pretty easy to take screenshots, but there’s a few things you need to take into account if you want the results to be accurate…

Read the rest of this entry »

AngularJS best practices: Refactoring existing code to Angular

December 27, 2013 – 8:12 pm Tags: , ,

I’ve been involved in several projects where I worked on moving an existing codebase into using AngularJS. Some involved refactoring a small codebase, which is relatively straightforward in most cases, but I’ve also refactored much larger projects where moving everything at once is not an option.

Here’s some best practice type stuff that I’ve learned along the way.

Read the rest of this entry »

Using AngularJS for fast prototyping

November 5, 2013 – 6:27 pm Tags: ,

One of the big pain points in web application development used to be quickly prototyping site layouts. Now we have things like Bootstrap and other CSS frameworks, which give you a quick grid and a bunch of other reusable components.

But that does not solve the whole issue: In today’s web applications, standard page load style actions just don’t cut it anymore. You need to have all kinds of UI features, from tooltips to dynamic form validations and who knows what else.

How do you quickly build a working UI prototype for a highly dynamic web based interface? Everyone knows building DOM in JavaScript for doing that stuff is kind of a pain, even with jQuery or Mustache.

Here’s how: With AngularJS. Not only is it great for building dynamic UIs, it’s actually amazingly fast for prototyping as well!

Read the rest of this entry »

Library author: Don’t provide an exploitable interface

August 31, 2013 – 10:17 pm Tags:

SQL injection is a pretty big deal. Its cousin shell injection is also a common issue, demonstrated quite well by a recent post to the PHP reddit. Although some suspect it was a troll, I heard echos from a variety of people who had seen pretty much exactly the same vulnerability in production.

This got me thinking: People writing libraries for doing things like shell commands, SQL, etc., don’t actually have to provide an interface that can be easily mis-used. An interface like this could just as easily be based on some other data type besides a plain string, completely side stepping issues caused by concatenation.

“What on earth are you talking about?” – Let me explain…

Read the rest of this entry »

Why use user story based testing tools like Cucumber instead of other TDD/BDD tools?

July 28, 2013 – 3:11 am Tags: , ,

When you think of writing tests, usually you would write them using a tool from the xUnit family, PHPUnit, JUnit, etc., or if you like a more BDD-style approach, perhaps you would use RSpec, Jasmine, or some other tool like that.

Then there’s Cucumber. Instead of writing your tests purely in code, with Cucumber you start by writing a human-readable user story. Then, you write code to run the story and perform test(s) based on it.

This seems like extra work right? That’s what I thought at first, so I hadn’t really looked into it that much. However, it turns out there might be a bit more to it…

Read the rest of this entry »