I've been itching to write about something for a while now but alas no idea ever came around. That is, until NOW.
For the past two to three weeks, I've been building a side-project as a way to test my knowledge of React. It's been a great journey going from an idea in my head to a living, breathing website that you can interact with (Read on for the link). The project in question is a simple space-themed blogging website named Nova which I built with React and SASS among other technologies.
As I write this, I can confidently say that I'm almost done with the implementation of my original idea for the website and I'm proud of that. So, I thought it would be a good idea documenting a few of the lessons I learned in the course of building this project:
Features Always Change
Regardless of how hard we try as developers to figure out everything our intended app is supposed to be able to do, we always end up having to change our specifications at some point in order to accomodate the changing needs of the app. So it doesn't make sense to try to figure out all the details at the very beginning. Trying to do so only brings about unwanted delays in product implementation and may even cause said product to be abandoned by the developer because of overly complicated specifications stemming from such an approach.
Now, this is not to say that there should be no place given to thought and planning at the beginning of a new project, this is indeed necessary. I'm only saying that instead of trying to think through everything from the start, try instead to figure out the minimum set of features for the app (It could be as small as a single feature), map out a clear plan of action for implementing and rolling out said feature set and then proceed to build that out.
Doing this, will absolutely simplify your development process especially when working on sideprojects where you have no other person to keep you accountable and aid your productivity.
Mobile-first Development Rocks
For a really long time, I've heard about the importance of adopting a Mobile-first development approach to building web-based interfaces and I've also heard, how important it is to adopt it due to the fact that most devices on the internet are mobile devices. But honestly, I never really felt the need to try it out.
However, I fully embraced the idea and applied it to this project and I must confess that the productivity gains were almost unreal. Here are two reasons why I'd advocate adopting this in your own projects as well:
- Most of the styles you write for smaller screens will be acceptable for larger screens. Hence, you don't have to create so many duplicate styling rules as you would have had to otherwise.
- For the same reason, it's also way easier to create highly responsive and adaptive websites using this approach.
It's still possible to shoot yourself in the foot though, but it's far safer than the alternative and leads to greater productivity in the long run. Can't recommend this enough.
R.A.Y.C — Refactor As You Code
Waiting till the last moment to refactor your codebase into a readable and better structured format is a really good recipe for sleepless nights. I had to learn this the hard way.
So I can't recommend this enough ; Once done coding out a feature or a component or any other unit of logic or abstraction that you add to your codebase, do your best to refactor and clean out redundant logic before moving on to the next thing. This keeps your code DRY enough to be maintainable in the long run. Doing this, has two advantages:
- Codebase stays DRY and clear enough to be easily extended in future.
- You get to read your own code and reflect on ways to really improve it.
Be A Critic, Not A Cheerleader
Sure, you should always try to encourage yourself as you work on stuff as this helps you keep up your motivation. But, doing this all the time and without merit, will cripple your progress and only cause you to build shitty websites that don't actually work and are a pain to use.
To that end, always strive hard to critique your own design choices. Compare them with those of others if possible. Never settle for a design simply because it's convenient to implement.
If you have too much empathy for yourself, then seek criticism from a trusted external party with the relevant expertise to provide it. If it doesn't hurt, then there's a lot not being said. Trust me, doing this pays off.
Project Completion Is Key
Strive to complete your projects or at least, strive to get the app to a state where most things that a user can expect from your app can actually be done. Always try to fully provide, support and / or implement the minimum set of features that the design of your app suggests. Doing this, leads to better customer satisfaction which is your ultimate goal as a developer.
Conclusion
It's been really nice building this project as I've learned a ton of lessons many of which I've been able to articulate into the information presented above but some of which are still hovering somewhere in the recesses of my brain.
CAVEAT: I feel a need to state that I'm not 100% proficient in the practice of all the principles and lessons laid out above. It's still a work in progress.
Thank you 🙏🏿
If you enjoyed this, then please give me a heart and feel free to share your thoughts in the comments. To get more, you can connect with me on Github, Linkedin or X
Top comments (0)