Category Archives: Advice

Free Coding

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.

Technorati Tags: , , , ,

Applying The Creative Writing Process to Software

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:

Capital vs Labor

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!

Personal 20% Time

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.

How to find time

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.

Minimum Viable Sale (MVS)

One of the big things about running a business is managing risk.  As an entrepreneur I know that 25% of businesses fail within the first year, 60% have failed by year 4 and 71% have failed or closed by year 10. Given that most businesses are started with the best of intentions and usually with all the time and equity the business owners can provide these failure rates are indicative of the tremendous amount of risk.

One of the most effective ways to combat the risk and reduce the chance of your own business failing is to seek validation of your business idea early.  Very early.

Lets say you have a great innovative idea for a business. To start with you’d probably ask around to your friends to see if they think it’s a good idea or not. Chances are your friends, not wanting to hurt your feelings, will agree.  “That’s an amazing idea” they’ll say.  With the positive feedback, you’ll probably feel pretty confident about starting to build your business right away.

Unfortunately that is a false sense of validation.  Your friends are probably not your target market, they are motivated to maintain friendship rather than stomp on your dreams, and they didn’t have to put money where their mouth was.

To really get a sense of whether or not your business has legs start with getting some commitments on sales from real customers, if possible negotiate full or partial upfront payment. This happens before you’ve built anything, before a line of code has been written, before prototypes have been developed. Validate that the idea has merit from actual customers and confirm that they’re willing to put real money on the table for your solution.

Only after having made your sales and having financed the bootstrapping of your business do you actually go ahead and create what you’ve promised. With customers in place you have eliminated one of the biggest and most stressful risks in business  - the struggle to find new customers.  The remaining risk is to actually deliver what you promised below cost.

Making that initial sale is almost never easy, and getting the marketing message correct from the start is nearly impossible.  Investing the minimum possible money and time into an idea so that you can market test it can be critical.

So here’s a new acronym for you: MVS (Minimum Viable Sale). MVS refers to the absolute minimum amount of effort and money required to craft a compelling enough marketing message to land your first sale.

The MVS probably includes a presentation (Keynote/PowerPoint), perhaps a website, it might require a business plan, some mockups or even a faked version of your product. For example: a mobile app could be convincingly created in something like Fluid UI without writing a line of code that could be used as a demo in a sales meeting.

Even for a free service, the MVS is worth creating.  In some cases the MVS for this could be simply posting on reddit if people would be interested in it, or linking to an opt-in form on a website to build an initial customer list.

In other cases the Minimum Viable Sale might be a production run of 100,000 widgets in which case something like a kickstarter campaign might be a good option to reach as many people as possible.

The concept for creating that MVS is to do the absolute minimum amount of work before getting paid to actually work  on your idea. By making that first sale you’ve validated your marketing message, you’ve identified your customer base, and confirmed that your idea meets a need that someone is willing to pay for.

I’ve worked in places where the business had a good idea, identified an underserved market and put heads down for 4-5 months working on building a product only to find out after the fact that the potential customers were happy with their existing system, or the cost to change their current system was more work than it was worth.  Month’s of wasted effort and tens of thousands of dollars in development costs down the drain. Alternatively they could have started by trying to sell the solution they had in mind with the intent of getting enough cash commitments to pay for the 4-5 months work upfront.  The added benefit of getting customers before development starts is that they can help refine the features required for it to meet the needs of the market. Win-Win.

Starting a business with an MVS before you develop your MVP (Minimum Viable Product) is a simple way to get off to a lower risk start and help ensure that there is a market for your MVP when it’s finished.

What Do You Know

iphone app

What Do You Know?

This is the product of my first experience with outsourced development. What Do You Know is a simple iOS game where the player guesses what word matches the pictures shown. We picked a simple game engine to start with our initial foray into outsourcing to keep costs down and to help us quickly get through an entire project and learn our lessons from it.

I’m very excited to see how this game does on the market. It is comparable or better than most similar games in the category which I hope gives it a good chance of becoming a hit.

Our biggest lessons on this first project have been:

  1. Maintain control over the source code yourself – get a code repository on bitbucket or github where your team can regularly push their code as it progresses.
  2. If you are hiring a outsourcing company request senior/experienced developers be put on the project.  Senior developers will produce a higher quality product, and give more realistic timelines.
  3. You’re the boss, coach the team to produce the best product they can by providing the best leadership you can to them.
  4. Have the final project reviewed in detail. Check the source code. Growing a good business on apps requires that you can leverage past development into the future through code reuse.

This game certainly won’t be the last time we hire programmers to develop games for us. Keep an eye out in the App Store for What Do You Know.  It should hit iTunes in the next week or two.

Competition is Fierce

EMBA_start_up_competition_996x446Our market economy is built around the premise that competition makes everything more efficient and better over time. For most products and services a careful analysis of the competitors is very important to your success.

This market analysis applies to all aspects that you can glean from your competitors. The product features and design, quality of service are obvious things for the engineer in you to look at for hints about what you can do better with your product. Business models, marketing and sales strategies are just as important to your success so look to those too for ideas that can be improved on.

Importantly, if you are planning a business idea and can’t be better than the competition in enough ways to matter DON’T WASTE YOUR TIME.

It’s an approach right out of Apple’s playbook.  Only enter a market where you know you can dominate with a superior product.

As an App developer it has become interesting to see the marketplace evolve into a much more competitive space over the course of a few years. With the vast amount of successful apps being free it’s impossible to compete on price, the race to the bottom has already finished. To develop a successful app now requires a great design, superb artwork, discoverability and viral tools for additional distribution, good marketing, and positive reviews.  There are only 100 apps in the top 100 highest grossing list, and those apps are (for the most part) doing all those things.

To have a great app idea and expect it to be a hit without addressing all these things that your competitors are doing is naive.

High Performance Static Websites on Amazon S3

I’ve been seeing more frameworks lately for generating static websites. The reason for these becoming more popular recently is the result of several developments.

  1. Cheap shared hosting is notoriously unreliable, slow servers overloaded with too many websites and hacked servers being able to infect and hack many other sites at once.
  2. The development of 3rd party services such as Disqus to power the dynamic parts of a website with embedded javascript. (removing the requirement of server side logic)
  3. The scalability, performance, uptime and low cost provided by Amazon S3 and their CloudFront CDN service.

The difference in cost between a scalable dynamic site and a scalable static website can be staggering.  So if there is a way you can convert a website over to be static (perhaps with a daily or hourly upload of new content) it may be worth your while.

A website with 1 million page views per month on Amazon S3 with CloudFront would cost roughly $6/month depending on the size of the assets.  Building up a simple server configuration with 1 database server and a webserver with small EC2 instances would bring the costs up around $150/month.

One of the nice things about developing a static website is that you can script things however you want to.  Concatenate strings in bash or PowerShell or go all the way to having a complex database backed CMS system and template engine.  It also means massively less complex server infrastructure.   No more nginx reverse-proxied gunicorn server paired with a database server and a host to tools to monitor uptime and send alerts should things break.

It’s for these reasons that I am working on my next project to have a static website backend instead of a dynamic django app.

Using a template engine like Jinja2 it is trivial to convert content over to static files ready to be uploaded.

Some tricks may be needed to handle things in a more complex static site.  Perhaps a small light server to refresh the static content every hour, or to run scheduled tasks, or to do other various asynchronous jobs.  Still the costs can be brought way down if your servers don’t have to handle the web requests.



Cockiness of Programmers

There’s no doubt that programmers are lazy people.  Anything that can be automated is, copy/paste code – you got it!

There is another trait of programmers that they assume because they can program in one language well, and have touched a few other languages over the years they can quickly learn a new language on the job.

Programmers are arrogant about their own skills.

The article What If Cars Were Rented Like We Hire Programmers? exemplifies the problem though their analogy is not accurate.  A programmers job is more like the mechanic or factory worker building the car.  If you had built or fixed only Subaru Imprezas for 10 years then you are not amazingly qualified to fix Fords.  If Ford is looking to hire, they know that there are 1000′s of mechanics more experienced on their cars in the pool.

I say this because after several years of writing Javascript, learning on the job, I finally decided to pick up a book.  The first thing I learned was just how much I didn’t know.

More programmers need to read books to master the skills they need on the job instead of relying on Stack Overflow and Google to solve all their problems when they arrise.

The thing to watch out for is the situation where you read someone else’s code and say to yourself “I have no idea how this works, or what it does”.  As a programmer that should be a red flag – you don’t completely grasp the language syntax.

If you don’t have a complete handle on the syntax of a language chances are you also don’t know how to write idiomatic code.  Without those two things mastered the code you do write will be poorly organized and buggy. The next programmer to come along to work on your code will hate you.  You will be that guy who everyone bitches about for writing bad code.

Bite the bullet, read a book from time to time.  Always be Learning.