Category Archives: Business

I saw this said in a book I recently finished reading about company planning and strategy.  For sure when I read it first it caused me to pause.  Could there really be that much difference between good and great?

The more I thought about it, the more I came to agree that it is a pretty good estimate of the difference in costs to a business.  One great employee will do things better, with fewer errors and without the communication overhead of having to distribute the same work among three people.

In terms of salary costs that can add up very quickly.  The great employee may demand a 20-30% premium over the good employees but by needing 3 people your total costs skyrocket up 250%

It’s something to keep in mind if you ever are interviewing or hiring.  It’s usually better to wait for a truly great employee than to settle for someone that you don’t feel is going to bring a tremendous amount of value to your team.

Stack your company/team with A players and your chances of achieving your big audacious goals multiplies.  Introducing even a few even a few mediocre people can derail a project and create a stressful work environment for everyone.

Decisions can be paralyzing when you have to make them.  Even more so when you don’t have the information you need to make an informed decision.

In the day-to-day work of programming we make decisions all the time.  However the decisions we either don’t have answers for of don’t have the power to make ourselves can often block things.  These blocks can easily last hours or days if we need to co-ordinate with other people to make the decision.

Part of the planning stage of a project is to make as many of the decisions up-front before development starts so that the process of writing software doesn’t get blocked waiting for or discussing what to do next.  In an ideal case decisions would be always ahead of the developer needing to work on implementing them.

The output of the planning should be essentially a to do list that can be worked on quickly with enough information so that no further clarification is needed.  This is essentially the key that Kanban – writing tasks down on cards forces you to think through and make decisions so that the coding tasks are directly actionable.

When done right, programming can be extremely productive.  Having a work queue to pull from is a popular design pattern for implementing applications and it works similarly with scheduling programmers work.  When the producers (decision makers) ensure the work queue is full, the readers (programmers) won’t be blocked waiting for work to do.

This is commonly implemented with a Todo list, bug tracking software or Kanban style tools.

Whether it is a small one-person project or it belongs to a large team you should strive to keep everyone engaged by ensuring decisions are made before programmers need to implement them.

Why would anyone ever suggest that it’s better to focus on quantity over quality?  Clearly pushing out a pile of sub-par work is not a good idea when you could take your time to think though things and produce a master piece the first time.

The fact is that you can’t easily produce top quality work without the experience you gain from doing something many times over.  Each iteration is a chance to learn from your mistakes and iterate on better approaches.  You can’t gain this experience without sometime dedicated to producing a quantity of work.

Malcolm Gladwell might consider this to be part of the 10,000 hours it takes to really master something.  A Aikido dojo might just consider it practice, and a student would consider it to be homework.  This is what it takes to get really good at something.

When you learn your multiplication tables you take the time to go over them again and again until your recall speed is high.  If you got to the test and had to multiply every 1-digit number by counting on your hands you would never finish the test before the time was up.  Getting good at anything takes sheer quantity to train your brain to be quicker.

As adults we tend to stop focusing on this as a way to learn new things.  We’ll just wing it and let our previous 30 years of life experience just coast us through a new task.

Even by the time you get to University the amount of practice you are expected to do is greatly reduced.  Professors will walk through one sample problem in the classroom and give one assignment question for each broad topic.  It’s hardly enough time to grasp some concepts, and certainly not enough practice to burn that knowledge deep into your cerebellum.

A journey to undertake a significant amount of practice like this takes small steps of progress every day.  By adding to your daily habits with the action of doing something to add a bit more practice can make a massive difference over the course of a few months or years.

I have personally challenged myself to write some Python code every day.  After a streak of 150+ days in a row now this is very clearly paying off.  The more I do, the deeper into the language nuances I get and my speed and recall has gotten better.  It means I’m more confident in the code I write every day and I can leverage the language in ways that make the programs I write better.

The focus is on the process of doing these things in volume, with a eye towards getting better each time.

Daily habits like these have a massive effect on you over time.  It’s like compound interest.  After a certain amount of practice you will be better than 99.9% people and at that point you are at the high end of a long tail distribution and get to enjoy the benefits of being among the best in the world at something.

Being action oriented is one of the biggest differentiators I have noticed in the most productive people.  It’s amazing what you can get done in a day when you just take action to make it happen.  Even a small step can get the ball moving on a large project.

One of my partners is the most action oriented person I have ever met.  No time is ever wasted with idleness.  A car ride is a chance for brainstorming.  Every phone call is a chance to network, spread ideas and get commitment from others to meet deadlines.  It is no surprise that he has started many successful businesses and has an impressive network of connections.

It can be quite amazing what can be accomplished when you really take action and get some momentum on a project. or tasks.

Most of the time I find myself in these situations when I decide that no matter what “this is getting done today!”  Then it doesn’t matter what it is that needs to be done: clean the house, write code, write blog posts, run errands, fill out paperwork.

Taking action can also take another form.  It is a great immediate response to anything that you want to accomplish or take advantage of, but don’t yet know how.

For example. the Japanese economy is under massive strain. Debt to GDP is at unheard of levels which seem unsustainable and are at risk of a major correction ( think Iceland or Greece x 100 ).  Knowing this you might want to ask yourself what actionable steps you could take to profit off of a default on Japanese debts.

This frame of thought, to always think about what you can do is a key differentiator with the most accomplished people I know.

For a decade I have pushed back on switching to an IDE for coding Python.  My preference has always been to use the minimal editor possible to help force a level of consciousness in my code and avoid the complacency that can come from having tools that are just too powerful.  Auto-complete is awesome, but if you lean on it too much it can prevent you from actually caring enough to retain information.

When the answer to a question is easy to find – your brain opts to avoid the effort required to push that knowledge into longterm memories in favour of just asking the question again.  Why bother remembering APIs when the IDE will just finish the typing for you.

Perhaps some of my distaste for IDEs came from having to use Eclipse to write Java.  A slow clunky editor that even after years of programming left me feeling inadequate at writing Java code.  It pushed me back to Vim for a long time in an effort to actually feel attached to my craft again.

Over the last couple weeks I have been exploring using PyCharm to write python code.  This was driven by being required to dig into some incredibly convoluted code written by other developers where a simple text editor just didn’t provide enough help with understanding how things worked together.

This experience has opened my eyes.  A good IDE really can connect a lot of dots.  I still think there is incredible value in learning a language, frameworks, and libraries as well as possible by actually typing them out in a dumb editor.  It takes a while to develop the knowledge to really be considered an expert.

Once you have the expertise an IDE can provide a lot of leverage.  I will probably never give up the simple text editor (vim is always a requirement for remote development) but will continue to lean on PyCharm for when development speed is critical.  Especially with a dynamic language like Python the insight from an IDE can sometimes be a lifesaver.

The morning is probably the best time of day to get things done for yourself before work and stress start to derail your day.  When you’re trying to accomplish something big finding a way to take advantage of these early morning hours can really ramp up your productivity.

The quiet morning hours can be your time to focus on what really matters most for your long terms goals.

What nearly always seems to happen is that at the end of a long day you are too exhausted to go to the gym, your too stressed to focus on things, or you’ve been convinced to spend an extra few hours at the office to finish up.  Your own priorities slip down the list.

A day has only 24 hours and every bit of time you give to something else is time you can’t take back later to do things for yourself.  If you want to make sure your goals get hit you need to block out time for yourself.

In financial planning one of the biggest tips is to always pay yourself first.  When you leave yourself whatever is left over after paying bills, and other expenses there is almost always less than you need to save if you want to become wealthy or retire.  Paying yourself first helps you reach these long term goals.

The same applies to time.  If you want to build wealth out of time rather than money you should use time for yourself first before you give it to other’s.

Creating a morning routine, and making it stick has in my case been successful when I’m truly excited to get out of the bed in the morning, I have everything ready to go, and no excuses preventing me from getting up.

One of the best things you can do is to prepare the night before for the morning.  Have your work ready, water ready to drink, clothing taken out and coffee maker scheduled.  The easier and quicker it is to get from bed to fed and getting things done the more likely you are to do it.

Here’s what you need to do:

  1. Figure out what you what to accomplish in the morning.
  2. Get everything ready, so you can do that as soon as you get up
  3. Iterate.  Find ways to make getting up easier, until it is easy

The theory for motivation has been best described by Maslow’s hierarchy of needs. Peak motivation can be achieved when you become self-actualized – internally self motivated, however to get there you need to fulfil your lower level needs first.

Maslows Hierarchy Of Needs
Maslows Hierarchy Of Needs

At each level of this pyramid you will find factors that might be motivating you.  Working up from the base starts with the physical needs – food, housing etc that we need.  If you don’t have these needs met then you would be strongly motivated to satiate them.  Note however, that they are not good motivators to achieve great things in life.  You will never compose an orchestral masterpiece if you can’t afford food and are living on the street.

The next level is Safety, which includes job safety and personal safety.  When you live in fear of not knowing how long you’ll be employed or if the city you live in is safe enough then you will be motivated to mitigate that risk.

Love and Belonging.  Humans have emotional needs to have friends, and family connections that are strong.  Building and maintaining these personal connections can be a strong motivator.

The need for self-esteem and self-respect is important.  People with low self-esteem may be motivated to impress others in order to gain respect.  However, your perception of how others perceive you is not always accurate, and the drive to impress is not an effective way to fulfill this need.  Self-respect comes from within.

At the top of the pyramid is self-actualization.  This is the need to reach your personal full potential. The more time and focus you have to devote to this need the more you are likely to achieve in life.  Someone who is fully self-actualized has all their lower needs met, and can devote all their efforts at pushing their own potential.

Knowing where your needs are is the key to identifying you motivations.

Over the last couple weeks I have been getting acquainted with using Ansible to provision and deploy servers. One nice thing with using Ansible over a tool like fabric for deployment is that everything from provisioning, initializing, updating, management, and application deployment can be done with a minimal amount of code.

There are tips I learned as I got started with Ansible:

  1. install ansible with pip into a virtualenv.  This seemed to fix issues I ran into when having it installed globally on my computer.
  2. create a new directory to work with – it will have all the templates for nginx, supervisord, roles, playbooks, and server lists in it
  3. create an inventory file that lists all the servers you will manage
  4. split things into multiple playbooks – I have a webserver, database server and deploy playbook. having the deploy playbook separate keeps it simple and it will run quickly.
  5. the roles found on ansible-galaxy are almost never exactly what you want, even if they are you’ll likely have to read through the templates to find out what variables can be used to customize them.  In almost all cases it’s good to clone the role into your working directory’s roles subfolder so they are easily accessible and editable.
  6. the idempotent property of ansible playbooks make it easy to procedurally build up your playbook.
  7. it’s often easier to have an open ssh connection to manually see what’s changing on the server, make sure templates are rendering correctly etc.

my working directory looks like this for a simple single server Flask webapp.


For my deploy playbook things couldn’t be simplier:

- hosts: webservers
    app_name: awesomeapp
    repo_remote: origin
    repo_version: master
    webapps_dir: /srv/webapps
    virtualenv_root: /srv/webapps/pyenv/versions/latest_v3
    - name: git pull project
      git: repo={{repo_url}} dest={{webapps_dir}}/{{app_name}} version=master
        - restart app
    - pip: requirements={{webapps_dir}}/{{app_name}}/requirements.txt virtualenv=latest_v3 executable={{virtualenv_root}}/bin/pip3
    - shell: "{{virtualenv_root}}/bin/python3 deploy"
        chdir: "{{webapps_dir}}/{{app_name}}"
    - name: restart app
      supervisorctl: name={{app_name}} state=restarted

the tasks are very easy to follow, git pull the latest changes, install requirements that might have changed, run the ‘deploy’ command on the app which does DB migrations, and finally kick supervisord to restart the app.

On the command-line my process for executing this deploy looks like:

ansible-playbook deploy.yml -i ansible_hosts

Ansible is a tool for power users. It would be quite difficult to use without experience setting up the servers manually. Unlike Heroku or another PaaS, it will take several hours to learn and configure your first server through Ansible. However that onetime cost should pay for itself with the additional control you have, and server cost savings.

I certainly would love to see tools created to analyze your project and create a set of playbooks and templates which would create a production quality server setup, similar to how Heroku’s Buildpacks can figure out how to get a Django/Rails/Node.js app running.

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.

All software developers know that measuring a developer’s productivity by counting lines of code written is not an effective way to measure their output.  The correlation between the technical difficulty of a problem and the number of lines of code is not always 1:1.  Which means that one developer can write 10 lines in a day and be very accomplished, while another could copy/paste a solution of 1000+ lines in a day which was trivial.

On the factory floor managers always should be measuring opposing indicators.  If you’re measuring the volume of output – you also need to measure the quality of output in order to prevent creating an unbounded method for taking advantage.

For example.  If a manager of Intel processor factory production line focused solely on the number of chips produced each day, and cancelled all quality control checks then production output would likely skyrocket.  In short order, however, the defects would be found by customers, the business would suffer.  On the other extreme, if the manager focused solely on quality and checked every aspect of each chip produced then costs would skyrocket and output would crash.

The problem with measuring a software developer by the number of lines of code they produce is that there isn’t an opposing measurement of the quality/difficulty of those lines.  Gauging the quality or difficulty of the produced code would likely require peer review, and for that peer to grade the code.  Nobody wants to be the ass that gives their co-workers D- grades on their code so it becomes difficult to get honest scores.

In my opinion, counting anything is better than counting nothing.  If Bill suddenly goes from committing 100+ lines of code per day down to 10 lines per day it may indicate something that a manager should investigate.  If you weren’t measuring output then it would be impossible to know about or fix anything that Bill was having trouble.

Authors measure themselves by pages written per day.  Writing 10 pages of crap is better than ending the day without having written anything. At least once things are on paper they can be communicated and others can help edit things to find the gems inside.