Tip #1: Rapid Prototyping and Avoiding Perfectionism (except for security)
Turning your ideas into code as fast as possible is perhaps the single most important thing you can do as a developer.
To me, perfectionism is the root of almost all productivity loss. That’s not to say however, that having high standards is a bad thing! It’s just that if you’re building an app and you constantly second guess every action that you’re taking because you’re worried about breaking something or submitting something that doesn’t look perfect, you’re missing out on all of the brilliant thoughts that could have arisen from simply ignoring those mental blockers and just doing what your natural instincts tell you to do.
Obviously, we don’t want to expose ourselves to security risks in favor of rapid prototyping but, this is why it’s crucial to establish basic guardrails for yourself against the most significant risks. This allows your creativity to flow freely and uninterruptedly. It’s a slippery slope though, so guardrails should be reserved for only significant concerns like protecting your APIs, databases and so on. Setting up security constraints is generally a more significant aspect of development for teams which is a long and complicated topic but I will say this: your development environment is truly a sanctuary!
Tip #2: Frequent Refactoring
Rewriting code and restructuring when things don’t feel right is essential to achieving optimal agility and control of your codebase. Without this, technical debt can very sometimes build up and your codebase can start to control you.
Whether you’re working with investors or corporate management, refactoring can often be deprioritized in favor of new features but, it’s important to a balance depending on the expected longevity of the project.
When writing books or speeches, there are almost always multiple revisions or editions. So why wouldn’t this apply to writing code? Well there are some caveats.
1) There is a point of diminishing returns if you keep rewriting the same thing over too many times
2) Rewriting the entire codebase from scratch does not mean you will build everything better the next time. Sometime learning how to work with and debug unattractive or buggy code can be better than just rewriting that code to make it work your own way.
Tip #3: Not Wasting Cycles on Unnecessary Pre-Optimization
There are many ways that this can happen but here are a couple:
Trying to reuse code too often or too early
This means avoiding building components for every little thing. The idea here is to write code in one file until you see a pattern (i.e. building the same few things ~4–5 times) then it makes sense to start componentizing. If we’re talking about building user interfaces, there are so many fantastic UI libraries out there to help you skip the need for building out your own fundamental components for simple elements like buttons. I recommend trying out either BlueprintJS or Chakra UI depending on the scale of your project.
Using unnecessary or overly complex frameworks or tools
I admit. When I first started getting into frontend development with ReactJS, I hopped on the Redux train and went full steam ahead. I did one project for a client and quickly realized that Redux has its place among large teams however, in my opinion, using Redux gets very cumbersome, very quickly when working alone or on small teams. On paper, these sorts of frameworks look very appealing for their theoretical value such as the allure of “doing what Facebook is doing”. In reality, it’s a valid reason to consider a framework or tool when you have as team as large and skilled as they do to maintain the code. The tech giants have open-sourced tons of fascinating and exciting toys to play with but, it’s important to consider if those toys were intended for your size and use case before fully adopting them.
As an alternative, I use MobX on every project as it 1) reduces the amount of code necessary to handle state management in React, 2) increases overall frontend output and allows for very rapid restructuring of your application if your application ever needs a facelift.
I hope this improves your programming experience. Happy coding to all!