BROADCASTS.com

b'

Some people have very strong coding instincts. They can solve problems just by looking at them, and feel like rockstars. But being a rockstar coder can only get you so far. You need one other crucial element: discipline. In this podcast, Bill shares his disciplined approach to writing code and to work in general.

Written by Bill Sourour:\\xa0http://twitter.com/billsourour

Read by Abbey Rennemeyer: http://twitter.com/abbeyrenn

Original article:\\xa0https://fcc.im/2IzwWdH

Learn to code for free at:\\xa0https://www.freecodecamp.org

Intro music by Vangough:\\xa0https://fcc.im/2APOG02

Transcript:

I wrote my first few lines of code almost 32 years ago, when I was 6 years old. I developed very strong coding instincts. I could look at any problem and immediately know how to solve it, just by intuition.

By the time I started coding the web for a living, I felt like a rock star. I found and fixed bugs faster than any of my co-workers. My team started assigning me all the most challenging features and the most nagging bugs. They even started calling me a \\u201cwizard.\\u201d

But following your intuition can only take you so far. I hit a plateau. And no amount of coding instinct was going to push me past it.

The trouble with trusting your gut

Unfortunately, intuition as a technique for learning and problem solving doesn\\u2019t scale very well. When you rely on instinct and intuition alone, you get a curve that looks like this (See original article for graph).

Of course, you can choose to accept your limits and only ever deal with problems below the line. This will indulge your \\u201crock star coder\\u201d fantasy, but it will quickly begin to limit your growth and your career. Plus, it\\u2019s boring.

As I pushed myself further and further ahead in my career\\u200a\\u2014\\u200aand started to really challenge my own abilities\\u200a\\u2014\\u200aI began to notice a disturbing trend. I was no longer the fastest kid on the block.

I had always known that I\\u2019d eventually run into people smarter and more talented than me. (My delusions of grandeur were still grounded in reality. I\\u2019m no genius.)

But when I looked around, I realized that some of the people beating me were not using a superior intellect or some sort of innate gift for code. They just had a secret weapon that I sorely lacked: discipline.

It turns out that a consistent, repeatable, methodical approach to learning and problem solving will eventually outperform any natural gifts\\u200a\\u2014\\u200aor instincts\\u200a\\u2014\\u200athat you may have developed.

Let\\u2019s tool up those problem solving abilities

Regardless of who you are, how much passion or natural talent you have, you will eventually hit a hard ceiling. I\\u2019m going to share with you a few techniques that will dramatically improve your disciplined problem solving abilities.

I\\u2019m assuming that, if you have a debugger, you\\u2019ve already run it, Googled the output, and had no luck.

I\\u2019m also assuming that if the problem was reported by someone else, you have been able to reproduce the problem. This second assumption is a big one. If you can\\u2019t reproduce the problem, then that needs to be your first step.

You need to compare the context and environment in which the problem occurred to the context and environment in which you are trying to reproduce it. Start eliminating any differences you can, one by one, until you can reproduce.

Once you can reproduce the problem, and after the debugger has failed to be of any use, you can try the following disciplined approaches.

RTFM

Read the documentation, you fool! (Admittedly this isn\\u2019t what RTFM stands for exactly, but there may be children reading.)

Actually read it\\u200a\\u2014\\u200amore than once if you need to. Don\\u2019t just skim it looking for something you can copy, paste, and pray will work.

The problem is you want an answer fast. You want that thrill of victory. But you\\u2019re not willing to put in the work. So slow down. Take a breath. Grab a coffee. And read the relevant documentation all the way through.

If you have no documentation, consider creating some, then sharing it with others after you\\u2019ve fixed the problem.

Test Your Assumptions

If you expect something to work and it doesn\\u2019t, it\\u2019s because you\\u2019ve made a bad assumption somewhere along the way. Take an inventory of your assumptions and try to prove that each one is true.

Start with the most basic assumptions that can be quickly tested. Is the server actually running? Is it connected to the network? Is everything spelled correctly? Are all the brackets and semicolons in the right place?

If you don\\u2019t start with the simple things, and it does turn out to be one of these things, when you finally figure it out you will want to jump out a window. So save yourself the headache.

Disassemble and Reassemble

Remove components from the solution until it starts working again, then put the components back one-by-one in order to find the broken piece.

This feels tedious and scary, but it is one of the most effective, disciplined ways to find the cause of a bug in your code. Make sure you have a backup before you start though, in case you accidentally end up with Humpty Dumpty code (code that you can\\u2019t put back together again).

By the way, if you find yourself in a situation where you don\\u2019t know how to reassemble the code back to how it was, this is an indication of a potentially bigger problem: you don\\u2019t understand the codebase you\\u2019re working with. That\\u2019s bad bananas, my friend.

If you\\u2019re on a tight deadline, seek help immediately from someone who understands the codebase better than you. If no such person exists, dig in for a long night, and prioritize getting to know and understand how this code works, so that you can fix it.

Eliminate Variables

Anything that can change from one trial to the next should be made to remain static while you\\u2019re debugging. You can\\u2019t hit a moving target. This is where Test Driven Development (TDD) comes in handy. If you\\u2019re using TDD, then you should have some mock objects at your disposal.

Mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts.\\u200a\\u2014\\u200aWikipedia

If you didn\\u2019t do TDD, then you\\u2019ll need to mock out any moving parts now, so that you can find the bug under stable conditions.

Here\\u2019s a tip: if you mock an object and the bug suddenly goes away, then the bug is likely in the object you mocked.

Use the \\u201cSaff Squeeze\\u201d

There\\u2019s a technique called the \\u201cSaff Squeeze\\u201d\\u200a\\u2014\\u200anamed and popularized by Kent Beck\\u200a\\u2014\\u200athat is sort of a cross between the two ideas above.

He describes it this way:

\\u201cTo effectively isolate a defect, start with a system-level test and progressively inline and prune until you have the smallest possible test that demonstrates the defect.\\u201d\\u200a\\u2014\\u200aKent Beck

So instead of formal mocks or code disassembly, you simply add the body of the functions that you\\u2019re testing into the test itself, then move the assertions down until the bug goes away.

This has the added benefit of leaving you with smaller, more specific tests.

Edit: Thanks to Jim Balter for pointing out this link to a good example and explanation of the Saff Squeeze.

After You Fix It, Break It and Fix It Again

Never leave a bug until you fully understand how you fixed it. You should be able to reproduce the bug and fix it again at will.

I can\\u2019t stress this enough. If you fix a bug and you\\u2019re not sure exactly what caused it or how you managed to fix it, that bug will come back to bite you at the worst possible time.

What About Those Instincts?

Now that you\\u2019ve learned these techniques, does that mean you should always use them first instead of relying on your instincts? No. Absolutely not.

What I recommend is that you give your instincts a time box in which to succeed. If you have a strong hunch about what the problem might be\\u200a\\u2014\\u200aand you can test your hunch quickly\\u200a\\u2014\\u200ado that first. If the bug is below the green line in the chart above, chances are that your instincts will be the fastest path to a solution.

Once you\\u2019ve quickly tried your first or second hunch and been wrong though, stop the shotgun approach and start doing things methodically.

Having both instincts and discipline will make you one of the top coders on any team.

To help you even more, I have put together a free PDF list of my five favourite code refactoring techniques\\u200a\\u2014\\u200athat lead to fewer bugs\\u200a\\u2014\\u200aget it by clicking the link in the original article.