Matt Warren

Author: Matt

  • Free Coding Caused an Avalanche

    It’s about a month since I started doing some free coding everyday as part of an evening ritual. The idea was to spend a minimum of 10 minutes writing any bit of silly code I could think of. It could be completely meaningless random bits of syntax or it could be a useful script. And after it was done I’d commit the file up to github. I even had a little script that would check github every hour after 6pm and nag me if I hadn’t committed any code yet for the day.

    Free coding started out as a bit of a struggle. Trying to think of something to code everyday can be difficult but eventually I started on some multi-day ideas. I wrote a piece of code to pull down daily stock prices for 3000 stocks in the NASDAQ one night and the next night I computed which stocks had the best one week returns for each week of 2011. (FYI: if you had bought on monday, sold on fridays and held the top 3 performing stocks each week in 2011 you would end the year with a return of 1100%)

    It got me thinking about a bigger project idea for a stock market analysis algorithm. So I wrote down some notes about it.

    Then I free-coded a couple of nights on a project template engine where you can have a template in github in which files can be written with moustache templates and the script will download it, ask you a bunch of questions required by the templates then render out the full directory structure given your answers. I spent a couple hours contributing back to an open source project as part of this effort.

    After that I got inspired by something at work where we wanted to answer a question like “which projects do we have that use service X?” So I wrote and open-sourced a library that can parse Ruby Gemfiles. It’s published on PyPI – first python package I’ve put up there.

    For the past week I have started to work on a project estimation web app. It’s still very rudimentary but when it’s finished I think it’ll be genuinely ground breaking.

    Over the course of one month I have gone from having trouble thinking of things to code, to having an abundance of great ideas I’m excited about working on.

  • How to Create a Billion $ Company in 8 Months

    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!

  • Learning about Artificial Intelligence

    There has been a real break through in AI technology over the past year with the work that Google is doing on the Google Brain project. Details are scarce at the moment but it seems like they’ve taken neural network concepts and dramatically improved their performance.  From what I can glean, Google is using this internally, and exposing some of it through services like voice recognition.

    For the last few weeks I have been reading a futurist book about the development of super intelligence.

    It’s a very big book that goes into detail on many different scenarios for how the development of a super human intelligent computer program might happen and what the results would be.

    The most likely case (in my mind) is that at some point in the future a program will be written that has comparable intellect to a human and is able to program itself or evolve itself to become even smarter. When that event happens there will be a series of tipping points. At some point the program will surpass it’s human creators ability to understand and program it (much like we don’t understand how the human brain generates intelligence). Then it will surpass the intelligence of the smartest people, then better than the best team of people.

    We are wholly unprepared to deal with an intelligence such as this.

    This transition could actually happen very quickly (days). If it does happen quickly then the likely outcome is that AI will exist as a singleton and it will spread across the planet to grow and become even more powerful.

    The dawn of a strong AI will mark the biggest single turning point in human history since the development of agriculture.

  • Three Ways to Become a Better Programmer

    Programming is a great mix of both the creative and technical skills. Problem solving on a daily basis makes it one of the best jobs imaginable. Staying ahead of the technology curve and continuing to get better at your core skill is what differentiates an average programmer from the superb.

    The three most effective ways I have found to get better at programming is

    Read Books

    The quality of a curated, professionally edited book written by a talented author is hands down the quickest way to learn something new. If you want to pick up a new language, framework or learn new concepts reading at least one book is a good start. I am always reading at least one technical book.

    Practice Programming

    I write code at a full-time job for 40 hours / week. That isn’t practice and professional experience doesn’t provide many opportunities to actually get better. Deliberate practice for software coding can come in many forms. Learning a new language? Try solving the Rosetta Code problems. I believe some of the Basic Computer Science algorithms should be committed to memory – for example – being able to code merge sort quickly because you ‘know’ it rather than having to figure it out.  Practice writing Software Design Patterns and code idioms until they become second nature and intuitive.

    Peer Review

    Often you don’t know what you don’t know.  In these cases having someone else review your code can really open your eyes. However, in a work environment peer review often turns into a cursory sanity check, or after a while you have managed to learn all you can from the colleagues who typically review your work.  Venture into the world of open-source by making pull-requests.  This will introduce you to a wider community of developers where you have the chance to learn some new perspectives.

  • Contributing to More Open Source

    This week I expanded my daily Free Coding time to include some contributions to open source projects.  It just scratches an itch to continue my learning and reach out to find other skilled developers to help drive some additional expertise.

    One of my free coding scripts was to develop an interactive file template engine, that drove me to add features to a library I was using.

    Free coding may have been one of the most effective things that I’ve done yet to help keep me learning new stuff.  The 8 hours a day of coding at work actually doesn’t provide much time to explore new techniques or technologies.

    One surprising thing about open source is just how high the bar is on contributed code.  Rather than just being thankful for anyone to contribute any code to an open-source project, in the couple cases I have contributed to existing projects the back and forth on code review has been educational and intense. It results in some of the most eloquent code I’ve worked on.

    Looking forward to doing more in the future.

  • Move Fast, Break Things and Collect Data

    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.

     

  • Finding Opportunities to Open Source

    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.

  • Getting my Git On

    mfwarren__Matt_Warren_For the past week I have been trying to be more active on GitHub.  I’m writing code every single day in an effort to boost my presence and learn a few new things.

    GitHub has created a social network around writing software which serves as a productive (and necessary) tool and also as a portfolio of work.  Showcasing your work on github is perhaps one of the best ways to show a potential employer the quality of your code.

    As a professional software developer having more code on Github seems like a necessity these days.  However the real reason I am writing and sharing more code is that I want to get better at it, and I want to explore this new concept I’m developing called Free Coding.

    Free Coding is based on a similar practice used by authors to warm up before writing real stuff for the day.  The idea is to write as quickly as possible off the top of your head for 10-20 minutes.  It is meant to get the juices flowing – to wake up your creative mind and connect that through your hands and onto paper. The expected outcome is that authors will more reliably reach a productive flow state when they transition to real writing.

    I’m testing to see if a similar technique will work for software development.  And to keep the whole process open I’m committing my daily free coding sessions to my GitHub account.

    After the first week of doing it I think it is already improving my code although I don’t yet have a way to measure the improvement. It has turned into a chance for me to play with aspects of Python that I’m not all that familiar with, and to write some simple fun scripts.  It has already inspired me to write more code than I otherwise would have as the 15 minute free coding session has extended several hours longer on more than one occasion in the last week.

    If my anecdotal experience continues to be positive I may try to spread the word and get more developers Free Coding.

  • 5 Reasons You Should be Free Coding

    Free coding is the practice of writing code quickly off the top of your head.  It should be done as part of a daily ritual for at least 10 uninterrupted minutes.  The goal isn’t necessarily to produce something useful or even complete.  You should strive to open the taps of originating thoughts in your head and pouring them quickly into a text editor.

    Here are five reasons you should be free coding:

    (more…)

  • Building Things Quickly

    Developer productivity is a  perpetual area of improvement. Finding better tools, new abstractions, learning shortcut keys and using modern project planning is a way to continually get better at your job.  The goal of doing all that is to produce better software faster.

    Choosing the right tool for the job plays a big part.

    Lets say you wanted to get a web app up and running that provides a login, admin area, user accounts and authenticated REST API around some simple business form data that’s submitted by a Mobile App.  Writing that in C++ might take weeks, writing it in Go would take days and writing in Python/Django might take hours.

    When deciding how to roll this service out onto some servers.  purchasing, receiving and building physical hardware could take weeks, manually building the machines on AWS could take a couple days, and deploying to a PaaS like Heroku or ElasticBeanstalk might take minutes.

    There are orders of magnitude in reduction of effort required to build things when you choose the appropriate solutions.

    As a developer who writes software there are several things that are easy wins for writing more code in less time:

    • Typing speed. Learning to type faster is a basic skill, expanding on that with shortcuts is awesome
    • Knowing the language and APIs.  Every time you have to Google for API references it slows you down by 10x and gives you a chance to get distracted.
    • Knowing how to do things. At a higher level than code syntax, knowing how to structure solutions, and having a good sense of what the software is supposed to do and how you are going to do it.
    • Isolation. Distractions will derail you – people, noise, tv, all get in the way of being able to focus on the problems at hand.
    • Preventing blocks. Running out of battery, losing internet, no credit card, don’t have the credentials? Getting blocked can stop you from working entirely.

    The best developers really can be operating at 10x the performance of the average developer.

    Getting things built quickly is not only impressive, but it is a major competitive advantage.  Getting your products to market faster and iterating on them faster is a big win for everyone.