How People Learn Software Languages 28 March, 2014

The idea of a polyglot developer is quickly moving from a state of imagination to a state of reality. I 'm realizing that although there is immense job security for those who know what they are doing in a single language, there are several real benefits to being competent in several languages. 

Some benefits include cross pollinating patterns and faster tool creation. However, I believe the biggest benefit is removing the thought constraints a person can have when they limit themselves to only using one language most of the time.

For many languages, it's not the syntax-sugar a language can have, but their ability to answer questions like "What if I didn't have to...?" or "If I wasn't focused on this area of the problem, would I see a different solution?" 

So, how do you go about being competent in several languages? I recently surveyed a number of software developers, asking them what they prefer to do when learning a new language. This is what I heard.
  1. Always start by coding
  2. When you get stuck, follow an online tutorial
  3. For all the details, read a spec or the official book
  4. To keep it fresh in your memory, submit/merge pull requests in that language

Here are some techniques that were listed by survey responders.
  • Only use what you’re learning (immersion)
  • Start a new project
  • Understand the wrong way to use it
  • Learn it at your own pace
  • Be able to apply each thing you learn
  • Like it
  • Practice it
I wish you the best of luck on your road to polyglot serenity.

SOLID - What It Means For Your Code 14 January, 2014

The SOLID acronym is fairly well known, but the phrase it represents seems to be the only well known part of it. It's a set of letters representing techniques for creating maintainable code. What I've done here is give a brief explanation of each solid principle, followed by a short explanation of how you can apply that principle to your code.

Single Responsibility Principle - Each object should have one responsibility, the granularity of which depends on future changes. Develop with the current feature set in mind and using small objects. The first time that code changes, you'll have a better idea about what the single responsibility should be.

Open/Closed Principle - The goal is to keep the number of code changes low. Requirements will change, but the less code you change, the easier regression testing will be. If a code change requires enough testing that it bothers you, you probably need to adapt the code to be more open for extension and closed for modification. You probably can't always follow this principle, but you can segregate the "open for modification" part while trying to keep it small.

Liskov Substitution Principle - Subclasses and superclasses should be able to run interchangeably without breaking the system. Precondition and postcondition consistency across these objects is a key to avoiding bugs in substitutable types.

Interface-Segregation Principle - Code shouldn't depend on something it doesn't use. If you find you are changing or implementing unused methods, break up whatever you are inheriting or abstracting from.

Dependency Inversion Principle - When you depend on an abstract class, a change in one class has a lower chance of forcing a change in dependent class. You don't need to create an abstraction for every kind of object up front because most abstractions never get a second implementation. Often it is better to wait until the need for a second implementation arises, and then create an abstraction.