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 strange as it is, we didn't have this problem when we were beginners. Likely because we didn't know the right way to build something. Every idea was exciting to us so we always just explored it without worrying. This new 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.
We stall because we're hesitant to write bad code.
I can only speak from my experience, but when presenting progress to clients, product managers, editors, etc., it's most important that there's something visual to showcase as quickly as possible. A prototype goes further than an idea. Even if it's slow or the code is bad. So always consider your audience and your next immediate step. At the beginning of a project it doesn't matter how something is coded as long as it works.
Here are a few examples to watch out for...
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. 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 it could be written in a more sophisticated way. 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 styling a cartogram for the 2020 Democratic Primary that shows the status of the delegate allocation throughout the primaries season. 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, 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. The first step is to load the data (usually JSON or CSV). Depending on the structure of the data and how large the file is, you may run into performance concerns immediately. For example, if 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 a critical moment, though. And I use data visualization as a specific example here because I've been down this road before. When visualizing data on the web we generally have three options: SVG, canvas, or WebGL. Let's say you choose the route mentioned above where you worry about performance later and build a whole prototype with d3 + svg; you may run into a situation down the road where you need to completely change your paradigm and maybe even the library. That could involve a major refactor—it may even require starting from scratch if you need to use a different library/framework more suitable for canvas or WebGL. Hmm, this is tough...
See? Just like that I've started worrying about the very thing I'm telling you not to worry about. That kind of thinking will always slow you down and get in the way of your ideation.
So might as well just make it work now. One day you'll be a better developer but you have to build more first. Get started and worry about refactoring later.
Did I get it right?Tweet to me @andrew_levinson and share your thoughts.