Category Archives: Advice

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.

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.

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:

Continue reading

collection_01_largeProbably the best thing about being a software developer is that everything is always changing and there’s always something to keep you engaged and learning new things.

I think that is what helps keep your mind sharp as you get older. Being a programmer full-time is like spending all day doing Sudoku puzzles and getting paid for it.

The new iPhones and especially the Apple Watch opens up a new world for programmers to work on bringing software ideas to even more personal hardware. The amount of sensors and processing power that is now making its way from your pocket onto your wrist is astounding. The true effects of this shift has not even begun to be understood.

It was just 7 years ago that Apple announced the original iPhone and changed everything about how cellphones are perceived. They introduced the full touch screen interface which is now the way that all smart phones operate.

Between then and now Apple introduced the iPad. An entirely new category of product that has since become a staple part of every household.

There is a trend to this, of course. The continuing miniaturization of electronics coupled with advances in software and the ubiquity of the internet.

The Apple Watch is the current pinnacle of the technology. And this version 1.0 device is just about to land in the hands of millions of users.

Developers have a unique chance here to be at the front of the next wave of technology that should last for 7-10 years.

The amount of technical innovation between the first iPhone and the first Apple Watch is truly a massive leap. Given that technology has tended to advance at an exponential rate, in 7 more years it is very difficult to imagine just what is in store for us. What will be possible in 2021?

Back to the here and now… The kinds of things that we developers can start to work on which are personal enough to wear on your wrist and take advantage of the entire stack of established technology abstractions it mind blowing.

From the expansion of the data gathering technology that is already built into the Apple Watch that can be recorded, analyzed and integrated into cloud systems. And on the other you can feel the pulse of the world on your wrist as the internet gets filtered and pushed to you.

With things as they currently are hardware wise, developing a program that automatically detected a heart attack and notified the ambulance on your behalf would actually be relatively simple. There are so many things you could detect through the accelerometers, pulse sensors, and pressure sensors that before now there was feasible way to develop.

Creating an interface to everything on the internet and putting it on your wrist is perhaps just an evolutionary step from your pocket. However sometimes even a small change in the user experience can result in a larger shift. As Siri has gone from 95% accurate to 99% accurate in understanding spoken commands the usability of the Siri has exploded. It remains to be seen if the Apple Watch will result in a cultural shift similar to the one that smart phones ushered in.

I would encourage all software developers out there to take on this challenge to build the next generation of personal software that can possibly play a big role in all of our lives for the next decade.

one thing programmers should do more oftenThis past week I found myself with a task of creating pages on this site for all the Mobile Apps that have been developed by Halotis Inc. At the same time I wanted to get the marketing material organized for all of those apps in a consistent directory structure.

Which lead me to something I believe more programmers should do more often. Write Automation Scripts. Rather than manually create the directory structure for 23 different Apps and find all those apps in the App Store to get their descriptions and screenshots. I was able to write a script to create the directory structure, search iTunes, pull out relevant information, and download all the screenshots.

It’s what I love most about Python. It becomes so easy to find a decent library for any public API, and quickly whip up a command line utility to automate what would otherwise be a tedious task.

Getting good at writing these sorts of automated scripts is a differentiator. After a while of writing them, you build up a library of neat scripts that can help you day to day to get more done in less time.

A script, once written, becomes an asset to be possibly used again and again in the future.

Getting into the flow or zone as a coder is when you are your most productive and code spews from your fingers into your favourite text editor as fast as you can type. When in the zone you can seemingly pour out 100’s of lines of code in no time.

But how do you get into the zone other than by pure happenstance?

Authors have a technique called free writing which was popularized in Julia Cameron’s The Artist’s Way for which the rules are simple:

  • Select an amount of time: 5, 10, 20 minutes for example
  • Write continuosly and quickly for that amount of time ignoring spelling, grammar, formatting
  • If you can’t think of things to write, write about that or simply scribble. just keep things going from your brain to the page.
  • When your time is up, review what was written and mark anything interesting to explore further in a future free writing session

The goal of free writing is to build up enough momentum to blast through mental blocks and quickly transition to a state of flow for the real writing process. It is meant to be done daily as part of a morning routine before real work starts.

I’m curious if a similar technique could be used to get into the zone for coding. A quick Google search revealed no information about anyone exploring this idea so I thought I would.

Here are the rules I’m using for freecoding:

  1. Pick an amount of time before hand 5, 10, or 20 minutes for example
  2. Use a text editor where I can turn off syntax highlighting (to avoid the impulse to go back and fix typos)
  3. Code in a language that I know well enough to code without referring to documentation
  4. start coding and don’t stop typing. If you can’t think of something to code just code about that. it doesn’t have to run, it doesn’t have to make sense or be correct syntax. Try not to go back to code out of order.
  5. Don’t try to accomplish anything that will require you to stop to think. ie. don’t try to implement your favourite sorting algorithm.
  6. If you code yourself into a spot where you don’t know the API well enough, just fake it out with a call to a magical function that does what you want.

When time is up, turn on syntax highlighting and read what you wrote. Make notes about anything interesting that you’d like to explore again in the future. Note things that you were hung up on with syntax or APIs that you should brush up on.

The purpose of freecoding is to limber up your mind before starting real code. The secondary benefit is to identify gaps in your knowledge of a language or library where you might have to stop to look up the documentation.

Use the momentum built up in the freecoding session to launch into a real project. Try to keep the transition freecoding and real code somewhat smooth

As an example here’s part of what I did in my first 5 minute freecoding session:

a = 'hi there'
b = a.replace('hi', 'bye')
a. reverse()
c = fun(a)
def requestA(a):
    return GoogleThis(a)
if requstA(a) == 'no results':
    println("there's nothing in the google machine")
    return tryBingInstead(a)
requestA('matt warren')
b = b.capitalize()
b = b.reverse()
b = b.capitalize()
not_sure_what_to_type = b
def star_trek_is_better_than_star_wars():
    return true
if star_trek_is_better_than_star_wars:
    print "hell yeah"

There’s nothing interesting going on here, it’s not complete thoughts and doesn’t accomplish anything nor does it run. the point is to simply start getting a flow of code coming by reducing any blocks that might prevent it (in this case by removing the need to create something that runs or even makes sense).

Upon reviewing this particular session I might decide that the concept of using bing as a backup for google is interesting, and that I need to increase my vocabulary of string functions to call upon.

In my limited trials so far it’s clear that there is a bit of a skill to freecoding successfully. For all other coding you do there is a goal to reach, something specific you want to implement. I suspect that after a couple weeks of regularly freecoding the code will start to get more complex, better structured, and longer thought streams of cohesive code segments.

I am still early on in my experimenting with this concept. However, if it is as effective as free writing is for authors, then perhaps free coding can be a daily ritual more of us can use to boost our productivity. I’d like to encourage every software developer to give it a try and report back (if they like) with how it worked or didn’t work for you.

Grabbing the best ideas from other industries and applying it to your own is a fantastic way to learn and discover new ways to do things.

I was listening to the Tim Ferriss podcast yesterday in an interview with Neil Strauss.  Two best selling authors discussing their creative process for writing a book.  It got me thinking if some of the approaches they discuss could apply to to software development -which is also a highly creative process.

Let’s break down Neil’s process a bit.

The first part is to do a lot of research.  For example, when Neil is doing an interview with a celebrity, he will read everything they’ve written, listen to ever song, devour every bit of information he can about the person.  He writes out a list of 100 questions for the person and studies it like you would for exam prep.  Finally when it’s time for the interview he puts the questions in his back pocket and forgets about them.  As a result of this level of preparation and study the interviews can flow naturally.  He has a backup of questions to draw on if the conversation stalls but usually he can riff off the bulk of knowlege he has collected to build rapport and get to the really interesting details.

With a cache of notes from research it’s time to start writing.  There will be several drafts and the goal of the first one is to “Write to the end”.  Convert the pile of notes into a story as quickly and rough as possible without self editing along the way until you get to the end of the book.  This first draft will be read by no body else.

After the first draft you are just 1/4 the way finished.  The second draft is done for the readers.  You cut out all the uninteresting pieces, ensure the story arc is solid, characters are developed enough, flow is good, and jokes are funny.  You do this by putting on the hat of a reader and ruthlessly editing your first draft.

The next step is to put on the hat of a hater.  To deflect criticism before it happens you go through it again with the perspective of someone who wants to debunk your stuff and criticize your ideas.  At this step you fact check everything, and make sure there’s nothing offensive, or at least that the counter points are acknowledged and dealt with.

Finally it goes to the editor and is test read by anyone who wants to read the manuscript. Listen to their criticism, and adjust your book to improve things and cut parts that people don’t find interesting.

After enough feedback you’ll know when to lock down the book to a final version and send it to be published.

For an average size book this whole process can take upwards of a year to complete.

There are some lessons that we can take from the best approaches to writing books and apply it to writing software.

Notice that this approach to writing a book is not Agile, and it’s not waterfall, it doesn’t involve sprints, scrums or user stories. It’s completely unique to the way most software is created.

The first part of Neil’s process is research.  You might roughly correlate this step to requirements gathering but that vastly understates the effort Neil goes through.  I have never met a developer that thoroughly masters the domain knowledge before typing anything the way Neil does.  Taking months and often years to interview people, take courses, and generally immerse yourself in the space you will eventually write about gives you skills and knowledge to be able to write “to the end” without pause.

Side note: Interruption is one of the most detrimental things to the creative process. Stopping to look something up, or ask a question of the client can waste half a day of productivity.  Agile methods promote this open communication during development… maybe there’s a better way.

Writing to the end for the first draft is something not possible without having enough domain knowledge to do it in the first place..  There really isn’t a comparable product in any software project I have personally worked on which compares to this first draft.  The scope of Neil’s first draft expands far beyond what is in the final book as he will likely cut 50% of the pages during editing.  It has me wondering if it would be a good software development approach to rip through a 20,000 line first cut of an application knowing that I’d delete 1/2 of the code before being finished, slashing out features along the way.

If we did write this quick rough first draft application with the intention of whittling away anything superfluous to arrive ultimately at a publishable product then the next step would be to put on the hat of someone who wants or needs to use this software. Can you make the interface more intuitive? Can you give it some life? Are there any features that are more complex than they’re worth? What can be cut without destroying the utility of the application?

It would be only after these changes have been made that anyone other than yourself would see a demo.

In Neil’s process the final step is essentially debugging. Going through the application yet again with an eye for correcting errors, fact checking things, getting a lawyer’s review for liability etc.  At this point you would also ask for the input from as many test subjects as you can, gathering and filtering feedback to fine tune rough edges.  Essentially you want to make sure that if someone is trying your software they don’t have a reason to ask for a refund and they can’t claim that you or your company are incompetent.  The final product has to be great.

Only after enough friends, family and colleagues have used the software that you feel confident in it do you call it done.

It’s interesting to wonder if this would produce a better product than the typical agile developed software.

There are a couple of significant differences in software vs book writing however that need to be addressed.  Software is rarely a single developer’s sole project.  There is usually a team to divvy the work between. This team adds some communication load to the project as people need to be in sync.  This team approach doesn’t work well if all the domain knowledge is stuck in scribbled notes and in the head of  one guy that did the research.  Would Neil’s approach scale to writing a 10,000 page book with 4 other writers?  The counter point would be that if you’re looking at writing a 10,000 page book maybe it would be better to write 20 500 page books and only have a single author per book.

Software is also not written linearly.  When you start to write a book chapter you may be able to start writing and continue without stopping the flow of words.  You probably wouldn’t be halfway through chapter 18 and realize that it would be good to foreshadow what’s happening earlier, then stop and go back through to find a good spot to add that foreshadow element to an earlier chapter. A disruption like that would completely disrupt the flow of your writing.  It’s difficult to write software without jumping around like that.

Programming languages are much more rigorous than English.  it’s not always possible to skip pieces where you need to know an answer to get a working program. There can be hard dependencies that prevent you from moving on until they get solved.  Again this is an opportunity for interruption.

It would be interesting to try this method on a software project to see how it translates.

If you are interested in getting more details from Neil Strauss and Tim Ferriss about the creative process check out this video:

A lot is being said these days about inequality. It is an issue that probably won’t be going away anytime soon as the trends continue to push the top 1% of earners even further away from the 99% as the middle class is getting hollowed out.

In the ground breaking book Capital in the Twenty-First Century Thomas Piketty goes into great detail about the real data about inequality over the past 100+ across 10+ countries.  It’s the most thorough data ever compiled on inequality.  The economic theory put forth after examining the evidence is that when the return on capital investments is greater than the growth rate of the overall economy inequality increases.  This seems to make sense intuitively as the families with capital to invest are the ones that see the most gains (on average)

What does this result have to teach us about running a business right now?  Well, we live in a time where capital is returning better than labor.  In concrete terms that means that in the aggregate (ignoring local anomalies) the cost of employees is going to grow slower than the value you get from their work.  If there’s something you can take home it’s that it is a great time to be investing and growing your business.  Hire employees, create products, launch services!  Take your profits and re-invest it – acquire assets, purchase stocks/bonds, and don’t let it sit idle.

On the other hand you will be on the loosing side of the equation if you are the employee eeking out minor raises every year.  If that is your situation then now is the time to get your shit together.  Aggressively get yourself into a position where you have capital to invest (pay off debt, grow your savings). Create assets such as publish a book, write software or invent something (something that doesn’t require ongoing labor). It has never been easier to sell things into a global marketplace.

Interestingly, during the time when the rate of return on capital was less than the economies growth rate, it was a great time to be an employee.  This happened during the golden years between 1945 and 1970 when the classic advice of get any job at the bottom of a corporation and work your way up by being a go-getter actually worked!

A 20% investment seems to be the sweet spot for a doable amount that still results in significant benefits.  In Personal Finance saving 20% of your income is a great goal to strive for;  Businesses like Google and Thoughtbot have policies to spend 20% of your time on business investment.  You can apply this to your personal goals to achieve equally impressive returns.

Making 20% time work for you depends on one underlying premise: that it is an investment that can move you forward.

That means playing video games and watching TV doesn’t count.

For something to be considered an investment there has to be a reasonable chance that it will help you get towards your goals.  Even baby steps will help in this regard.

But also, taking some risks to learn and try something new can pay off big sometimes.

Taking one step back is often required to take two steps forward.

I have a goal at the moment to become a top tier Javascript developer (there is a lot of shitty javascript out there).  To reach that goal I am investing time into reading books on Javascript and Node.js.  As well I have started creating some commandline scripts, and web applications to put my learning to some productive causes.

Reading just a couple of books will put you in the top 1% (which is kind of sad).  Launching a handful of open source tools based on what you learn puts you into a category of developers numbering in the low thousands.  Having a popular open source tool would put you into a category of the top 100 or so developers.

Top tier developers (on any platform) are paid handsomely in our winner-takes-all economy.

It could all start by investing that 20% time into yourself by learning something new and then creating something new.

One of the hardest things in getting productive work done has always been finding time to get focused work done.  There are so many demands on our time that what we want to accomplish gets pushed out in favour of other more immediate or more pleasurable things.

Back in the day when Ben Franklin, Albert Einstein, Nikola Tesla, and Alexander Graham Bell were alive the mind numbing effects of TV were not yet felt.  These great thinkers could devote an extra lifetime to their pursuits. The average Canadian watches 30 hours of TV per week! The loss of productivity to TV is astounding.  Taking that TV time and instead using it to learn, experiment and pursue goals would change the entire country.  If people took back their evenings to tinker with robots, or learn an instrument we would be in a very different planet right now.

Reducing or eliminating TV is the low hanging fruit for finding more time in the day.

For Ben Franklin not watching TV didn’t provide any competitive advantage over other people of his time (no body else had TV either). Franklin found his extra time in the mornings. By waking up before the demands of everyone else could direct his day he was able to get an astounding amount of work done. The quiet solitude you can find in the early morning hours can be more focused and productive than the rest of your day.  It is the perfect time to exercise, plan the day, or study something new.

Converting to a morning person takes dedication and planning. But it will give you a couple more hours in your day to devote to your pursuits. (How to do this is worthy of another post)

People today, have the additional benefit of the tools of automation and convenience. Microwave ovens, coffeemakers and dishwashers can each contribute small amounts of time back to our day if used. By brewing your own coffee in the morning you save both time and money over waiting in line at starbucks.  Technology is here to serve us and make our lives more convenient so that we may devote less time to chores, and more to what we want.

Technology and automation is the 3rd leg in our pursuit of finding more time.

Finally, with so many things demanding our time, finding focus and eliminating distraction will make the time we do get more productive. As a software programmer I am acutely aware of the pitfalls of multi-tasking. The human brain just isn’t very good at actively working on multiple things at once.  It takes time to really focus our attention on a task and get into a mental state where we can accomplish significantly more. Whether through physical isolation or by using tools to reduce chatter or developing a pattern of work that provides time to focus you can get more done with the time you have.

Of course you need the motivation and ambition to direct the time you do have to productive means.