Matt Warren

Author: Matt

  • Finding Appropriate Side Projects

    Time is our one major limited resource and so it’s important how we decide to use it.  One of the biggest questions we ask ourselves as developers is often what kind of cool stuff could we do on evenings and weekends.

    Here are my considerations for any side projects that I feel are worth saying ‘yes’ to.

    • It should align with your broader goals
    • It should ideally provide an incremental step towards those goals
    • It should be fun and interesting
    • It should have a number of quick wins
    • It should be something that you can’t or won’t get experience with during work hours

    One thing to consider is conflicts with your job.  It would suck to be working on a passion project at night and find the need to hide it from co-workers and your boss or risk some sort of discipline. Co-workers can be great sounding boards and strong supporters of your success with these personal projects and it’s awesome to be able to take advantage of that.

    The key to being one of those people who seems to get a lot of stuff done is to be continually walking in the same direction rather than running scattered from place to place.  It’s not as easy as it sounds.  There’s always a new hot idea to pursue or a reason to give up on the project you haven’t yet finished.  For that reason it is good to pick a project that hits as many checkboxes as possible for you and that you believe you can see through to the end.

  • Goals and Processes

    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?

  • Passion for Productivity

    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.

     

  • Summer Recap

    With summer coming to an end I thought I would recap all the things we managed to get done in our first Ontario summer.

    The general theme for the summer was HOT!  Right from the start we had one heat wave after another.  Particularly memorable was that while I was in Mexico, it was hotter in Ottawa.

    We got a couple of good camping trips in this summer and explored some of the nearby parks.  The campsites at Murphy’s Point were amazing, quiet and accessible.  Trying to scare away a bold raccoon that grabbed an apple from the chair next to me and watching the fireflies glow in the brush all around our tent was pretty cool.  We did some swimming in the pond, made sandcastles on the beaches and rented a canoe a couple times to paddle around Big Rideau.

    Perhaps the biggest personal achievement for me this summer was learning to sail a boat.  Taking the course was a reminder just how important it is to continue to step outside the ordinary routines and find new things to learn and be exposed to.  The sailing class experience resulted in a cascade of further learning and ambition.  Next year I’m going to be taking lessons for larger boats, VHF Radio certifications and probably CPR and survival skills.  Continuing to push into a wider variety of skills is something I will make part of my annual goals every year from now on.

    The road trip into southern Ontario was filled with meeting new people, seeing relatives and old friends.  It was a chance to see a region that I never got to explore during the 3 years I was in University.  We saw Niagara Falls, spent a day on Centre Island, did some wine tasting, and relaxing on the amazing beach at Sandbanks provincial park.  Overall it was a jam packed week of trying to squeeze everything in.

    Beyond the bigger trips and such we also found time on the weekend to do a lot of exploring.  We did one day in Montreal, and spent some time in places like Cornwall, Perth, Smith Falls, Brockville, Belleville, Gatineau, and Kingston as well as visiting most of the major museums and a couple of the big historical sites.

    After all this there is still so much more to explore.  We have not yet ventured too far into Quebec (mostly due to lack of confidence in speaking French – another thing to learn) and there is still lots of events that we never made it to this summer.

    I guess after living in a couple of cities across Canada the biggest lesson I have learned is to take advantage of all the experiences around you while you can.  People have a habit of not visiting the tourist attractions in their own backyard and for sure the place that I have the biggest gap in my geographic knowledge is where I grew up in Newfoundland.  It sucks to leave a place and have regrets about the things you didn’t get to see or do.

  • Web Design Fallacies and the Failure of CSS

    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.

  • Experimenting with ECommerce

    Over the last couple of weeks I have been spending some evening and weekends working on building some e-commerce websites. If I were to Define Ecommerce, I’d say that it is the most advanced platform for sales, and which has the higest percentage of reception by customers worldwide.

    Chinese ecommerce companies are now experimenting with direct selling model

    Right at the time that the iPhone 2 came out I was really into buying domain names and picked up iphone7case.com. I’ve held onto that domain for nearly 10 years and finally (fingers crossed) the time is coming to make something of that site.

    The most obvious way to provide some value with that domain name is to put a store on it that sells iPhone 7 specific cases and accessories.  So in trying to find a way to make that a reality I’m doing some web development in the evenings to build up a website and hopefully get something ready to launch before they announce the new phone in September.

    In addition to that I put up a small store on this site to experiment with.  I just put some books and products that I bought off amazon which I really liked and will continue to add links to things that I personally have bought and recommend, I’ll also make sure to add some coupon codes I’ve gotten from websites like Raise.  I’m hoping to offset a bit more of my server costs for hosting this and my other sites.  We’ll see how that goes.

  • Programming Should Be More Like Authorship than Engineering

    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?

  • Power of Iterative Progress

    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.

  • Web Scraping With Scrapy

    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.

  • Writing Bots

    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.

    Conversational_User_Experience_Platform_for_Web__Mobile_and_IoT_-_Api_ai

    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.