6 lessons to keep in mind when you code before you think
When you have an idea, you often just want to start coding. Your motivation is high, your idea fresh, your hopes are up. Taking extra time to start with fluffy little things like architecture or design will just hold you back!
Until the moment that you’re actually in the middle of working it out. Suddenly, your code is a mess, your design doesn’t make sense and all you’re doing is staring at your screen and wondering why you exist.
Your project just stays unfinished and you start the cycle anew with a new shiny idea.
As I’ve gone through this scenario multiple times, I can give you some tips and tricks to keep your project going for longer, and learning more.
And who knows, maybe your next project will be the multi-million business you might be aiming for.
Don’t think when exploring
Often you’re starting the project because you saw a cool new thing. Or you want to learn a new skill or library. And you connect that to something you also want to have or make.
This will mean that you will need to test it out first. And thus a lot of preparation is not useful yet.
When you’re exploring a new framework, learning should take priority over delivering.
You will be much more productive and successful later when you are able to spend the first bit of time getting to know the framework. Because you’ll be able to use what you learned afterwards.
So when your project goal specifically is exploring a new area, or at the very start of a project, just code and don’t think too much.
Architecture is much more important for large systems
Getting your architecture done before you have something is hard. You need to have a good idea of what you are building, how you will be building it and what tools you will use.
For large companies and mega projects, this is a good investment. They can pay a bunch of people to figure out what they want, and how to make it. But for individuals, and especially novices, this will be a large challenge.
The third reason architectural reason, is that fancy architectures are for larger systems. When you are starting up, and starting small, your architecture matters much less. And it should be much simpler than you think.
That’s not to say that you shouldn't organise your code well. But you get fat with some simple rules of thumb. Keep relevant code together in folders, use consistent naming, both of files and of code, and keep interactions one way and to a minimum.
Some aspects need thinking more than others
When you’re creating a full-stack up, with both a website and a backend, there is twice the work and twice the design to do. And the question becomes how to divide it.
If this is the case, this is my advise:
Think more about your user interface than your backend.
Your backend is flexible. You can change a bunch of stuff and nobody notices. You can deploy it anywhere, change it from self-hosted to managed to serverless and your user is none the wiser.
In contrast, your user interface and more importantly, the user experience, has much more impact on an early user.
The early adopters won’t care if the API calls are a bit clunky. But they will care that your design is inconsistent. They will care that they are not able to find the functionality that they are looking for. They will care that they are suddenly stuck on one page.
So if you can choose, choose to spend your thinking time on design and user experience and less on whether to choose Spring, Django or Rust.
Find a balance between learning and making
When you’re making something new, you can often choose between taking a well-established language or a new and exciting language. Or a broad framework versus a minimalist library.
For example Java with Spring versus Rust, Ruby on Rails vs ExpressJS or in my case Django vs Flask vs FastAPI in python.
For these old languages and big frameworks, the landscape is very well set. Many problems are solved out of the box, and else there are a ton of libraries. You can take a lot of work off your plate by importing those.
On the other hand, for minimalist frameworks and newer languages, these might be much less available. You might need to reinvent the wheel.
You need to decide how much of you value efficiency versus learning
You will probably be up and running much faster with the established framework approach. But you will have exactly what you want by making it yourself and on top of that, you learn a lot by doing it.
For example, for my latest project, I decided to go for FastAPI with ODMantic as I wanted to learn a modern Python framework and use asyncio.
However, using that combination, there was no good authentication framework I wanted to use. So I made one on my own.
From an efficiency standpoint, this is wasted time. Authentication is mostly a solved problem and does not provide much value. But I learned a lot, and now I have exactly what I want.
Make initial decisions on how fast you want to get up to speed, and how much you accept to go into predefined frameworks.
And you should never feel bad for taking a batteries-included framework, like Django or Rails. If Instagram can work on Django and Github on Rails, then whatever you build will also work perfectly fine.
Keep your initial goal in mind
When you’re working on something, you need to get your hands dirty. You will encounter challenges, large and small. And while solving these problems, you might forget what your initial plan is.
Once in a while, you should try to stop on the small implementation details, and zoom out to look at the bigger picture.
Every month or so, look back at your original goal and see if you are still on track.
If you wanted to learn a new framework, are you still working on that framework or have you meandered into other things?
If you wanted to create a new app, are you creating valuable parts or you getting in too deep on one very specific part of the code?
If you wanted to solve a problem for yourself, are you closer to solving that problem, or are you making it too complex?
Rework is inevitable
Even when you started by thinking everything through, you had your design, you had a fancy architecture, at some point things won’t work out as planned.
Even the best-designed systems aren’t resilient against changing plans or priorities.
And don’t think priorities won’t change because you are making the app by yourself for yourself.
You will run into technical issues, making you change your architecture somewhat. You will run into edge cases that you also want to support. You will run into problems you didn't foresee.
And that is no problem. Reworking is also an opportunity for redesign or refactoring. When you’re reworking something, you can leave it even better than what you imaged the first time.
The worst-case scenario is that you revert back to your previous work. But at least you learned a bunch.
It’s not bad to code before you think
Don’t get me wrong, coding before thinking is not a bad thing per see. I would even say it’s the best way to start on some projects.
When you want to learn, you don’t need to make fancy-schmancy architecture diagrams or designs (unless that is what you want to learn). Start immediately, get your hands dirty and learn along the way. The end result is not the project but the knowledge you now have.
Even when you are building something, starting with code can be a good idea. Especially if you are not sure where you want to go. Then you can adapt on the fly, and make it a bit better every time than from the start. And design over time tends to be better than upfront design.
The last reason to code before you think is that thinking too much might also reduce your motivation. You need to start quickly, so you can have results and keep your motivation up. Too much thinking leads to stagnation.
As long as you think before you release.
What did you learn when you were creating some of your own project? What did you find out when you were investigating a new framework or language? Let me know!
