Spend more time designing, and less time spitting out code
Your success won’t be measured by lines of code, but by the quality of your work
It can be easy to get caught up in the number of lines of code you’ve written and see it as a form of healthy progression towards your end goal. However, it’s quite the opposite.
In the beginning, you’ll want to see some results or to get a prototype working so that you have something to show for your hard work. To that end, you will probably want to put together the first few ideas that come to mind and figure it out as you go along.
Don’t do this.
I’m also guilty of this type of thinking, and I’ve been slowly starting to realize with experience how dangerous this can be for a number of reasons. For starters, your code will be spaghetti, which no one wants to see or work with. If you don’t write good, adaptable & modular code, then you will suffer as you add more features. Getting from 0 to 1 will be easy, but every other step after that will get exponentially harder as you wrangle with preventable bugs and design limitations.
There’s always a good way and a bad way(s) to implement your idea, so take some time to think it all out on paper before you even turn on your computer. Draw out some diagrams on a whiteboard to illustrate how your application should flow. As you start thinking about how you want the end result to be, you will start realizing limitations and obstacles that you will need to work around. You may even realize that something is not possible, and will have to scrap parts of your idea or pivot, and it’s always better to know this going in instead of realizing after spending hours or days on writing futile code.
Think about the future, and possible additions or changes you may need to make or features you may be required to add. This will significantly impact your design choices. Once you have a final feature list (as well as reach goals), try to outline some major, high level classes and interfaces you want to use, and think about how you can use inheritance or composition to reuse code and keep your logic modular. More on this in another post, but the earlier you adopt clean code practices, the happier you’ll be!
Once you have an outline or better idea of all the code you will need to write, and how different systems will interact with one another, the nitty gritty will work itself out.
Don’t concern yourself with the minutiae when you embark on a project. Writing actual code will be like clockwork if you plan ahead.
That being said, there are (very few) times when writing spaghetti code is acceptable and perhaps even desirable. Think hackathons, urgent deadlines for proof of concept prototypes to show your manager, etc.
Sometimes you’ll need to get something to work, and work quickly, so it is understandable to rush through. But if you have the time, or any plans of using your code for longstanding durations, then make sure you take the time to design it well.
This is #6 in a series of articles intended to document my self-taught journey into the world of computer science. I’ll be sharing my experiences and tips that I’ve learned over the past couple of years. Check out #7, learn by coding, or have a look at all of my posts!
