Category: Software Engineering

One of the most influential pieces of code I’ve written (that I use myself every day) is something I’ve talked about before.  It sends me an email alert when I haven’t blogged or written code as often as I want to, and keeps sending alerts until I do the action.

When I broadened the software out to handle reading books it got me thinking about taking this public.

I started building a web service over the last couple of weeks to make this a more general productivity tool for anyone to use.  In the coming months my partner Colum and I will launch the web site, and work on a mobile app to go with it.

A well designed mobile app might be able to attract a few loyal users.

Everyone who does web development will probably find themselves doing devOps tasks at some point.  I keep an eye on servers hosting several different projects at different cloud providers and some private servers.  Until recently management of those servers wasn’t difficult enough to warrant using tools to deal with things.

Ansible is a commandline tool that allows you to manage your servers.  Lets say like me you want to introduce it into an environment with servers already in place.  Here’s how you can get started.

Install the Ansible commandline:

brew install ansible

Create a hosts file (file that lists all the servers you want to manage):

ansible_hosts:

[ec2]
ec2-.compute-1.amazonaws.com  ansible_ssh_private_key_file=/PATH/TO/key.pem  ansible_ssh_user=ec2-user
ec2-.compute-1.amazonaws.com  ansible_ssh_private_key_file=/PATH/TO/key.pem  ansible_ssh_user=ec2-user

Ping all the servers to see if they respond to ssh:

ansible ec2 -i ansible_hosts -m ping

Ansible comes with a large library of low level ‘modules’ for doing interesting things on your servers. You can call simple things right from the command line as in the previous example (uses the ping module). If you want to upgrade openssl package on all your (Ubuntu) servers:

ansible ec2 -i ansible_hosts -m apt -a "name=openssl update_cache=yes" --sudo

or upgrade all updates to a CentOS server:

ansible ec2 -i ansible_hosts -m yum -a "name=* state=latest" --sudo

There are over 200 modules built into the core of Ansible to make interacting with lots of different programs easy – git, shell commands, postgres databases, supervisorctl, django, gem packages. Doing a git checkout of your application across a pool of web servers can be done with a single command line.

If that was all you could do with Ansible I’d be happy. But that’s really just scratching the surface. Building on these low level modules is what Ansible calls ‘roles’. Roles encompass a series of commands to do a bigger task – like install and configure nginx. You can tie multiple roles together into a ‘playbook’ that can define how to build out your entire infrastructure.

In my next post I’ll cover how to go from zero to fully deployed web application with Ansible.

Expanding on the thoughts in my last blog post about measuring opposing indicators I wanted to explore things from a different perspective.

There is a growing community of people that measure and record as much as they possibly can about themselves.  This quantified Self movement is predominantly focused on health related aspects exemplified by the growing market for activity trackers like FitBit.  The more information you have to track yourself the more you are able to identify longer term trends that would otherwise be twisted by your own fallible perception.

Programmers strangely do not have much going on for measuring themselves.  Even though it would be quite easy to glean information from the coding output from any programmer.

I would be quite interested to see a collection of stats about myself.  A daily digest of basic productivity, and charts of longer term trends would be motivating and insightful.  Would lines of code per day increase as I got better at a new language/framework?  Would there be plateaus in my productivity? Could I identify the impact of distractions? How much more productive am I working from home vs. at the office?  There are so many questions that would have valuable answers for me personally in my quest to improve.

While no measurement is going to be perfect, by measuring myself against myself, for personal insight provides some incentive not to cheat and keeps the relative performance as an informative metric.

GitHub provides a decent API which could be used to dive in and gather this information.  It would be interesting to launch a service that could mine through a user’s github account to generate a detailed productivity report.

Unfortunately another project I don’t have the time to build myself.  If someone else builds it though. I would surely be a paying customer.

Programmers often take something for granted that would make them significantly better at their job.  No it’s not communication skills, or management.  The biggest differentiator between the best and average programmer is how often they have to refer to google to solve a problem.

Any programmer who knows the basics of programming in a C like language feels like they’re competent enough to write Javascript – even if they only have to program it occasionally.  What ends up happening is they stall on every other line of code to crawl stack overflow for solutions.  Despite their lack of skills they can still write complex code and get things done.

No doubt that Google and Stack Overflow are awesome resources that make it easier to write things you don’t really have the knowledge to do off the top of your head.  Each detour to the search engines eats time.  It takes 10x more time to find a good piece of code on the internet than if the programmer knows how to write it already.

The skill that most programmers overlook is memorizing the APIs and languages they use.

When you take away all the crutches we use to help write code by writing with pen and paper, without the help of reference material gaps in your knowledge become brutally apparent.  Try this from time to time.

Most programmers I know seem to think that picking up a new language or framework can be done in just a few weeks.  My experience is that unless they take deliberate time to read and learn and build expertise the typical result is getting to a passible skill level and then plateauing.

Do not underestimate the value of depth of knowledge.

Do you want to write code faster, with fewer bugs, and feel confident that what you write is good?

Over the years, programming has evolved, and many new platforms and tools have been created. Most of the tools aren’t very useful, but a few are.

Here are the 11 tools that have helped make my programming a bit easier and more successful:

Tool #1: Linting

Every language these days has a selection of Linting tools.  These are programs that parse your code to detect and flag best practices.  Linting tools enforce consistency of code style among all those in your team, can detect complexity, unused variables, naming conventions, or a long list of other infractions that help you to keep your code clean.

A side benefit from Linting tools is that they can hint at things which may just be general improvements.  Enforcing Javascript semi-colons, suggesting modernization of Ruby code or helping keep Python code PEP8 compliant can often trigger you to think twice and maybe re-factor to improve your code structure.

If you’re code environment doesn’t have linting built in, get a better development environment, or install a plugin. Linting is a great tool for improving your programming skills.

Tool #2: Dash

Google and Stack Overflow are great resources for solving quick questions you have about something you need to do but having a local copy of documentation to reference can speed you up tremendously.  Dash is a Mac App that lets you search through documentation for various languages and frameworks quickly and easily.  It copies them locally so it works when you’re offline too.

Everytime you search online for an answer to a question there are two things that can go wrong:

1. You get distracted reading articles, browsing things and loose time
2. You get the answer you want without enough knowledge to understand it, copy/paste and promptly forget how it works.

Reading real documentation often forces you to learn something new.  Well written documentation will explain things enough to give you a firmer foundation to help you remember it the next time you encounter similar questions.

Tool #3: A Solid Text Editor/IDE

I have been using Atom for the last couple months as a coding editor.  I’ve always personally felt that IDEs can often do too much which makes me uncomfortable.  Which ever side of the fence you’re on, one thing is clear.  You need to get yourself a great editor.

This is the primary tool you use when coding – don’t be afraid to spend a little bit of money to make your life better.  Take the time to truly master this tool.  Write your own plugins, customize the shortcuts, tweak the theme, read a book!

Tool #4: Vim

Yes, vim is a text editor, but regardless of your editor of choice you should also know how to use vim.  Especially if you work on servers.  Vim is installed by default on just about every Linux machine, so it’s the workhorse that is very nearly always available for you to use.

Tool #5: Git

There are many methods for managing source code versions. Git is the one you should be using.  CVS and SVN are long dead, Mercurial and Baazar lost out to git.  Even if you just are coding locally, without any other developers git is a gift that will someday save your ass.  There is really no excuse not to have your code under source control.

If you want a GUI for interacting with git – checkout SourceTree.

Tool #6: Commandline

A master of the commandline can accomplish a lot of things with relative ease.  One of the nice things about a commandline interface is that if you know how to do something on the command line (as opposed to in a GUI) you know how to automate it or turn it into a script without any additional thought.  With a GUI you know how to do something by moving and clicking the mouse – and it’s unlikely you’ll every investigate how to do that task any faster even if you have to perform it 1000 times.

Tool #7: GitHub

You’re using git right?  GitHub makes git better in several ways.  By adding Issues, Wikis, Pages, you can plan your Todos and publish your documentation.  You can easily give access to repos to new people when they join the team, or make things public so anyone can fork your project.  Use Github webhooks to plug in and automate your own workflows.

Have a public face to yourself and your company. Github is the first place I look when checking out a potential new hire.  Your github profile is the modern extension of your resume.

Tool #8: Newsletters

K, this isn’t really a tool, but I think it’s important.  Reading the various Google+ Pages, Reddit subreddits, Twitter, and blogs for the languages, tools and frameworks you use, is simply too much noise to reasonably parse.  I suggest signing up for a weekly newsletter instead.  A much more reasonable weekly digest of the most important new things will keep you up to date, without sucking up all your time.

Tool #9: Books

Books are often underrated by software developers.  Unlike blog posts which are often written quickly and published in the first draft.  Books are often written by multiple authors, reviewed by a panel of experts and edited by professionals.  These extra filters helps to lift up the quality of content in a book much higher than you find laying around on the web.

If knowledge a $20 book gives you saves you 10 minutes then it’s paid for itself.  It’s much more likely that a good book will save you days.  A great book could help you double your efficiency.

Tool #10: Continuous Integration/Unittests

I have found that different languages and tools necessitate different levels of unit testing.  Python is relatively explicit and APIs are generally consistent – python code usually behaves the way you expect it to.  Ruby syntax on the other hand is prone to ambiguity, has multiple syntaxes for the same things, is poorly documented and often implicit in how things work.  Even after over a year of full time Ruby development under my belt I trust that any untested code is broken.

Continuous Integration runs your tests after every commit, or every change you make locally.  By running tests often you can catch regressions quickly before they become an embarrassing bug.

I recommend using a web service like Travis-CI.  Setting up your own CI Server can be a bit of a pain.

Tool #11: Practice

If you hired a coach to teach you how to play tennis, you expect to run drills, learn how to grip, swing, stand and step. You’d hit thousands of balls until the mechanics of how to hold the racket, swing and step become so instinctual that they can be performed without thought.  You would practice several times per week, for 1-2 hours each time just performing basic moves.  It would be months before you actually are ready to play a game.

Nobody practices anymore.

I believe that deliberate practice is what differentiates an average developer from a 10x developer.  Practice with the languages, frameworks and libraries you use and the tools you write with.  Every API that you memorize will add up to hours of saved time searching Stack Overflow.

Conclusion

Writing code doesn’t have to be hard. There are a ton of free tools out there that can help you write better code faster.

The 11 tools I mentioned above are the main ones I use on my projects. Give them a shot. They’ll change your coding experience.

What other tools do you use when coding?

I have a long, long list of software projects that I’d like to create.  Scattered across notebooks, Google docs and text files and collected over years.

It’s unfortunate that even good ideas are worthless if you don’t have the time or capital to implement them.

There are many software platforms that offer ‘magic’ like ways to accomplish things. Ruby on Rails has a lot magic going on – pass in a string argument and it gets automatically pluralized, converted from snake case to elephant case, inferred as a class name in the global namespace, instantiated and connected to set of URL routes.  Magic code is dangerous because it’s easy to use without needing to understand how it really works, and leads to a false sense of confidence that you know what’s going on.

Imagine a professional escape artist.  He has 10 years of experience performing in front of large international audiences, then one day he watches a new magician’s escape trick.  He thinks he knows how it was done so he tries to replicate it.  He chains himself up, puts on a straight jacket, takes a deep breath and locks himself in a glass box filled with water.  Moments later he realizes his understanding of how the trick was done is incomplete… Now he’s in real trouble.

That is the danger of code that works like magic.  You think you know how something works; you gain confidence that you understand it, and then it fails to do what you expected at a critical point.

What about the beginner magician?

The beginner magician can watch a card trick performed 100 times and may not be able to figure how how it works.  If they try to perform the trick themselves it’s almost guaranteed to fail.  You can not easily learn how the magic trick is done by just by watching someone else do it.

Web frameworks can be like a bag of tricks where you get to tell the professional what trick to do.  “Make this form work with AJAX” can be like asking a magician to guess which card you’re thinking of.  You have no idea how it either of those tricks work.  However, you can become very adept at wielding your bag of tricks and never learn enough to create your own.