We've all been there. You have an idea for a project or a feature and instead of just writing the first code that comes to mind, we sit on it...and sit on it some more...and some more...
It's a trap we can fall into but it's important that we don't. While it's critical to plan, you can easily end up in an analysis paralysis of some kind. As our previous beginner selves, we didn't have this problem. Likely, because we just didn't know the right way to build something, meaning any idea was exciting to us—so we always explored it. This intermediate-level trap is particularly evil because the more experience you have, the more ways you've seen an approach end up failing down the road, and the more hesitant you become. Just as it's much easier to shoot down an idea than to stick your neck out and support it, it's just as easy to do with coding.
We're hesitant (or even embarrassed) to write beginner-level code.
I can only speak from my experience, but when presenting progress to clients, product managers, editors, etc., it's much more important that there's something on the screen working than not. Even if it's slow or the code is bad. So always consider your audience and your next immediate step. At the end of the day, it doesn't matter how something is coded as long as it works. (Obviously, if you are writing code for enterprise-level production codebase, this doesn't exactly apply, but you get my point).
Here are a few examples...
This is the worst thing to worry about first. Don't Repeat Yourself is a solid mantra, but don't waste your energy on it early on a new project. This likely applies to beginners more than the intermediate/advanced crowd, but if your first thought is to repeat the same code 20 times to make something work, then do it. We've all done it. It's okay! You're smart enough to know that iteration and looping are possible, but maybe not sure how to make it work on your first try. Again, this is okay. It's not worth wasting your valuable focus time and creative energy on reducing the size of your code. Just get your idea out there first and get it to work. Your user isn't going to know that your code is 10 lines or 100 lines.
Recently, I was working on programmatically coloring a cartogram for the 2020 Democratic Primary that shows the status of the delegate allocation throughout the race (must be on an iPad or larger to view). My problem is that the JSON data structure I was expecting was a bit more complex than I would have liked for the method I was considering. Instead of worrying about data transformation, which can be time-consuming, but likely not a deal-breaker, I just created my own sample data in the most optimal way for my v1 prototype. It allowed me to quickly get up and running with a method for coloring the blocks on the map according to the presidential candidates. Quickly, I was able to visually show my work to the team and push forward.
Inevitably, the data transformation work from our API required some refactoring on the front-end, but at that point it didn't matter. The right people already signed off and were excited about the idea. While data transformation work may be impressive to developers, it's not something visual. Now, it's worth noting that you can seriously screw yourself by not worrying about data structure—my point here is that one of the skills we should be learning as developers is to know whether something is a deal-breaker or not. I knew that no matter how the data was structured, I'd have transformation options available to me and any refactoring on the client side would be possible.
This is a tricky one and my earlier point applies again—know whether something is a deal-breaker or not. Often, I write code to visualize data using d3.js. The first step is to load the data (usually JSON or CSV) either remotely or from a local file. Depending on the state of the data and how big it is, you may run into performance concerns. For example, you load in a dataset with 500k entries, and it takes 5+ seconds before you see anything on the screen. You've got two options here. Either you keep going and worry about performance later, or you make a determination regarding the right tools and methods. This is tough. I use data visualization as an example here because we generally have three options: SVG, canvas, or WebGL. If you choose the route where you worry about performance later and build a whole prototype with d3 + svg, you may run into a situation where you need to completely change your paradigm and maybe even the library. Maybe you need p5.js with canvas or two.js/three.js with WebGL. Your code would likely need to be rebuilt from scratch in that scenario. Again, this is tough. That's why it separates an intermediate developer from an advanced developer.
Know what tools you need for the job and know which approach is a deal-breaker vs. one that can be reasonably refactored over time.
So, just make it work and worry about refactoring later? Yes, but only when you can.