Category Archives: Advice

For software developers there is an unhealthy prevailing belief that being a great programmer is some innate skill that others have. Brilliance with developing code is difficult to train for because it either requires some gift you don’t have or years of on the job experience.  There is a large amount of impostor syndrome within the community which is not healthy or productive.

Of course people who are top developers know that it takes a lot of hard work to understand core concepts. It helps to have a mentor and a solid education and access to training.

There is a tactic to getting better which more programmers should be using.  Deliberate practice is the most critical aspect to improving any craft and programming software is not an exception.  Like playing piano or painting or ceramics there is creativity and technical skill which can be improved on with deliberate practice.

If you want to get better at your craft it is not good enough to simply work on job tasks. For work you typically do something once and then it’s done, there’s few opportunities for repetition and critical evaluation.  If you were learning to play piano and you had a sheet of music the equivalent to developer workflow would be to play through the song once, stopping to go back and fix your mistakes then when you finished you’d put the song away move on to a new song.  Practising piano requires playing the same song hundreds of times, you start by playing and focusing on not making mistakes, when that is accomplished there is still practice at making the song sound good with appropriate pedal usage, tempo and dynamic, and finally when that is good enough you can continue to practice the same song and add your own touches – arpeggios, slurs, delays etc.

How many times have you implemented a deck of cards?  Can you write one top to bottom without looking up examples on stack overflow, or querying the documentation or searching through code completion lists? Could you write a deck of cards in a procedural, functional and object oriented styles?  Could you meta program a deck of cards? Could you make a deck that is thread safe? distributed? Web scale? Obfuscated?

Practice. Do it often, and do it deliberately.

Writing code everyday has been an interesting challenge.

In 2015 I started to work towards a long streak on GitHub which eventually capped out at 250 days. The questions I wanted to answer was:

  • Can I apply ‘deliberate practice‘ to programming and get better?
  • Can ‘free coding’ (like free writing) be effective way to push through writers block?
  • How important is memorising to your coding performance?
  • If syntax and API unknowns don’t present bottlenecks to your flow how fast can I translate an idea into code – can it be limited by typing speed?

I started a repository for my daily coding.  It had a simple script to generate a blank file everyday for me to code in and I would try to code something.  Sometimes it would be to explore a new python module, or fiddle with syntax, or challenge myself with a rosetta code example or replicate a previous day’s code from memory.  I wrote dozens of Flask apps, memorised the methods of lots of APIs, and gained a level of confidence with writing Python that I don’t have with any other language.

At the end of the streak I had a repository with hundreds of small scripts.  Only a handful of them were multi-day efforts or had any real value.  The variety of this collection proved to be useful on it’s own too – several times I have referred back to these examples to help with my actual work and to copy/paste snippets from.  Some of them started me down a path of exploration – like calculating the return on investment for solar panels.

Part of what enabled me to maintain this streak as long as I did was a simple script I wrote to check GitHub for daily activity and email me if I hadn’t yet committed any code.  This simple hack was enough of a reminder to keep me focused even when I was otherwise distracted.

This past week I turned that script into a web service anyone can use.  CodeStreak.io will watch your public github activity and email or SMS you if you haven’t yet pushed any code for the day.  This is the first project of 2017 that I plan on building to expand on my previous streak.

In 2017 I want to build 12 projects.  Each should be roughly 10-20 hours of effort and result in something that provides value for other people.  CodeStreak.io is an example of the kind of project that I want to undertake this coming year, but it is also a tool to help ensure that the momentum is sustained for 12 months.  Blocking out 4 hour chunks of time is a helpful way to really focus and be productive, but 4 hours once per week has been (for me) too sparse to maintain interest in something long enough to finish it.  A little bit everyday keeps a project on your mind.  Attempting to maintain a streak will be a tool to power through the bits that are otherwise uninteresting or difficult.  CodeStreak.io is a foundational tool necessary to accomplish my 2017 goal.

The questions I want to explore with this new goal are:

  1. Without a concern for generating revenue can I just write cool things and get them out there?
  2. Can I get deeper into something new and create something useful out of it with less than 20 hours of effort?
  3. Can you get good at seeing a project from start to finish – what skills or traits will improve the odds?

Hopefully, I’ll have some answers at the end of 2017.

Recently I’ve been interested in finding a business investment – something like a B&B that allows me to put some of my retirement savings into a business that I have some control over its success.  The normal process for something like this would be to write a business plan or at least do some back of the envelop estimations for how much revenue is expected from the property.

The usual tool of choice is a spreadsheet.  And those are excellent ways to work through the numbers and visually see things.  However, the flexibility of a spreadsheet is somewhat limited for even more advanced analysis.

I wanted to take things to a different level.

What information could I get from looking at the market and scraping webpages that I could feed into a bigger model to see how other owners of similar businesses do.  By pulling in 1000+ comparables and running them all through a similar model to estimate each of their profitability it becomes possible to identify the traits of a successful business.

Applying this sort of ‘big data’ analysis is proving interesting.  There is an amazing amount of information freely available on the internet, but much of it exists in different silos.

In the example of running a B&B, there are lots of them listed on booking.com and similar travel booking sites.  These provide a partial picture of how popular a place is (from it’s availability) and the revenue (from the cost to stay there). Another big piece of the picture is the costs – which you can estimate by checking real-estate listings.  By putting all this information you can see many interesting things.

If your model is accurate then you can get answers to these questions:

  • What percentage of B&Bs turn a profit each year
  • Is there an optimal size / number of rooms
  • which attributes of the property correlate most to it’s profitability

You can take a deeper dive into the best performing properties to see if they do something unique – do they have nicer websites / photos? Do they do aggressive advertising? Are they active on social media?  Answers to these questions can help you find the strategies that are working best in the market – and perhaps things that are a waste of time.

This type of analysis is something I think more people should be doing.  It provides some competitive advantage in terms of the information that you bring with you into a potentially big investment, and reduces the risk that you inadvertently buy a lemon.

 

I recently had an experience where I was given the same programming problem as a handful of other software developers.  My advantage was that I was using Python while the other people were forced to write their solution in Java or C.

The difference in the amount of time it took to solve the same problem with a different language was striking.  Most other people completed in about the 45 minute mark whereas I had finished in just 15 minutes.  An average of 3x less time.  That’s a massively significant difference in developer performance that comes primarily from using languages that aim to be readable and focused on developer productivity.

I’d always known that Python was a productive language but that was the first time that I had experienced first hand just how beneficial it can be to switch from one platform to another.

Imagine taking a 3 month project and complete it in just 1.  That’s a massive savings; enough to change a business idea from impractical to highly lucrative.

One thing I’ve learned over the last couple of years is that with the right approach and the right tools you can make difficult application development accessible to even small budgets.  Sometimes it requires creative thinking and accepting unconventional solutions.

I’ve worked on $1M projects that could have been MVP’d for 20 cents on the dollar by choosing different technology and different developers. It’s quite shocking to see just how variable it can be to develop the same software with different tools.

If there’s a lesson in this it’s: Take care when choosing the people and technology.  The right choice can save you a tremendous amount of time and money.

Productivity is closely related to skills and talent so it’s been something that I have a keen interested in.  The actions you take to get better at what you do have fairly important role in your wealth and happiness.

I recently read the book “Talent is Overrated” by Geoff Colvin.  It was insightful in a lot of ways and built upon ideas that I had myself about what it takes to reach for the pinnacle of success.

Geoff busts a number of myths about successful people.

  • High IQ does not correlate to significantly more success
  • Fantastic memory is a skill you develop
  • “Deliberate Practice” is the (only) key to improvement
  • Experience in many cases correlates to lower job performance
  • Child prodigies rarely maintain their lead into adulthood

In a handful of skill sets there is a very clear framework for practice.  Music, athletics and chess have very well understood methods for improvement.  You start early, practice, learn and exercise until your skill improves. Stick with it long enough and it’s possible to reach world class standards.

With other domains of knowledge the frameworks for practice are not as well defined.  How do you practice software programming, project management or reading x-rays?

If deliberate practice is the determining factor in skill acquisition then how can we make sure that the education system supports it, and society builds on it to influence corporate decisions in an ongoing way?

The term “deliberate practice” is specific.  Simply working 9-5 at work related tasks where you’re expected to produce output is not considered practice.  Deliberate practice is hard by design, it is a process to continually push you slightly past your current limits, repeatably, and with feedback.

Hitting a bucket of golf balls at the driving range is not practice, but it provides the illusion of practice.  Without a coach to identify and provide feedback on each swing it will be very difficult to improve your skill.  Even Tiger Woods, at the top of his game, had a coach.

To answer the question for something close to my heart, how do you deliberately practice software development, I believe the answer lies in either finding someone better than you who can review or pair program with you who also understands how to coach, or by finding superior open source code to study and reproduce.

One of the examples from the book was how Benjamin Franklin learned to write. He picked articles from Spectator magazine that he wanted to emulate and he would take notes about the article.  After a few days when he had forgotten the text he would open his notes and try to re-create the original article. Then by comparing his against the original he could identify what he could have done better.  In the absence of a coach, this seems like a fairly ingenious way to get immediate feedback on your practice.

It would be good to test this sort of approach with programming skills.  It’s a concept I have started to test.  As with all practice, it’s is a long effort before the benefits are expected.

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.

What do you believe is the single most important thing that will affect your productivity?  Time management? Software tools? Calendars? ToDo Lists?  No.  The most important thing that will affect your productivity is your expertise.

Knowledge is the baseline for almost all work that we do in today’s information economy.  We simply cannot produce good information products without the knowledge to do it. And gaining the knowledge as you go is akin to assembling the tractor before you can use it to plow the field. To be maximally effective you should strive to have the knowledge for how to do what you need to do.

There are two aspects to knowledge that can be looked at as it pertains to your productivity.

  1. Relevance – The more relevant your knowledge is to the task at hand the more efficient you will be
  2. Competence – how easily you can apply your knowledge.

When you have relevant knowledge and have competence with it then you have an expertise that allows you to be productive at a much higher rate.

The four stages of competency will give you a sense of how effective you knowledge is towards your productivity. Simply having the knowledge is not enough to being extremely productive.

  1. Unconscious incompetence – you do not know how to do something and haven’t yet recognized that
  2. Conscious incompetence – you realize that you don’t know something
  3. Conscious competence – you have the knowledge but it requires concentration to execute
  4. Unconscious competence– through extensive practice your skills have become second nature and can be performed without effort

It has been said that the best programmers are 10,000x more productive than an average programmer. While this claim is outlandish it exemplifies that people with experience hiring programmers see as truth. The right programmer with expertise can implement quickly while the wrong programmer may not even recognize that they don’t have the knowledge required to do so.  In the worst cases incompetence is a liability – incorrect knowledge applied incorrectly can pose a significant threat to your business.

 

The main lesson from a handful of recent books that I have read has been focus on fewer, more important things if you really want to make progress.  Less but better.  And that the best way to maintain the momentum on the projects you do want to take on is to make small steps and celebrate the progress, rather than reaching the end goal.

Studies have shown that the best way to create engagement in your work is to either experience achievement or recognition of achievement regularly.  This is something you have probably experienced personally.  The best projects are the ones that you can feel like you finished something at the end of every day.  Massive all or nothing projects that drag on each day where you work hard but it’s difficult to see the progress can wear you down very quickly.

With this in mind, it is important to structure your projects such that there are always pieces where people can feel personal accomplishment or otherwise provide some external recognition of something that cannot easily be sub-divided in to small tasks.

This works at various different scales too.  Entrepreneurs talk about Minimum Viable Products and “Done not perfect” to describe that initial ship-able product that can be celebrated as a turning point in the business.  At the day-to-day scale the accomplishments might be to implement a button on an app, or finalize financing terms for a business loan, or write a chapter for a book.  When you start off the day knowing the small task that provides a small step towards your end goal, then at the end of the day you can feel that sense of accomplishment when you complete it.

These small daily accomplishments are THE major factor in maintaining momentum.

Work each day without the sense of accomplishment is like crossing a bog – slow, tedious and dreadful.

With the sense of accomplishment it’s like driving a car on smooth paved roads – even if you take your foot off the gas you’ll keep going forward.

How do you make this concrete and apply it to YOUR goals?

There are two steps/skills required to control and build your momentum.

  1. Focus
  2. Planning

Focus is about very specifically knowing what your goal is and using that goal as part of all your decisions.  Develop your goal by taking time to really think about it, make it something measurable, attainable, and time boxed if possible: “lose 10 lbs by summer vacation”, “reach $1M in revenue this year”, “sign up 1000 new clients this month”.  With this goal in hand filter all decisions through it.  “Will X help me accomplish Y faster?” If the answer is No, then put it aside, decline the offer, and continue to use your time on things that will get you to your goal.

Planning is about taking the time to really think about how you can accomplish your goal.  Figure out how to divide a big goal into smaller daily or weekly goals – something that is actionable. $1M per year in revenue is more difficult to understand than a $4000 per day sales goal.  Then put systems in place to measure and accomplish those smaller goals. Up front planning is important but it is also critical to re-evaluate and adjust the systems as progress is made and you learn or experience roadblocks.

With a good plan and the ability to maintain focus on your goal you stand the best chance of having the daily accomplishments needed to create momentum.  Slowly but surely these accomplishments compound until massive progress is done, goals are met and success is had.

All software developers know that measuring a developer’s productivity by counting lines of code written is not an effective way to measure their output.  The correlation between the technical difficulty of a problem and the number of lines of code is not always 1:1.  Which means that one developer can write 10 lines in a day and be very accomplished, while another could copy/paste a solution of 1000+ lines in a day which was trivial.

On the factory floor managers always should be measuring opposing indicators.  If you’re measuring the volume of output – you also need to measure the quality of output in order to prevent creating an unbounded method for taking advantage.

For example.  If a manager of Intel processor factory production line focused solely on the number of chips produced each day, and cancelled all quality control checks then production output would likely skyrocket.  In short order, however, the defects would be found by customers, the business would suffer.  On the other extreme, if the manager focused solely on quality and checked every aspect of each chip produced then costs would skyrocket and output would crash.

The problem with measuring a software developer by the number of lines of code they produce is that there isn’t an opposing measurement of the quality/difficulty of those lines.  Gauging the quality or difficulty of the produced code would likely require peer review, and for that peer to grade the code.  Nobody wants to be the ass that gives their co-workers D- grades on their code so it becomes difficult to get honest scores.

In my opinion, counting anything is better than counting nothing.  If Bill suddenly goes from committing 100+ lines of code per day down to 10 lines per day it may indicate something that a manager should investigate.  If you weren’t measuring output then it would be impossible to know about or fix anything that Bill was having trouble.

Authors measure themselves by pages written per day.  Writing 10 pages of crap is better than ending the day without having written anything. At least once things are on paper they can be communicated and others can help edit things to find the gems inside.

Programmers often take something for granted that would make them significantly better at their job.  No it’s not communication skills, or management.  The biggest differentiator between the best and average programmer is how often they have to refer to google to solve a problem.

Any programmer who knows the basics of programming in a C like language feels like they’re competent enough to write Javascript – even if they only have to program it occasionally.  What ends up happening is they stall on every other line of code to crawl stack overflow for solutions.  Despite their lack of skills they can still write complex code and get things done.

No doubt that Google and Stack Overflow are awesome resources that make it easier to write things you don’t really have the knowledge to do off the top of your head.  Each detour to the search engines eats time.  It takes 10x more time to find a good piece of code on the internet than if the programmer knows how to write it already.

The skill that most programmers overlook is memorizing the APIs and languages they use.

When you take away all the crutches we use to help write code by writing with pen and paper, without the help of reference material gaps in your knowledge become brutally apparent.  Try this from time to time.

Most programmers I know seem to think that picking up a new language or framework can be done in just a few weeks.  My experience is that unless they take deliberate time to read and learn and build expertise the typical result is getting to a passible skill level and then plateauing.

Do not underestimate the value of depth of knowledge.