Matt Warren

Author: Matt

  • Being A World Class Programmer

    A year ago I started on a goal to write and publish code every day to my github account.  That streak lasted for 250 days.  It was a learning experience that gave me time to broaden and deepen my knowledge of Python.  Though the actionable goal was to maintain a streak of activity, the underlying purpose was to get better at programming (both speed and quality).

    It was in many ways a success.  I learned a bit and got better.  However, as a form of practice it had limits and ultimately improvement plateaued.

    Since then I’ve been thinking off and on again about what it would take to reach the top.  Not the top 1% but the top 10 globally of Python programmers.  Even though there is no measurement of the top as there is in something like chess, it’s clear that as an intellectual endeavour some people know more and can write better code than others.

    Then I read about how Ben Franklin learned to write better.  He started by finding a source of writing he wanted to emulate – in his case Spector magazine articles.  He would read the article sentence by sentence and make notes about each intention and meaning.  After a few days when he forgot about the article he would go to his notes and try to reproduce the article from them then compare against the original and identify where his version wasn’t as good. By digging into why specific differences were better he was able to learn how to write better.  He was able to expand on this technique to improve his vocabulary and techniques for overall structure of a story.

    I have on many occasions tried to equate learning to program with authorship skills.  This is another one where I think programmers have an opportunity to learn something.

    Becoming better at something takes deliberate practice. The keys to effective practice is focus and feedback. You need to identify things that need to be improved and focus on those individually and then get immediate feedback to learn what can be done better.  You then cycle this process for hours/days/years.

    Until reading about Ben Franklin’s technique I didn’t have a good answer for how to objectively get the focus and feedback needed for practice to work.

    The current approach to learning in a professional setting is:

    • peer review
    • books/reading
    • conferences

    Peer review is great if done right.  If people use the review process as a chance to coach instead of just scanning for overlooked bugs then there is a chance things will learned, discussions will be had and the product will get better.  However this is dependent on peers that want to offer this kind of feedback and who are sufficiently advanced to point out areas for improvement.

    Books and reading can be a source of great ideas but reading ideas is not the same as originating them. People learning a spoken language experience this difference.  Exceptional amounts of time spent learning vocabulary, verb conjugations, prepositions and sentence structures can make it possible to understand something they read, while at the same time actually being able to speak a sentence is stilted and slow.  The mental processes for taking an idea and turning it into speech or code is different from reading and understanding what you read.

    Conferences are much like books except you gain a few more mental hooks to hang memories on (I remember learning about that at a conference in SF last year), and the chance to discuss things with peers.

    None of these options really provide a great way to reach the top. But Ben Franklin’s technique for practicing writing may be a hint at something that could actually people achieve elite levels (with a lot of hard work).

    It’s an idea I want to explore further in the coming months.

  • Going Mobile

    Over the last couple weeks I’ve had a growing concern that my office is just not functional any more.  A standing desk in a room pulling double duty as a spare bedroom.

    So over the last week I have pulled out all the office equipment and turned the room back into just a bedroom.  The experience made me realize just how much clutter there is everywhere and it all creates distraction.

    The white tennis shoes scenario.

    There’s a classic book for writers called “The Artists Way”.  One of the anecdotes is about a pair of white tennis shoes.  Imagine for a moment that you have an immense project in front of you – months worth of work.  And in the dead of winter with a foot of snow outside you sit at your desk staring at your computer monitor.  Then, from the corner of your eye you see your white tennis shoes tucked in the corner. There’s a little bit of mud scuffed into the toe;  you look back at your screen.

    Moments later there is a nagging feeling, you must clean those shoes.  Never mind that you won’t be able to play tennis for months.  This must be done now. “It’ll only take a few minutes” you tell yourself.

    Several hours later you’ve cleaned the whole room and accomplished none of your work goals for the day.

    A messy office is full of white tennis shoes and as a result I haven’t been getting much work done for what feels like forever.  To address this I’m taking the unusual approach of getting rid of an office entirely.  I’m focusing on getting my mobile office in better shape so I can easily re-locate to a coffee shop, the bedroom or the kitchen table to get work done.  By just moving to a place that has limited distractions I’m hoping I can stay more focused and get more done.

  • Making Longterm Plays

    In an age where we expect everything quickly it seems that it can be harder to have the patience to endure long term investments.

    People are career hopping between companies and entire job types more today than at any time in history.  Employees who want to progress up the ranks find that a quicker route is to job hop.  Ambitious employees are not content to put in 10 years at a company before getting a promotion.

    Investors also look for quick gains.  Few are willing to park their money for multiple years in order to get rewarded with modest gains. We look for the quick buck.  Day trading to make 1000’s of dollars in hours instead of months.

    This psychology has repercussions in our endeavours.  It becomes hard to focus for years on a blog to build an audience or create a piece of software in our spare time, or start a business.  These long term goals take time and time is the one thing that we too impatient to wait for.

    However, being conscious of this is the first step to being empowered enough to account for our natural tendencies and make long term decisions that are in our best interest.

     

  • Overbuilding From the Start

    A project I have been working on for the past couple of months has suffered from a critical planning error that early on has resulted in time and budget overruns as well as a product that has performance and stability issues.  It’s all because the decision makers at the top decided to take on risky technology and design choices anticipating scalability problems before they even have scale.

    One thing that I have learned over the years is that you can go a long way on the basics.  MySQL or PostgreSQL will scale very well for almost all use cases you are likely to be developing for.  In very few cases is the horizontal scalability of NoSQL options worth the complexity it brings.  Building out a distributed clustered environment from the start is a sure way to add unnecessary complexity to every subsequent technical decision.

    Now the project is over budget and behind schedule.  Any work that needs to be done has to deal with an architecture that adds complexity to every software decision and makes deployments more error prone and time consuming.

    Lesson learned I guess..  An MVP release should really focus on the keeping things as simple as possible for as long as possible.  For a $1M project, a 50% cost/time overrun is a lot of money.  Especially when a simpler architecture might have been 50% below the initial budgeted amount.

  • Success and Confidence: The Trump Effect

    With election activity heating up in the USA, and the prominent Donald Trump attracting a lot of media attention as well as leading positions in the polls it is interesting to think about what a crazy world we live in that someone like him has accumulated so much wealth and power.  It begs the question, why is he a billionaire and not me?

    The one thing that stands out about Donald Trump’s character which likely has much to do with his success is the unflappable confidence he has in his own opinions.  It takes a certain type of person to be able to double down from a personal debt of $900M and get back to billionaire status.  It says something about the amount of risk he’s willing to take on, as well as the amount of assets he has been able to leverage.

    His confidence is further evidenced by the way he talks about crazy ideas like building a wall on the Mexican border – with absolute conviction.

    Confidence is a trait that on it’s own convinces us of an underlying intelligence even when it doesn’t exist.

    When you need to get buy-in from others, confidence is an important part of gaining support.  It’s no doubt that Trump’s confidence allowed him to negotiate tremendous deals that allowed him to build his empire.

     

  • Focus is Critical

    At this point we all know that being a good multitasker is a myth.  The time it takes to context switch between projects can vastly wipe-out any perceived productivity.

    This has become more apparent to me recently as I have been asked to take on more work, or have taken on more for myself.  As a result annual goals fall behind, projects make slow progress and planning overhead rises.  This has knock on effects to perceived expertise – the amount of forward movement on a particular project is less in real-time than hoped.  When a month passes by with only a week of progress things are intuitively slow and perceived value drops.

    It’s important to say “No” to incoming requests and limit what is on your plate at any one time.  This actually can have a positive impact on your perceived value.  Saying “Yes” and failing or being late is far worse than saying “No” and leaving the impression that you have more important work to do.

    Focus is critical to both your own stress management, your external perceived value, and your productivity. Strive for only what is important, say “no” more often, and you will benefit.

     

  • Flâneuring

    A term made popular by the French Poet Beaudelaire has been on my mind for the last month.

    Flâneuring is when you take an idle stroll. It’s a practice that that I learned about from reading vagabonding by Rolf Potts. In the world of travel, flâneuring is a way to break out of the tourist traps and find your own adventures.  You just wander until you come across something that peeks your interest and let serendipity play a role in determining your experiences.

    The act of flâneuring necessarily requires you to abandon the structure and habits you might have – to give up your schedule and open yourself up to things as they happen.

    Even when not being a tourist, flâneuring can be a positive and eye opening experience in your own city.  A random stroll through unfamiliar streets gives you the chance to discover new restaurants, shops, paths and people.  It is all too common to for people to live in a place and never see it.  You get stuck in a routine for the regular route to work and the shops you frequent.  It seems odd but there are many native New Yorkers that have never been to the Statue of Liberty, but when things are so close it can be easy to take them for granted.

    More broadly, the spirit of flâneuring is that of discovery and exploration – something that seems so natural to us as kids.  Everything is new when you are young.  The older and wiser we get the more we need to go out of the way to encounter new things.  New things drive personal growth and make life interesting.

    Go flâneur!

     

  • Learning How to Learn

    My recent experience with daily freecoding taught me a lot about learning programming and about how you learn new skills.

    There were several types of freecoding sessions that I did and each of them proved useful for different reasons.

    I had a handful of memorized programs one of which was to program a deck of cards, shuffle the deck and print them all out.  I memorized this and practised several times recalling the whole program and typing it as fast as I could.  Getting fast at this reinforces basic syntax, it improves your muscle memory for typing and helps add to a repertoire of coding patterns that can be recalled quickly.  Since the bulk of programming day to day is loops, string manipulation and parsing, this type of practice can greatly improve your productivity.  However, it doesn’t help with your ability to solve problems.

    Other days I would seek out a problem.  Rosetta Code is a good resource for coding problems that can usually be solved in just a few lines of code.  I’d find something that sounded interesting, implement my solution and then compare to the published one. This process helps with your ability to produce code that can do what it needs to do, but also by then reading other people’s solution you often learn about nicer or more concise ways to implement it.

    The final type of freecoding I did was to find an interesting library or package I wanted to try out, and implement some examples with it.  From a learning to code perspective this doesn’t help a lot.  Much time is spent going though documentation and the temptation to copy and paste is high.  It did, however, let me explore a lot of variety and learn about some specialized things – such as what you can do with special non-printable terminal characters)

    Some ideas I have to make the experience better going forward would be to add a scheduling component.  We remember things better if we try to recall them just before we forget them.  This is the concept used in Spaced Repetition Systems (SRS).  Applying this to a learning system for coding might include a development phase where you create a new piece of code that introduces new concepts and then a handful of recall sessions where you try to re-implement one of those previously created programs at a later date.

  • Github Streak is Over

    Vacation broke my Github streak of consecutive days for coding and contributing code openly.

    It started out as a way to get me back into programming Python code and trying to test a theory I had about how to become a top 1% software developer by doing “Freecoding”  – a method based on what authors use to overcome writers block and become faster at writing.

    There were several key lessons I got while doing this:

    • It can be difficult to think of original things to program every day
    • I had the opportunity to find a lot of gems in the Python standard library and practice using them
    • My knowledge of the language is significantly deeper than it would be had I just been programming professionally
    • It gave me time to explore some of the other sub-communities within Python – example: Mathematics, plotting, and  machine learning

    One thing I was hoping this would be more effective with was getting fast at developing with a web framework.  Over the course of 250+ days of coding I wrote nearly 25 web applications with Flask. I wanted to get to the point where I could type a new web application as fast as my typing speed allowed and that recalling names of packages and how to bootstrap a new application would come so quickly that there would be no cognitive load at all.  It turns out that it’s hard to do.for a couple of reasons.  First, If I don’t know what the application is going to do (within the scope of something that can be finished in < 30mins) then I get bogged down with figuring out something to do.  When I tried implementing the same application everyday it became a memorization exercise and didn’t help with the understanding of what I was typing.

    Additionally it was interesting to experience how my short term memory dropped off over time. After several consecutive days of practice I could perfectly recall a 100+ line program (and type it in 15 minuts), but a break from that practice for a couple days and I’d encounter blocks in my recall.  A month long break and most of my memory was missing too many specifics to completely recall it.

    Now that the streak is broken I’m calling it quits and re-allocating that time for something else.  I have some non open-source code that I’m trying to work on, and I’m falling behind on my reading goal for the year.

  • Lessons From 253 Days of Consecutive Freecoding

    My recent camping vacation is what broke an epic 253 day streak of github commits.  Overwhelmingly this activity was a daily practice of freecoding to see first hand just how effective it could be at getting better at programming.

    Freecoding is based on a writing technique called free-writing which is supposed to get the juices flowing and eventually lead to you developing a faster thought to fingers connection for getting your ideas out.  It is a popular practice for authors, but has never become something that programmers took up.

    With a bit more extensive experience now with the process and it’s effectiveness I can draw some conclusions about how it works and where the difficulties are.

    By far the biggest difficulty is trying to think of something original to write every day.  Unlike story writing where you can ramble out words with markov chain like inspiration, the strict syntax of programming forces you to think ahead about what you want the program to do.  I also found it psychologically difficult to finish a program that had syntax errors.  Finally, writing a script is not always easy to to linearly and jumping around the code provides an interruption that can stop the flow of thoughts.

    There were a lot of positives though.

    • Finding interesting things to program everyday inspired me to keep a list of interesting projects and try them out
    • It gave me an excuse to test out things like how threading is limited by the GIL in python which I hadn’t run into with my job
    • was able to scour through the standard library and uncover some features that I now incorporate often into my code.
    • got a much better handle on parts of the language that I didn’t use often such as functional programming
    • took time to try some popular libraries in areas I don’t usually get to deal with (mathematics, graphing, and machine learning)

    Through this practice I feel like my knowledge of Python was able to reach a new plateau.  Learning by doing and practising everyday is a tremendously good way to improve.

    if you are curious what kind of code I wrote everyday for 253 consecutive days it’s all on my github account.