Pushing the boundaries of the webbernets.

Learn by Listening

Pull a rabbit out of your hat

One my close friends made the comment “You’re usually able to pull rabbits out of your hat”, after I just offered a solution to a problem he has been trying to solve. The reason I am able do this really has very little to do with magic. I just know a solution exists, or there is a library to help get the job done. That sounds magical, but really in truth its just because I exposed myself to the concept, library, or technique.

Simply being exposed to a concept can be nearly as powerful as learning the concept in great detail. Listening to Podcasts you get exposed to many skills you may not have otherwise picked up.

You are the sum of the 5 people you hang out with most often

We tend to emulate the people we like most, its called “mirroring”,· this is why husbands and wives tend to look like each other. It’s not because they actually have similar genetics, its because overtime they tend to make the same facial expressions and mirror each other.

I learned of this powerful psychological concept years ago, and I since then I make an effort to surround myself with people I know will be a good influence on me. It turns out your mother was right! You shouldn’t hang around with people you wouldn’t want to be like.

We mirror people mentally, this is why a son will·almost inevitably say something his father would have said. We are the product of the people·we surround ourselves with. This is just a fact of how we work in social settings. We can’t alwayssurround ourselves with the most brilliant scientists or the best programmers in the world, but we can do the next best thing. We can listen to podcasts where they talk about their ideas and have conversations about programming topics. While this is not as good as talking directly to them, many of the benefits will show up. You will gain insight into their thought patterns and potentially pick up some of these patterns. You will be introduced to new ideas and be forced to question your current positions.

This might seem a bit far fetched and that this cannot come from just listening to podcasts, but in these effects are more subtle than you realize. You may never have noticed that you can your friend both seem to take a sip of coffee at the same time. Perhaps you thought it was coincidence that you both had the idea to go to Starbucks. Somehow you seem to be in sync with your best friends. Much of the time I listen to podcasts and I find myself being able to call on concepts, news, phases, or techniques I have heard them talk about on the shows. The psychological effects of mirroring are extremely powerful and can be used to your benefit.

here are some of my favorite podcasts:

Ruby Rogues
Javascript Jabber
Ruby on Rails Podcast
Ruby 5 - Ruby News
5 Minutes of Javascript
Codenewbie Podcast
Ruby Steps Podcast

Don’t Comment Your Code - Rewrite It

Commenting is a topic I have have changed my mind about as I have matured as a software engineer. When I first started out I thought you should comment in every single nook and cranny of your code. These days I have swung the other way and for a good reason. I believe comments are a code smell and should be used sparingly. When I first started out I thought that comments would help me as a beginner to learn the code and get up to speed. I wanted comments because they were plain english road map to the pure greek I was trying to read. As I matured I realized it was just poorly written code that was really my pain point. Slogging through hundreds of lines in a single function, or variables named “x”, “y”, or ‘i’, those were my true pain points that made the code hard to read and hard to wrap your head around.

When should you comment?

In general I don’t say never, because in computer science we so rarely deal with absolutes only trade offs. So I think using a comment is a definitive trade off situation. You need to be sure of the reason you are using it. I use them like they are warning signs warning the programmer of some dangerous craggy part of the code that is not obvious right off the bat what it’s doing. Couldn’t that be said of any code that is significantly complex, and highly coupled? Yes, it can! So I use comments frequently in legacy code that is not actively being developed. Since the business concerns do not always allow me to refactor the code as I would like to, and sometimes its just better not to shave that yak. So in those instances I use comments. I consider that a necessary evil.

Why are comments such an evil thing?

The short answer is they often lie to us. They tell you what the code is doing and can often be stagnate by several generation of that code. For instances if I said a function returns a string and it gets changed to returning an integer, because thats what it should do in the first place, and a developer makes the quick fix forgets to update the comment, and they usually do. Then we end up with a situation where the comment is saying it should do one thing and the code tells you it does another.

We know the truth to be the code. Since that’s usually what is in production and is working at the time, or has been working for some time. So why read a comment that could potentially lie to you and waste you time when you could just read the code and see what its doing for yourself.

“Code never lies, comments sometimes do.” - Ron Jeffries

How do we avoid comments?

On projects that are actively developed, I try to write my code in a way that is expressive of what it’s trying to do. It’s probably where I spend a majority of my time. I agonize over the choices and trade offs of names. I usually will just pick a name I think works for what the function or class does at the time and revise it later if I need to.

class Dog
  def bark
      puts "woof"

The above code is an example of very expressive code. Even a small child would be able to understand what a dog is and that it has the ability to bark. In most cases the above code sample is far more simple than the code you will be writing but the principal holds true. Try to name things like you would need to explain it to a small child later. In this instance we can describe it like this “The dog can bark”. It could just as easily be “the user can login”, or “the user can edit their profile”.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” – Martin Golding

I always thought the above quote was pretty funny, yet it really spoke to the pain I had experienced when slogging through hundreds of lines of terrible code. I really wanted to punch the author for making the job of maintenance so painful. A simple modification which should take 20 minutes in well factored code might take 4 hours in a steaming pile of legacy code.

Put thought into the names your give variables, functions and classes

During development it’s not uncommon the first name I pick for a function or variable, will change several times during the course of project. Especially if the development cycle last more than one day. Once I have time to think on the choices and think up better choices for name, I will go back and revise the original code. Anytime I feel like a comment might be nice here. I take a step back and look at the code and even consult with a peer to see if it makes sense. Sometimes the answer is yes, but in general unless you are doing something very peculiar with the code, you shouldn’t need a comment.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ” - Martin Fowler

I take the above quote to heart, Mr. Fowler has encapsulated the reason for avoiding comments. Your code should be so readable that any human could understand it, and comments are in line documentation screaming out that a human cannot understand this with out documentation to go with it. This is why I avoid comments, and you should too! We comments are a crutch allowing us to accept bad code as long as it has a paragraph or a sentence to explain it.

Next time you write some code try to do it with out comments, look at your code and see how easy it reads. If it doesn’t read easily and you cannot understand what you wrote with out a comment, don’t comment your code rewrite it.

Making Time to Learn

Making time to learn is one of the most important things we can do as software engineers. It can be a daunting task, especially with family, friends, TV, books (reading for pleasure), and any number of one hundred other things we could be doing with time not spent at work. So in this onslaught of daily life, how do we make time to learn something new and hone our craft?

Make time where ever possible

The simplest answer is we fit it in where ever possible. There are plenty of opportunities to waiting for you to take advantage of them. You just may not have noticed that they were there, or you have it filled with another activity so it seems that you can’t possibly fit it in.

Let’s take something like your morning commute, most of us have a day job and need to drive to work or commute in some fashion. Usually this time is spent reading a novel (if you commute by mode other than a car), or listening to music for around 20-30 minutes each way. This is 40 minutes to 1 full hour of time that could be spent learning a new concepts or exposing yourself to new ideas in your craft. Fill your morning commutes with podcasts. You can easily burn through one hour long podcast nearly each day. For me this practice, then spilled over into anytime I was driving somewhere I would catch 15-20 minutes of a podcast. This time all adds up and can really boost you knowledge of high level concepts like service oriented architecture, good object oriented principals. I did this for around 1 year straight and nearly every time I discuss a new project at work I can pull some helpful nugget from a podcast listened to on the way to and from work. Just getting exposed to advanced concepts can be a huge win for you and your career.

Next, get and e-reader or a smart phone and load it with books on subjects that interest you. Try to keep it loaded with several books on varying subjects that you want to read. Avoid loading too many distracting novels that you’d rather read. While these can be nice to read from time to time, keep distractions to a minimum. Keeping books at hand for quick access comes in handy when you have idle time between tasks or when you are out and about in the world. It’s become common place to see people browser facebook while their wife or husband tries on clothes and a store, or perhaps when your favorite TV show goes on its umpteenth commercial break for 5 minutes. I usually try to fill these kinds of gaps, with some light reading. Simply open your e-reader app instead of looking at all the cute cat pictures your friends are posting to their facebook wall.

Focus on a goal

Bruce Lee, one of the greatest martial artist of all time, was famous for his insane physical shape, his speed, and strength. He would routinely workout for 8 hours or more a day. This is the price you pay to keep that physique. Bruce, would consistently work in more exercise into his daily activities. If he needed to the go to the store he would drive close to the store, then park far enough away to get a good walk in, or even a run. He would flex and hold isometric positions while just standing. He would be actively working out even while holding a conversation. This attention and laser focus on working out kept him in peak condition and earned him the respect as a formidable fighter, capable of feats of strength.

What Bruce Lee’s insane workout regimen shows us is that in order to be world class you need to work and push yourself to be world class. This is why squeezing in those extra minutes per day can boost you to levels you didn’t think were possible. We can all strive to develop software with Bruce Lee like passion.

Isn’t it important to relax? Yes, absolutely this is key, you want to make sure you prevent burn out, but relaxation is an activity like anything else and you can schedule it in. The amount of time for relaxation varies per person, so you will need to find something that works for you. Some people are ok with one day a week dedicated to relaxing, others need significantly more. Find a balance that works for you.

Reward yourself

An effctive way of training yourself for this new behavior is using a “if this then that” reward system. Rewarding yourself for doing something that helps you career, is an effective method for ensuring you stay productive. Let’s say you’re writing a blog post, and in order to watch the new episode of Orange in the new black, or marathon the last season of Breaking Bad, you need to finish this blog post. So following the system it would be “If I finish this blog post, then I can watch my tv show”. Enforcing these rules makes you more productive and more likely to just crank it out, so you can get back to that sweet sweet endorphine rush of your favorite show.

So in the end the key to success with keeping yourself in peak condition and being a lean mean software cranking machine is making sure you take advantage and make the most of your time each and every day. While we may not get to Bruce Lee status, We can all strive to be the best software developer we can be.

Remember the difference between good and great is that little extra time and effort.

Basics of Git

Getting started with git can be a daunting task. It’s amazingly powerful and with that it allows you just enough rope to hang yourself if you aren’t careful. So where do you begin? You know you need to use source control because all software developers do, right? This is a misconception, most smart software developers do use source control. However, horror of horrors, some developers still don’t embrace source control. So the fact you are looking into source control puts you ahead of those that aren’t using it. At one time I too was ignorant of source control, and then I learned SVN, and quickly grew to despise SVN. I needed a better way to keep revisions of my source code. Git was the answer I needed.

So what makes git so different? Why is it better? and most importantly what is git? It’s a distributed source management tool. What does this mean and how is it distributed? Essentially git operates on the idea that there will be many copies of the repository and no one repository is the correct version. They are all correct and equal. The only unifying factor is that they share a history of snapshots in time called “commits”. This allows git to have 2 people or 100 work on the same code base. Its extremely powerful, a by product of this distribution is the ability to branch you code and start it down a different development line since the tool is built to cope with multiple versions of code existing in copies of the repository, why couldn’t you have a marker telling your repository to clone itself from a certain point in time, and track that history separately? Well you can and that essentially is git in a nutshell. The ability to branch your code and collaborate easily with other developers.

So let’s get started with git.

First I highly recommend you check out this brief tutorial. It will walk you through some of the simple features of git. Try Git

Now that we are kinda familiar with git, what is this github thing? Well github is essentially a hosted network of git repositories. We can host it on github and allow the world to copy the code as well as work on the code and then collaborate on the code. Once you know git, github isn’t too hard. Here is the normal workflow for git so work on mastering these commands.

git init

creates a repository in your current directory. Use in you project directory. This only gets used on initial creation of a repo.

Workflow Commands:

git status

check to see what is staged and ready to be commit and what has changed since last commit and can be added to staging.

git add .

Adds everything in your current directory to staging the “.” is a command line short cut for “this directory”. Think of this as telling git to prepare to save these files.

git stash

Stash your changes on your current branch and save them for later so they can be reapplied. using git apply very useful when you need to switch between branches. You can think of this as a clipboard for code that has not been committed

git checkout -b <name of branch>

This command branches the git repo and allow you to have a separate copy of your source code to work on and if you break it you can always go back to another branch that is still “good” and no hard has been done. Note: can be replaced like so git checkout -b my-feature-branch

git commit -m "some message here"

This command will commit anything you have added to your staging to the repository. Think of this as saving those files permanently.

Those are the normal workflow commands. Typically everything gets put into a new branch and you do not work on the default branch called “master”. Master is meant to be the pristine back up copy that everyone knows is the most production ready code.

Finally there are a few commands that you will need for working on github, or any other hosted service for git.

git remote -v

That command will list all of the current remote repositories you know about and can track. Typically you will just have one called “origin” this is the default one, and comes included if you cloned this repo. If you initialized the repo yourself you will need to set the origin yourself.

git remote add origin

You can see this documented on github here

git clone

Cloning a repo copies that repository to you local machine so you can work on it. Think of this command as “download source code”

git fetch

Pulls latest data from origin or any remote specified. git fetch origin. It does not pull the changes down it simply updates your repository with any branches from github so your repo contains local caches of that information.

git pull origin master

This command tells your repository to pull changes down from origin on the master branch. You can specify any remote and any branch you want.

git push origin master

This pushes your changes to a desired destination. So it will push the new commits up to your github repo.

If you want to work with a GUI instead of command line you may want to start with Source Tree it gives you a nice interface to preform most of these commands.

It may help your familiarize yourself with how git works initially, but git is first a foremost a command line tool, most of its power is on the command line interface. So I highly recommend you learn to use the command line version.

Software Craftsmanship

Software craftsmanship is a skill, and like any other skill it takes time to learn and even greater time to master. Mastering your craft is something you should strive for. It’s not something that is easy or just comes with time. You will need to actively seek to be a master of your craft.

The best developers I know actively seek to make their craft better. They look for the next thing over the horizon. Constantly pushing toward the thing that will take them to the next level of programming. This isn’t to say they have no life, or are a ninja, rock star, or any other term that has been dreamed up to identify people who eat, sleep, and breath binary. They are simply life long learners and never let their skills rest. Once you skills atrophy it’s game over in software development.

How do we become a craftsman? Simply put, the second you start writing code you are a software craftsman. You have started a journey that will take you years to complete if you choose to master this craft. We are all craftsman at our heart and so we should definitely strive to become masters.

How do we produce code that is worthy of our craft? You should always be trying to produce incrementally better software. Pushing yourself to new heights even if your chose language doesn’t embrace certain ideals you can always learn from other communities and bring it back. For instance, there isn’t as much pressure in the PHP, or ColdFusion communities to produce high quality very testable and well tested code. However, Ruby has a very large emphasis on this. Bringing those ideals back and employing them in PHP or ColdFusion development has been a huge win for me. Bringing Sandi Metz’s rules from the Ruby world to pretty much all my code. Some of it does not apply to PHP or ColdFusion, but the vast majority of those concepts can be used for any application in any language. It may have been years before I was exposed to that had I not learned Ruby.

How do we find ways to improve our craftsmanship? The best way to improve you craft is to stretch you mind and learn something outside your comfort zone. Learn a new language every year. This sounds difficult, but you don’t need to learn the language in its highest capacity, just well enough that you can build something of moderate complexity. Learning to build something small to moderate size in Haskel for instance will stretch a Ruby programmer to learn new ways of thinking about old problems and with almost certainty help you produce better Ruby code over all.

In the end we all want to write great software, and great software tends to be software that can stand the test of time. In order to withstand the test of time it needs to be flexible and easy to change and designed in a fashion that makes developer enjoy maintaining the code. Good software craftsmanship will help us do just that.