Starting this blog to share a bit about what it’s like building things at a startup. This week’s topic: how we tackle problems as developers—specifically, the difference between experimenting and actually thinking things through.

More often than not, when facing with problems that are above trivial, but below unsolvable, the instinct is to jump in and start changing stuff. Sometimes that works, especially with front-end code where the feedback is instant. If you’re working on a demo or a throwaway branch, the risk is low, and you might even stumble into a solution. This extends to every subproblem: you may well-design the top-level solution, but when it comes to, say, loops, there’s a temptation to add or remove one from the index boundaries. Does that sound familiar?

What’s really bad in tinkering is the desire for the immediate gratification, and the exhaustion that waits if the experimentation isn’t successful. It’s like a gambling mentality: you guess, and guess, and guess, until you run out of chips. That’s the hidden cost. As well, on related topic - have you heard about the ‘mise-en-cuisine’ concept? It’s about having everything properly set up before work, or losing productivity. Or being distracted. In short, too much guessing is as bad for your productivity as the woes above.

So there’s value in slowing down. Taking a few minutes to understand the problem, sketch a plan, and think through options can save a lot of time. Old-school devs talk about coding with limited terminal access—guessing wasn’t an option. Some boot camps still have students write code on paper for the same reason. Even coding challenge sites penalize trial-and-error. There’s a great section in the book “Code Complete” that talks about how much time and effort you save by creating detailed blueprints before building a house. The same principle applies to software development.

Of course, experimentation is good for learning, but this article is about delivering results. So where changing stuff and seeing what happens works? First, with front-end code where the feedback is instant. You’re very much tempted to open the developer tab and assign CSS classes and values to a piece of your UI ‘by hands’, with your brain’s right hemisphere. Then, experimentation is great when focused to a really narrow subproblem. Experimentation shines when you’re, for example, designing am ORM. Open your database, start a transaction and tinker until you get your SQL right. This kind of tasks. With some insidious FE problems firing a related piece of code in CodePen or StackBlitz is an effective approach too.

Bottom line - try to know better not only the right tool for the task, but the methodology as well.