Skip to content

Stop waiting for the montage

Dear Reader,

I love 80’s movies.

Probably one of my favorite movies of the era is “The Secret of My Success”. That movie was all kinds of awesome. Like so many of the movies out there from that timeframe, it had a montage showing the protagonist working hard to succeed…for about a minute.

The concept of a montage was so overused in the era that it became a trope in films, the 80’s Work Montages.

An 80s work montage is great because it takes all the hard and boring parts of the real work that has to be done and edits them out. What is left is a few cute cut-scenes of what needs to be done sets it to a fast paced – and short – song. By the end of the song, the job is done and the viewers are left smiling because they saw the easy parts, the fun parts, but not all the hard work behind it.

Too many people I see trying to get into software development want an 80s Work Montage to teach them how to code. Ok, honestly, you probably could learn to code in a 80s Work Montage because coding isn’t the hard part. Coding is the equivalent to taking a basic grammar class. Yes, you’ve got the basic tools to write when you are done, but that doesn’t make you Tolkien.

Begin a software developer is not the same as being a coder. Software developer use the tool of code to solve problems. Being able to think critically about a problem and being to see the solution is a discipline.

Like all serious disciplines, you have to invest time to really learn how to do it. You have to start small, you have to fail a lot, and eventually you start to succeed. The more you do it, the more you succeed. How long it takes to master the discipline of software development depends on the person. All of us have different strengths. Some strengths don’t lend themselves to being able to think like a software developer. Even those that are wired for it don’t master it quickly. The best software developers I know took the time to learn the craft. They logged the long hours. They sacrificed other parts of their life so that they could focus on this.

Stop looking for that 80s Work Montage that you think will make you into a software developer. Sit down in front of a computer and start solving a problem – notice I didn’t say writing code? Start solving a problem. When you are done, solve another one. Keep solving problems until you can start to see the answer in your head.

Solving problems as a software developer isn’t a skill you can pick up in a short montage in your life. Put in the hours, master the craft, then you can reap the rewards.

Until next time,

I <3 |<

p.s. In the movie, the secret to his success was that he actually did all the work that was summed up in a simple montage.

Great writers read…a lot

Dear Reader,

Have you ever watched one of those movies where  a software developer (usually called a hacker) is sitting in front of 2 screens and on both of them code is scrolling by at a fast pace while the hacker nods knowingly like they are reading and understanding what they are seeing?

Yeah, that doesn’t happen.

A more common scenario is that a software developer will fork a repo, clone it locally, open their editor of choice and start reading through the code. Scrolling through it slowly. opening another edito for the same code and scrolling back up to a previous section and comparing the two. This goes on for a long time.

Reading other people’s code is probably the best way to learn how to program. If you know what the code does then reading the code shows you how someone else solved the problem.

Just like a great writer reads more than they write, a great software developer will read code, theirs and other peoples, more than they will write code. As a junior developer this goes double for you. Since you do not have a body of work to copy and paste from, you need to see how other people solved common problems so you can understand how to solve them yourself.

Until next time,
I <3 |<

Practice the best

Dear Reader,

The tenants of software development put forth in Fred Brook’s seminal work “Mythical Man Month” are considered by most professional software developers to be “Best Practices”. They are not considered to be best practices because someone smart wrote them down; they are given this title because for the past fifty years smart people have reaffirmed that they are the best practices when developing computer software. Brooks talks about everything from how to estimate the time it will take, to how to structure your development teams. In fourteen chapters Brooks lays out the way to handle things.

Yes, there were software development books written before “Mythical Man Month” and yes there have been some great ones written after it. Many of they lay out current implementation practices for the era and were groundbreaking when written.

Don’t confuse current implementation practices, with best practices.

Until Next Time,
I <3 |<

How to solve the problem of crappy software.

Dear Reader,

A lot of the software we uses these days is crappy. Poorly built, insecure, crap. How do we solve this problem?

We solve it by treating software development with the respect that we treat other professions that can hurt people or destroy things.

Too many people see Software Development as a get rich quick scheme. It is perceived as ‘so easy anyone can do it’ and thus we are encouraging everyone to learn to code.

We don’t encourage everyone to become carpenters; take a 12-week course and go out and start building houses. But that is exactly what we allow in software development.

Software runs the world. We need to be at least as careful in who we let develop software as we are in who can build houses.

If you want to solve the problem of crappy software, you have got to start by getting rid of untrained an inexperienced software developers that call themselves professionals.

Until next time,
I <3 |<


Think like a house painter, not an artist

Dear Reader,

The lifecycle of a software project:

  • Simple and easy to use
  • Useful
  • Complex to understand but still useful
  • Unusable because of it’s complexity
  • Refactor to make it simple

Developers love complexity. However, most of the time, complexity is the enemy.

Artists love complexity. Many artists create beautifully detailed landscape scenes that you can stare at for hours and still not see it all.

House painters however create beauty with simplicity. They give special attention to a few details, like the edges, but for the most part, their goal is to create a surface that is clean and un-marred. Simple.

Yes, sometimes software needs to be complex. As developers though, we need to adopt the mindset of the house-painter, not the artist.

Create clean, not complex.

Until next time,
I <3 |<


p.s. Props to Brandon Savage for the idea.