One of the most understandable agreements is that we trade our time for money.  This is the standard that most employees agree to when they take a job.  They are selling their expertise and trading their limited resource of time to the company for a salary.

There are ways to get your time back by de-coupling income from time.  What kind of things allow you to get paid without requiring time?

Products are perhaps the most obvious option.  There are products that can be created or replicated (software) that do not require incremental time to deliver to a customer.  Automated services can help customers without a human’s time involved.  Brokering deals can generate large commissions with very little time effort.

Recently I did some financial analysis of business models to see how they might work out if I decided to pivot my business efforts.  I was trying to understand the costs and risks associated with a consulting business compared to a product business or a hybrid of the two.

The resulting insight made me rethink my priorities and preconceptions.

The value created by a moderately successful business can be astonishing. A business that generates a profit of $5k/month would make $60k/year and might be able to sell for $300-$600k to be acquired.  How long would it take for a lone developer to create such a business? Working 40-60 hours/week could you create something in 3 months? 6 months? 12 months? That has potential for this kind of revenue?  If you figure it would take a year to accomplish would you be willing to use $60K of your savings to bootstrap it?

With the right product idea once launched you’d be able to scale back development work and maintain the business and the steady trickle of income it generates.  Or sell the business for the capital gains.

The consulting business on the other hand may present less risk and a shorter path to profitability, but as a single developer consulting your ability to sell the company would require you to transition to a job to maintain the cash flows.  As a consultant you remain tied to the dollars for time equation and experience has showed me that doing both consulting and products is a difficult balance.

Finding time to live, to succeed, to love, to eat, to play, to work, to read, to escape is a perpetual set of trade offs we all have to make every day of our lives.  Finding a balance between all the things we need to do and the things we want to do is not simply about deciding yes or no to a list of things.

We all have to deal with human psycological falicies that affect our decision making.  Turning down a bowl of ice cream is much more difficult than a bowl of brocolli.  This subconsciously plays into all of our momentary decisions.

At every moment of the day we have the opportunity to make an infinite set of choices for how we spend the next moment. I could continue to write the next sentence in this blog post or stand up, go to the airport, buy a one-way ticket and move to Thailand.

The choices truly are endless and yet most of us find a pattern and stick to it.  Work 9-5, eat 3 meals a day, watch TV and go to bed.  How uninspiring.

Everything with time requires a trade-off.  Most of us trade the productive hours of the day for money instead of being with our families, we trade progress on our goals for watching re-runs on TV.

Breaking out of these habitual patterns is hard.  It requires mental effort to make decisions about how to direct your life.  The people who do it are often so far ahead with their accomplishments that they truly stand out.

Of course we will never get more time.  We must do what we can with the time that is given to us.

A goal without a process to back it up is just an idea.  It is the process which actually will help you reach that goal and it’s more important to focus on developing on an actionable process than to have the best idea or goal.

A business idea is worthless unless you do something with it.  The process you come up with could be to start a business around the idea, or to licence it to someone else.

If you had a goal of running a marathon but skipped the process of signing up for a race and training for it then it’s likely that your goal would sit on your bucket list until you abandon it.

Though it’s also the case that parts of the process also entail their own sub-goals. The process of training for a marathon involves sub-goals of going out several times a week for a run. It’s worth considering what the process would be to make sure the training happens which might require carving out some time from other priorities.  If these processes don’t happen it puts the goal at risk.

Consider your own goals, do you have processes to back them up?  Are those processes actionable given your time and money contstraints?

Personal passion is an undervalued driver of productivity. Experience has taught me that when you work on something that you are passionate about it becomes easier to focus, you care more about the quality and are less distracted.

If you can find your passion, it means you will never have a job – Richard Branson

When someone is extremely passionate it becomes possible to do 60-80-100 hours a week and not feel drained of energy. It is a powerful motivator and one which many businesses could stoke.  Although getting more overtime hours out of your employees isn’t a goal we should strive for.  Passion can overcome the draw of Facebook or milling about at the water cooler.  This can produce substantial gains.

The six-hour-work day increases productivity

Sweden is proof that there is still much productivity to be gained from the hours we do put into work.  Working fewer hours per day can help many people maintain the energy they need to stay focused and committed. The math of productivity is not simply about working harder and longer.  Finding other ways to drive energy such as cultivating passion in yourself and your employees can have a similar effect.  Getting stuck in a perpetual mid-afternoon slump is something that everyone should avoid.


Having the experience now of building dozens of different web sites over the years I have come to the conclusion that there are some major flaws in how web design is done and the underlying assumptions have proved inadequate to make web design better.

The first of these is the about CSS.  The goal of CSS was to create a language that designers could use to apply their vision to a website to separate the concerns of design from the logic and structure of a website.  It was meant to be simple enough that someone without a technical background in computer science would be able to write and maintain.  Of this goal, CSS has failed miserably.  Finding a web designer who has a design background but also knows CSS is nearly impossible.  Most designers skills are based in Photoshop and Illustrator, few have any interest in writing or maintaining CSS files.  The flip side of this is that most programmers are tasked with writing in a design language when they would be much more comfortable with JavaScript and few engineers have a good eye for design.

Another web design gotcha that is easily overlooked is that the web has different constraints from paper.  A static design spec put to a snapshot pdf or image of the final design is only 2 dimensional.  Web design reality is that there is at least 3 dimensions and sometimes 4 or more to implement.  This puts the onus of implementing missing design onto the developer.  How the page should behave at widths of 300px up to 2000px? What interactions should exist? What animations are there? Responsive design cannot be done with Photoshop and so these rendered design mockups represent perhaps only half of the design.

I would like to see one of two things happen:

  1. Make changes to the CSS tools so that it can be managed in much the same way that Photoshop does.  Fulfil the promise of putting design implementation into the hands of the designers by making the tools used to craft it similar to the tools they’re already familiar with.
  2. In cases where engineers have to do the design implementations provide a method that is more familiar to them.  It should allow for unit testing, it should be designed to reduce the likelyhood of regressions as the design changes. Debuggers and linters should identify unused code.

I think what we have with CSS is a bad compromise.  It is too technical, daunting and uninteresting for most designers to want to work with it, and it’s too unstructured, untestable and imprecise for engineers to have much love for it.  As a result CSS exists in a no mans land where few people have an aptitude.

The future looks interesting though.  Will there be a next generation language after SaSS that improves things for the lives of developers, and how will the React.js approach impact the future direction of web design.

Most programmers I know come at the discipline from an engineering background and this leads to all sorts of pre-conceptions about what we do and the guarantees we offer.

Clients often believe that paying for software development is like building a bridge.  You have some meetings to decide what kind of bridge you want to build, send it to get architected and the design approved by engineers and then hand the blueprints off to a construction company to build it.  Once built you expect the construction workers to go away and the new bridge will not need to be serviced for 50 years.  This is the mental model that many people have about how software development works too.

This is partially our fault and partially a quirk of history. Computers and programming languages came out of engineering and mathematics and the early developers brought with them their background of being engineers.  Now we are deeper than ever into this mode of thinking.  Software patents are treated like inventions.  Teams of programmers try to apply engineering styled development plans to writing software, sometimes with gant charts an other times with scrum.  None of these approaches have proved ideal and as a result expectations often do not match reality.

Instead I believe that software should be thought of as being closer to writing.  If you commissioned someone to write a book about the Golden Gate Bridge you might expect them to not be experts and require some time to gather research, distil that into notes and further organise their source material before they could really even suggest a structure for the book. If the book was going to be written by multiple authors then sections of the book would be assigned to each person in a way that required little sharing of the same content.  As each section of the book is drafted you might get an early read and have plenty of edit requests to make. Entire sections may need to be re-written if you don’t like the way something is presented.  At the end the full manuscript is again reviewed and edited. Reviewers and Editors expect to find typos and awkward sentences that should be fixed.

Publishers of the book also usually have a very different pay structure than software clients.  Publishers often provide the writer with an advance to cover expenses while the book is being written and then give a royalty on sales of the book.  This seems like a fair arrangement. Up front payment allows for full-time focus without having to take a part-time job or use credit to live and the promise of royalties provides extra incentive to write the best and most successful selling book you can muster.

Software development consultants rarely put any skin in the game. Time and materials based projects encourage a consultant to go over time for more money, and fixed budgets encourage them to cut corners to save time. The lure of ongoing maintenance contracts encourages developing something that requires updates and monitoring to keep running.  Notice that there is no direct incentive for the project to be a success, and the developer needs to cover their living expenses until a delivery date is hit. The developer who wrote the software rarely gets any public credit.

I think it would be refreshing if the publisher style model was applied to software developers. An upfront advance to cover expenses, and royalties from the profits of a successful product would help put the right economic incentives in place.  Books often have an about the author blurb tucked somewhere in the first few pages; websites and applications should do this as well since it’s another incentive to build something you are proud enough to put your name on.

The business model for book publishing seems like a good fit for software to me. What do you think?

Software startups often talk about iterative improvement.  It’s a development model where by you focus on an easy to reach but minimally sustainable business model and then iteratively improve things and add features over time.

The process of getting to that first product release is perhaps the hardest thing to do.  It requires having a vision, and following through on it day after day without much validation until it’s finished enough to show and talk about it with people.  To build a team you need to convince them of the validity of your vision and get their buy-in to help you build this product.

Even with great effort it can be tempting to bulldoze something 80% complete.  There comes a time in this long slog of work that we naturally second guess the idea.  “Is it worth pursuing”, “Someone else released something similar before us”, “I think I have a better idea”.  This is a pattern I have fallen into for many of the projects I have started.

Giving up on an idea before that first launch is like a construction company building a school, getting to the point of hanging the blackboards on the walls and then deciding “Nah! We should have built a stadium! Tear it down!”

Getting something finished enough to put it on the market is just the first half of the work of making a viable business of of it.  After crossing that hurdle of getting it out there enough to attract users and customers is when you have to tackle another slew of concerns: customer relationships, sales, marketing, accounting, ROI, growth hacking.  But if you don’t make it to that point of launching something, then the rest of it will never exist and all the energy and effort you expended will have been wasted.

Iterative progress is the idea that if every day you continue to put one foot in front of the other and keep going in the same direction eventually you will have accomplished a great journey.  Even if some days you don’t want to walk, it’s just something you need to keep doing anyway.

Writing a book requires sitting down and writing hundreds of words per day, day after day, for months.  It is exhausting. It is frustrating at times. But if you give up before publishing, it’ll all be for nothing, nobody will read it.

Most, if not all, the successful people I have met have this trait. A stubborn focus forward on their vision. They can push a single idea for decades without wavering.  By shear persistence they eventually get out in front of the pack.  It’s something I hope to cultivate in my self, and hope to see more people develop.  The world needs more leaders with the strength and will to see their visions become reality.

After reading a reddit thread about interesting scripts people have written to automate things I was inspired to put together a quick web scraping script to check the sales at the LCBO and send me a message (on Telegram) if there is anything interesting.

Back in the day I would have done something like this with BeautifulSoup, but Scrapy is a full-on framework to help build these kinds of tools. It makes it easier to write a web scraping or spider script in a more normalized way and decompose the scraping into a more consise and easier to read functions.

This was also the first time I tried to integrate with Telegram as a bot to send myself messages.  Having built bots for Slack and Facebook Messenger in the past, Telegram’s integration was by far the simplest and quickest to get up and running.  A quick conversation with @BotFather and I had my bot created and a key to connect with.  Using the twx.botapi package I was sending messages in just 3 lines of code.

This past week I had a chance to work on a conversational UI.  It’s a neat way to interact with software and presents an interesting set of problems to implement.

Before even starting to build something I needed to decide on some tools to help with managing the conversations. There are a small number of libraries and services that can help with the natural language processing which would normally present a technical hurdle.

I evaluated 3 options:

Wit_— is a service owned by Facebook that provides some very impressive ways to train a language parser to categorize and extract information from sentences.  It operates as a web service that if you send it a message it will return with a confidence measure and any extracted values.  It provides a level of fuzziness in it’s matching and as a web service it allows you application to improve over time without deploying new code.

Conversational_User_Experience_Platform_for_Web__Mobile_and_IoT_-_Api_ai is a similar Saas based solution that provides a way to convert a message into a more easily actionable format.  It has slightly different semantics than in how you describe the message parsing.

RiveScript – is the option I decided to work with. It specifies what is comparable to a markdown type language for defining messages and responses. Unlike or it is more simplistic in the language parsing aspects (closer to regular expression matching).  But has the nice property that it doesn’t rely on an external service. Implementations have been written in a bunch of languages which make it easy to get started writing bots.

For those of us lucky enough to be able to attend PyCon this year in Portland it’s a chance to meet and learn a ton about what’s about going on the wide world of Python.

For everyone else all the amazing talks and tutorials from PyCon are quickly being posted to YouTube, where they can be viewed at your leisure.  The amazing volunteers at PyCon are quickly processing and uploading the videos just hours after the talks are given so it’s easy for anyone to follow along.

Check out the PyCon 2016 Youtube Channel 

I’m going to be watching all the talks that I couldn’t get to see in Portland.  There’s just so much good stuff there to learn.  Here’s some good talks to start with: