The Lump of Clay Problem

A trap I see many early career developers fall into is the "Lump of Clay" problem. You approach your application as though it was a single lump of clay, out of which you are going to sculpt the vision that you have for its user-facing features. You fixate on what your user can see, and the internal engineering of your application arises as a second order effect of the surface engineering. If you'll permit me to extend this metaphor maybe a bit too far, the problem with this approach is that once the clay dries it's very difficult to change without doing damage to the piece.

Reliable software is composed of many small, well-defined units of behavior. You're not sculpting out of clay. You're building a house. You don't build a house by starting with a house-sized lump of clay. You start by framing it out. Then you add the mechanical systems. Then you do the finish and trim work.

Think of your software first from the perspective of the framing and mechanicals. How do you need to store and manipulate data in order to achieve the user interface that you envision? Get familiar with the roles that various tools in your toolbox should ideally play. What kinds of logic should go into a router/controller method? How about into an ORM instance method? Where should you put the client logic for communicating with your server API? Generally speaking, what are the discrete tasks that your larger feature depends on, and how can you keep them as discrete and well-defined as possible?

This is a skill that will come with practice, and one that I'll explore a bit more in the next few emails.

Next Up:
What's your superpower?

Previously:
Fielding Interview Questions