Category Archives: Business

ToolboxDo 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.


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?

Something has happened in the manufacturing world that is nearly irreparable.  As America moved production to China and downsized factories to realize the profit gains from low wage Chinese workers it also decimated an entire skill set from the national tool belt.

When a factory tools up a new line to produce a new iPhone, sneakers or toy it is the job of a skilled tool maker to decide what custom tools can be designed to make things efficiently.  These may be custom 1 of a kind drill bits, platforms, moulds, or machinery that someone with a creative and technical skill-set needs to design and create.

When America outsourced it’s factories it also lost these very valuable skills.  Now, as a result of that loss of knowledge spinning up a new factory in America is a very difficult task to accomplish.  That loss will take a long time to recover from.

In the world of software development, abstraction is often a panacea.  Abstraction has created a similar migration of technical skill sets over the last few decades.  We abstract out the complexities with layers upon layers of helpers, protocols, frameworks and libraries.  These extra abstractions can boost our productivity tremendously so long as we don’t encounter a use case that isn’t handled by our chosen abstraction technology.

The danger when you completely ignore how those abstractions work is that the skills and knowledge it took to create them die out as well.  Who are the tool makers?

I have found it incredibly useful when trying to understand a new tool to have a solid grasp of the underlying technology. Knowing how to build a HTTP service at the TCP level (and from time to time actually doing it) makes it easier to reason through issues and push the limits of a framework like Ruby on Rails.

Software developers everywhere should spend just a little more time writing the tools they need to do things quicker in the future.  It is investments in the tooling that has the chance to compound to make future work exponentially easier.

Create stand alone services that can be leveraged on multiple projects, write code generators, and libraries. Create your own frameworks.

The style of programming required for creating a great re-usable library is very different from that used when doing a business application.  Good, flexible code often relies more on using the dynamic capabilities of a language.  You’ll often find yourself needing to use meta classes, introspection and other fun constructs.  The people that know how to wield these tools are going to be better at debugging, see opportunities to improve code, and create their own tools.

My plea to software developers everywhere: create your own tools.  Know how to create the tools you use, and how to use the tools you create.

This last month or so has been a hell of a busy time for me.  Working long hours, with a 1 year old at home who needs attention while trying to squeeze in social events, exercise, sleep, reading and personal projects is a lot to juggle.

How have I managed to rock a streak of 53 consecutive days with open source github activity, learned Flask, read 3 books this month and made progress on several side projects?

The Github streak never would have happened if I didn’t have a script to email me every hour after 5pm that I don’t have activity on my account.  This simple nag makes sure I don’t go to bed and forget to write some code each day.

Thinking of things to code each day has pushed me to explore new ideas, practice concepts, study APIs and do tutorials. In retrospect it is astounding just how much interesting stuff you can get done when you do a little bit every day.

A simple nag will actually make you find the time when you don’t have it.  Several times per week I find myself up later than I would have been otherwise trying to write just a couple more lines of code.  Once you start on an idea it’s not easy to let it go unfinished; it’s hard to commit code that won’t even compile.

Activity has spiralled off from this daily coding.  A couple days of hacking on some stock market analysis algorithms got me checking Amazon for books,   which in turn got me to completely overhaul my personal finances.  On another tangent, trying to think of ideas for things lead me to a tutorial on Flask and more books on that subject.

Want to get more done?  I’ve improved on the Jerry Seinfeld Productivity Secret with a simple script to make sure I don’t destroy my streak by being absent minded.  The knock on and compounding effects from all this daily activity has been unexpected and amazing.

escape artistThere 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.

One of the unexpected benefits of free coding daily is the chance to explore solutions to problems you have to work on that day. When you write code freely without considering the use of it there is less pressure to keep a poor implementation. It’s practice that is a way to boost your understanding of the problem before writing it for real.

There are some definite benefits to writing a solution to a problem more than once.  With each iteration you get faster and produce a better solution. When you practice and try to learn from each attempt you get better.  You gain mastery.

I came across an excellent resource last week that more people should know about.

The Architecture for Open Source Applications is a series of books that examines how some of the best software ever written is designed.

Programmers rarely get the chance to study the work of others in detail.  You learn the fundamentals in school but when it comes to experience building larger applications it’s not easy to pass on that knowledge in a single semester when writing the code for a large application may take years.

The books are inspired by how architects learn by studying the designs of other buildings. If you’re tasked with designing an office tower there are no doubt countless lessons that have been learned in the past century about dimensions, materials, efficiency, best practices, capacities for everything from floor space, water pipes, air exchangers and elevators. If architects re-invented the wheel each time they took on a new project almost all buildings would be terrible.

Software developers do often start each new project as a chance to re-invent everything themselves.  Of course this is a massive risk.  Even the best developers cannot implement the optimal solution to each an every sub problem in a large application.

Studying design patterns get you part of the way there.  Actually seeing them used in different contexts will deepen your understanding of their value.

Actually studying the great open source applications will give you inspiration to lean on when solving your own application design issues.

All software developers should read these books.

Estimating the cost of developing software is difficult.  Very difficult. That’s because with each new project there are always unknowns, mis-interpretations and assumptions that are not communicated.  If the client knew exactly what they wanted then it would just be a matter of typing it up.  They hire you because they don’t know how to do it themselves.

Agile development realizes how difficult estimations are by attempting to avoid them entirely.  Instead opting to push clients to time and materials which they have a hard time fitting into a fixed annual budgets.

Creating an estimate that accounts for uncertainty while fitting in with businesses’ existing processes is non-trivial.

It all starts by taking the project scope and breaking it into smaller pieces that are easier to estimate effort on.  There are risks even at this early first step that your estimate may be off.  Even with a great deal of thought you will likely overlook things.

Agile approaches would have you break a project up into ‘stories’ and estimate on those.  I have found that stories generally have some overlap, making it difficult to understand as a line item in an estimate.  I prefer to get down to the level of code structure.

The second thing to consider in an estimate is that with every guess you make there is some understanding of uncertainty that is not often portrayed.  Creating a login page is fairly concrete, you’ve done it 50 times and are very sure how long it will take.  Creating a custom machine learning algorithm for the application may be a bit more fuzzy. Providing a measure of uncertainty to your estimate turns your fixed estimate into a range of estimates with different probabilities.

Actually, a machine learning algorithm is useful example to explain my next point.  A good ML algorithm can take time to train and tune and a bad one can be quick. You can take more or less time and still get an algorithm that works.  There is not only an uncertainty but also some elasticity since it is unlikely that an RFP (Request for Proposals) included stipulations on the accuracy of the ML feature.  Elastic features should exist as 2 options on an estimate. 1 for basic implementation and an other that provides a better implementation.  That way the advanced option can be explicitly accepted by the client.

Next thing to consider is that not everyone’s estimates are equally good.  Some people are overly optimistic others tend to assume worst case, sometimes you have better knowledge that can help cut down the estimate while another person considers things more difficult.  By collecting estimates from many people you can average out their biases and with an open dialog hopefully team members can learn from each other.

This brings up a couple of major factors that can influence a person’s estimate:

  • Anchoring bias – A person’s estimate can be influenced if they see someone else’s estimate first.  You mitigate this by having estimates done blind.
  • Optimism bias – People tend to want to impress.  It may be to stand out from the team as better, or because they haven’t thought of some of the complexity in a solution. There is a tendency to under estimate.
  • Lack of information – All estimates are made without complete knowledge.  The client likely doesn’t have all the information either.  When you don’t have all the information there is more uncertainty in an estimate.

Anchoring bias can be dealt with through procedures that make estimates independent of each other.  Games like Planning Poker have rules to prevent anchoring bias (everyone turns over their card at the same time).

Optimism bias is more difficult to account for.  Perhaps the best (though as of yet untested in software development) approach is to use reference class forecasting to provide some insight given historical realized costs on similar tasks.  If setting up a new server has for the last 20 projects taken an average of 2 days, but the team has estimated it will take 1 day then they may be some optimism bias in the estimate.

Lack of information is accounted for by adding uncertainty to the estimate.  Although we don’t always know what we don’t know so some amount of unknowns should usually be added as a buffer in the final estimate.

Using this information hopefully you can create better more realistic estimates for your clients.  If you are a client accepting bids on an RFP you should be looking for bids that detail where there is uncertainty.

If you want to get a sense of just how crazy the world of technology is for businesses that want to make money you need look no further than Slack.

For those of you unfamiliar with Slack.  They launched a product in February 2014 which is a private communication tool for business inspired by IRC. It has quickly grown to 30,000 teams using the service sending 200 million messages per month. Now, just 8 short months after launch they have raised money at a $1B valuation.

It is astounding growth and an amazing success.  How can you copy Slack’s success?

  1. Identify and launch into an under-serviced market.  Internal business communication tools really wasn’t a product category a couple years ago and companies made due with less than ideal alternatives like email and Skype.
  2. Look for big scale market opportunities.  Chat is something that could be used by millions of businesses world-wide. A billion users is entirely possible.
  3. Minimum Viable Product – most important word is “Viable”.  It’s easy to err on the side of too minimal and end up damaging your branding.  If eager early adopters look at your product and dismiss it, it will take a long time for them to come back and re-evaluate.  Slack was in development for over a year before it launched
  4. Create a low barrier to entry.  Slack’s integration features, and free trial made it easy to convince the boss and get buy in from the team.

Of course if it was easy we’d all be billionaires!  Good Luck!

With the help of unit tests, BDD, Coverage reports, Continuous Integration, and Source code control it has become easier than ever to build code that is robust against regressions while letting you branch and play with ideas quickly and without risk.  However there are times when the scale of code use in production requires a different approach to testing.

Staged rollouts through a distributed system are one way to test the waters with new code in production, but what happens when you can’t risk even 0.001% of traffic experiencing particular errors on critical pieces of code?

Tests can have the effect of making developers over-confident that their changes will not break the system.  I have seen this happen on production systems.

In the world of sales and marketing, split testing is a core concept for optimizing a sales message.  You put out multiple advertisements and measure which performs better against a set of criteria (more opt-ins, sales, links clicked etc.).  When the experiment reaches a statistical conclusion you clean out the losers and try again to beat your best performing advertisement.

I’d like to see this approach used on more than just marketing.

Split testing code would let you verify the accuracy of a new algorithm in real world usage, or measure the performance of different code paths.

People usually read about code performance benchmarks and complain that they are too simple, too specific or missing something that makes it hard to apply the conclusions of one test to another implementation. Measuring and comparing the code in your actual application scenario gives you real performance in your actual application.


open sourceThere are so many good reasons to open source code.

  • Gain contributions from the wider community
  • Contribute back for all the awesome you’ve gotten from Open Source
  • To build the status of yourself or your company
  • Attract the best programmers
  • Get public feedback on the quality of your software
  • More people will use your software
  • open source reusable components actually get reused
  • Attract clients

With those great benefits for putting more open source code out there it still seems like a hard sale. Business types don’t always see the benefit to putting time and money into creating something only to turn around and give it away. “HEY!” they say “that’s valuable intellectual property”.

As developers we know the value of producing more open source code.  It is our job to convey that message as best we can to our clients, whether they be internal or external clients.

How do you identify part of a project that is a good candidate to open source?  Here’s the best criteria:

  • It’s not unique to the core business (ie Google shouldn’t open source their search engine)
  • It should be something that has some re-useability for other people or future projects
  • Should be small and single purpose.
  • It should be easy to understand and explain
  • Ideally it should be a package (cocoapod, gem, pypi, etc), or a service

If you are given a project and asked to design it’s architecture, estimate the cost or otherwise create an implementation plan you should take a moment to consider if there is any pieces of the project that could or should be made open source.  Isolating and open sourcing should add very little relative cost (you would have had to implement the functionality anyway) and you get the benefits of publishing open source mentioned earlier.  Try to up sell your client on open sourcing parts of their project.

In many cases open sourcing a piece of a larger project may be the best business decision to make.  MBA types just won’ t have an easy time grasping that concept so it could be a hard sell, but it’s often worth pushing for.

Keep a mindful eye and suggest an open source strategy on your next project.  You, your client and the wider community all benefit when new code is open sourced.