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_—_landing.pngwit.ai 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.


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 wit.ai 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 wit.ai or api.ai 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:

Tomorrow I head to Cancun for a corporate retreat and will be taking advantage of the time away from my usual evening commitments (family) to catch up on my backlog of books.

What I’m primarily interested in right now is getting a better grasp of machine learning concepts.


I’m happy that Python has really become the go to language for doing machine learning. It’s one less thing to worry about having to learn myself when trying to really get a grasp of the concepts and putting it into practice.

There seems to be a huge boom in the demand for developers with the skills to develop machine learning algorithms. The recent Google IO keynote was notable in that the CEO talked of nothing other than Machine Learning and AI being the focus for Google in the coming years. It’s expected that by 2018 demand for experts in statistics and machine learning will exceed demand by at least 140,000. As a result people with the skills will have their choice of amazing opportunities.

This book is currently on sale for just $3 and it’s a hell of a deal.  I picked this up after hearing it referenced from several different groups of people in the span of a week, enough to make me curious.

“The obstacle is the way” presents an argument that much of what prevents us from achieving our goals in life is the perspective we apply to the objective reality of any given situation.  A challenging business negotiation can be seen as a stressful make or break deal, or a chance to further refine your negotiation skills.  The reality is that if you have one business negotiation it’s likely that you’ll have more in the future, thus taking the positive perspective of the situation will position you better for the next one regardless of the outcome.

When each obstacle you encounter can be re-framed into a learning experience, then everything compounds into more and more experience and skill.

The common approach that people take to a challenge is to give in – we say it can’t be done or we get angry when we try and fail.  There may be some learned helplessness, or emotional reactions that prevent clear thinking in these situations.  But stopping to get an external view can sometimes shead a lot of light.  We find it easy to suggest fixes to other people’s problems but often have a hard time thinking objectively about our own.

The book is a quick read, and worth checking out.

At the beginning of the year I, like many other people, set some goals for the year.  I also took the step of putting a reminder in my calendar to revisit my goals list every month to assess my progress.

After a couple of cycles of that I recognized the pattern, I had inadvertently applied a piece of the agile development method to my goals.

In typical agile we set a small set of attainable near term goals and work over the course of 1-2 weeks to accomplish them.  Then at the end of that sprint we pause to assess and examine 3 questions:

  1. what went well?
  2. what didn’t go well?
  3. what can be improved for the next sprint?

Small stretches of effort separated by pauses to assess and repoint are a fantastic way to reach a goal whether it is sailing across the ocean, building a software project or losing 10lbs.

The time to revisit and refocus allows you to keep all your goals front of mind and gives you a chance to re-evaluate if they were reasonable goals at all to begin with.

One of my goals was to be able to do 50 pull-ups.  After several weeks of exercise and research on training plans I’ve come to the conclusion that 50 is just an insanely unrealistic number.  So in light of this new perspective I’m re-targetting 20 reps.

Chat is becoming the next platform. Interacting with computers through channels that you already use to talk to people (Facebook Messenger, SMS, Slack etc) in a way that feels natural is a powerful way to accomplish many things for which web pages, mobile apps, desktop applications, or commandline scripts are cumbersome.

Chat is not a panacea for all user experience problems but there are many day to day things that might be able to transition to this way of interacting with computers or new ways that as yet haven’t been able to work.

In some ways this is evidence of more encroachment of technology into taking ever more jobs from humans.

Facebook has a bot they run on Messenger (available limited to Silicon Valley area) which can answer ‘any’ question and perform any number of activities on your behalf. Right now it is operating on a hybrid model. There is an ever growing list of queries for which it can automatically handle, and anything which the AI is not yet able to handle is directed back to an actual person to do. “what is a good pizza place nearby?” can be sourced from Yelp reviews. “Can you call and reserve a table for this evening” -> maybe can’t be handled automatically and will go to an actual person to do. As development continues the features that can be handled will be incrementally expanded.

I have a service running to maintain my healthy habits. Persistence is an app that messages me to do things when it can tell that I haven’t. It’s like a dependable friend that holds me accountable to my goals. There’s no reason why all this can’t happen through a communicative medium like chat. There’s no reason why this couldn’t feel like chatting to an actual friend.

After playing with the Slack and Facebook APIs around chat, it’s proving to be both more difficult and more interesting than I imagined. Difficult because in these early days creating interfaces that process natural language and conversation threads is missing a lot of tooling. Interesting because this is all so new that you really get a chance to build something that no one has really thought of yet. This is a new platform and there is still much to learn.