Plan first, then code

Dear new developer,

I thought this article was worth sharing, as it is a relatively inexperienced developer talking to newer devs. But as I read it, one piece of advice stuck out and is worth emphasizing.

Plan first, then code

Roberto Hernandez

This is fundamental. Unlike, say carpentry, where planning is critical because you waste material if you don’t, coding sometimes feels like you can “just start.” After all, if you make a mistake, you can delete the code and start over (as long as you’re operating on your own development environment, not production). Seeing what you’re building is satisfying, both to you as a builder and anyone else you share your work with.

However, “just starting” is a recipe for waste, if what you start is writing code.

The first thing you should do before writing a single line of code is understand the problem. Depending on the size and scale of the problem, confirming this understanding could be as simple as repeating the request back to the person who made it: “so what you are saying is you want me to change the button text to blue” and thinking through the ramifications: “that will work on form A and B, but what about form C?”.

Or it could be as complicated as writing up a specifications document with the proposed changes and architecture, getting feedback on it, running it by the appropriate people or committees, and getting sign-off from stakeholders, including executives and customers.

Then, after you confirm you understand the problem and proposed solution, plan on how you are going to execute against it. For a small problem, this could involve starting immediately by writing or thinking of a list of tasks to do, though often you’ll want to add it to a todo list or calendar to ensure this task isn’t lost among the sea of other tasks you have. For a larger problem, there may be cross team coordination required, so: meetings and documents.

After you understand the problem and have a plan for how to accomplish this goal, you can begin writing code.

Avoid jumping in and writing code because the time to feedback is long. Compared to what? Compared to text, images or meetings. These are so much easier to iterate. If you write some code to solve the wrong problem or address it in the wrong manner, you’ve used more time than you would have if you’d talked through the problem.

It is also harder to communicate concepts with code, especially with non technical colleagues. Even with fellow engineers, a diagram or conversation is an easier way to explain ideas than written code. I’ve often whiteboarded a solution in a fraction of the time it would have taken to prototype it. Code is more precise and you can’t handwave a problem away, but there’s lots of chaff around the germ of the idea in many code bases.

There are times when writing code is the right way to start, though. This is called prototyping and if there’s no way to gain an understanding of the problem by reading, learning, discussing or otherwise approaching it, write some code to explore it. However, be prepared to throw this code away, as it will be the equivalent of a hastily scratched note on a napkin.

I do want to emphasize that this understanding and planning process doesn’t always have to be heavyweight and formal. In fact, for smaller tasks, you may internalize this process and not even realize you are doing it.

Next time you are working on a small task, take a moment and think about how you break it up into even smaller bits of work: “ok, I need to add this form. Therefore I need a model and a view too, and what are the methods I should add to validate the input?”

You don’t need to produce documentation and artifacts for every decision, but you would do well to at least in your own head think through the tasks and the ramifications of those tasks. This will help you look around corners and see issues that may arise because of your solution. If you do, you can modify the solution, again, before any code is written.



Mistakes Are Forgiven, Hiding Them Is Not

Dear new developer,

We all make mistakes. Yes, this is not news, but it’s worth repeating.

We all make mistakes.

I have made them, you have made them, your boss has made them, the person you are interviewing with for the job you really really want and need has made them.

The one thing about mistakes is: never never hide them.

Now, that doesn’t mean you should hang every mistake out on your blog or your LinkedIn profile. Just because we all should tell the truth doesn’t mean you should say every sentence you think.

But the people who need to know about your mistake should. Who needs to know depends on the scale and scope of your mistake. If in doubt about who needs to know in a professional setting, ask your mentor, your immediate supervisor or a trusted team mate.

Don’t take your time to do this. When you discover a mistake, you should immediately do the following:

  1. Confirm it is really a mistake. You don’t want to be the boy who cried wolf. So avoid making a mistake about a mistake. Take a look at the mistake from several different perspectives.
  2. Think of a plan for fixing the mistake. This may entail bringing in other team members, depending on the severity of the mistake. It may entail shutting some things down so a mistake doesn’t get worse. There may be an immediate plan to fix the emergency and a longer term plan to prevent the emergency from happening again (perhaps using an automated test).
  3. Think about who is affected and the scope of the impact.

Finally, tell who is affected about the issue and the plan to fix it. This may in itself require some planning.

It’s very uncomfortable. When I was at a startup and was writing billing software for clients, there were times when I made a mistake. I remember one time when I had to email or call each customer whose billing I had screwed up. It sucked. But they understood and appreciated the transparency and honesty.

What is the alternative? Hiding your mistakes and pretending they never happened? This means that you don’t get to learn from them. Your users or boss may discover the mistake on their own and bring it to your attention in a far more unpleasant manner.

Making mistakes is fine (though try to not to make the same mistake twice). Hiding them is not.



What is fulfillment?

Dear new developer,

Stephanie Hurlburt tweets some amazing stuff. Definitely worth the follow.

Here’s an interesting post from her about fulfillment. From the post:

I threw myself at helping others and was absolutely shocked to find myself not really that fulfilled from this work. I couldn’t figure it out, was something wrong with me?! I upped the amount of people I was helping, started doing even more work– was it the wrong kind of work? I tried different kinds. Wasn’t helping others my mission? I felt dismayed and empty.

Sometimes what you think you should be doing is wrong. The post has some thoughts about how to tease out what you really want to be doing.

It’s always worth some time to think about where you are going. But it can be overwhelming. I asked my father about that once, and his advice was to pick one or two constants you wanted in your life and orient yourself around them. I have found that to be a great way dealing with the paralysis of choice that can affect you in modern society.