Author: Matt

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.

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.

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.

There 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.

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.

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…)

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.

For the last couple of evenings I have been learning about slot machines and how they work.  There is actually quite a bit more to them than first meets the eye.

I have a side project going to build a slot machine server application that can simulate many kinds of slot machine games.  Given the set of rules and reels it will build a playable demo, as well as produce all of the mathematical model statistics for the particular game such as how much money it will return to the player over time and what the volatility is.

Designing a game engine that can handle all of the possible variations in slot machine gameplay is not easy.

Ultimately this game simulator will be used to push different games down to a mobile app, which itself will need to dynamically render the reels, graphics, and animations that were set on the server.

The complexity of this side project has kind of ballooned a bit.