Sketching Before Coding: The Most Powerful Tool I Use as a Developer

Hi, my name is Matheus de Camargo Marques, and today I want to share a perspective I have on sketching things out, drawing over things, and how I believe that makes your life a bit easier—especially if you're a software developer.

The Problem with Jumping Straight to Code

We've all been there. You have an idea, you open your IDE, and you start typing. But here's the thing: it's not so simple. When you skip the planning phase, you often end up maneuvering your implementation around problems you could have spotted earlier.

The practice I want to share—the same thing I do—is to sketch. It's to actually draw something to see if anything comes out of it that we can put into practice.

A Real Example: The To-Do List

Let me walk you through a very simple project I worked on: a to-do list.

Step 1: Identify the Functionalities

Before writing any code, I wrote down what I needed:

• Create
• Delete
• Update
• List

These are the core operations. When we think of a simple interface for this communication, we'd have listing, create, delete, and update methods. Whether it's a module, a class, regardless—these are the functions we need.

But here's the key insight: one depends on the other.

Step 2: Define the Data Structures

I created a new data structure called a Task Folder (or Task List). Let me sketch this out using a simplified UML notation—it's not always the prettiest, but it's what I use to draft.

Task Structure:

• name: string
• description: string
• priority: integer

Task Folder Structure:

• name: string
• tasks: list of tasks

Step 3: Discover Dependencies Through Drawing

This is where sketching really shines. When you draw things out, you start seeing dependencies:

• The task folder is a list of tasks
• At time one, you create a task folder
• At time two, you create a task
• At time three, you aggregate it

We have an aggregation here—a type of aggregate. And we need functions to modify the task folder so it could accommodate a new task.

Beyond the listing and creating functions, we also need:

• Add task from folder
• Remove task
• Screen (handles printing the task folder)

Step 4: Identify Constraints

We also had guarantees to maintain. Every time we add or remove an element, we have to ensure the whole list always stays sorted by priority.

This is a restriction we discovered through the sketching process.

The Problem I Discovered

Here's where it gets interesting. During development, I discovered a problem I could have seen through the drawing if I had drafted it beforehand.

I forgot to include an ID.

But because it's a very simple problem, I didn't draft it. I let it slide, and I had to maneuver the implementation so it would work without an ID.

Why Does This Matter?

When we need to perform listing and removal functions, how do we remove an item? We have a bunch of items that don't have an ID. How do we do it?

The comparison I need to pass is this: to remove, just compare attribute by attribute—name equals name, description equals description, priority equals priority.

But if we had an ID, we could just compare the ID.

This is a problem I only discovered when I got to this part of the code. I could change the code to have the ID, but since I previously specified how the system should behave and omitted the ID, I'm following the rule I created myself.

Using Sketches as AI Prompts

Here's a modern twist: I can take all this draft and create a prompt for AI.

I need a structure called Task where it will contain the following attributes:
- name: string
- description: "string"
- priority: integer

Then I need a structure called Task Folder.
It is responsible for aggregating many tasks within it.
It contains the following attributes:
- name: string
- list of tasks: list

For the Task Folder module, it must contain the following functions:
- Add a task (the list must be ordered by priority)
- Remove a task
- Create a new folder from scratch

The AI can create or invent quite well from this point based solely on the description. But the form—the way you want the code to look—it might not know because you didn't specify. We can specify in a high-level language too, how this should behave.

The Feedback Loop

When I finish all of this with tests, I can provide feedback again:

Feedback: We should have made the ID part of the structure because it improves search performance and simplifies the search.

Because otherwise, if this task has more attributes, we have to keep updating the comparison criteria.

Why You Should Sketch

I'm a paper and pen kind of person. If there's paper near me, I'm going to write. And I keep writing. I write way too much on paper, and that's why I see a huge advantage in writing and drawing.

I have entire projects written out—all the drawings, all the diagrams. I'm still learning how to use computer drawing tools, but I'm much faster drawing on paper, making these specifications on paper.

Look at this—this is a screen layout, a design problem I was solving. This is machine learning code, the kernel. I even forgot some of it—it's been so long since I studied this.

But look at how much information piles up here.

The Bottom Line

As a developer, you really have to write. If only because you don't do anything just for yourself. When you go to specify it, put it in documentation, and it's already there—all laid out the way things should work.

Writing functions at the speed of your thought.

Whoever writes well, thinks well, and has clearer logic. Having clearer logic solves problems.

If you can explain the problem, you've already solved the problem.

So that's the tip I give: sketch a lot. Do a lot of drafting. Do a lot of drawing.

If they aren't teaching you this, I feel sorry for you. But I had to write a lot. I had a different kind of training. But today, I can't deny that the most useful tool I have is literally pen and paper.

What's your sketching process? Do you draft before you code? Let me know in the comments!

Tags: #productivity #beginners #programming #career