On the Prowl: Lessons in Overcoming Traps
If you learn something, it wasn’t procrastination.
Lesson 1: This is hard, I don’t know how to do it, and that’s okay.
I used the Test-Driven Development With Python as a jumping off point for my project. While it wasn’t exactly a Django tutorial, working through the testing of Django helped tie all of the pieces together. Or so I naively thought.
When it finally reached time to deviate from the book and create my own code from scratch, I started looking for reasons to not get the crux of the site done.
Man, I need to find a nice color scheme and logo. I bet I could fix the padding on these Bootstrap containers. Does that corner look a little too rounded? If I put the button here, does it look more balanced? What if I make it three pixels longer?
With TDD, it took almost no time to get a functioning site and my self-confidence up, but the second it started to get more complicated, I couldn’t make any real progress. I started regretting choosing such a complicated project and doubted any skills I thought had. I didn’t want to work anymore.
To cope, I spent a lot of time “researching” which is code for reading a lot of articles that might not have anything to do with my project. One such article I came across was The ‘Hello World’ Fallacy. To keep it short and sweet: the ‘Hello World’ fallacy refers to the over-simplification of learning something new by giving the learner a quick accomplishment right off the bat so they think they can use this new tool or language easily and stick with it. TDD did that to me with Django and creating a simple ToDo list site. It literally looked like this:
But my site needed…a lot more and as soon as I started working on my own: my URLs got more complicated, my views needed to be changed with all sorts of authentication and requests, and I needed to create a custom User model which required changing the default Django configurations. For the first few days, nothing worked. Travis CI sent me email after email saying everything was broken (like I didn’t already know it) and it was a stressful situation, but once I understood why I was struggling so much, I was able to get past the self-doubt I was initially feeling and start turning out some working code.
Lesson 2: Any plan is better than no plan.
And so this spiral keeps going until you end up with a stack of sticky notes all over your desk and notebooks. Once you reach this point in your work, it’s time to sit down and revisit the plan:
- Phase 1: manually enter an Opportunity
- Phase 2: add notifications and alerts
- Phase 3: allow in-site querying
Now we can break down the problems and see where they stand in the plan.
I have to redesign the database because it doesn’t support a core feature. Now I have to redesign the code structure to work with the new schema and now I have to rewrite my tests to go with the redesigned code.
This technically matters for phase 2, but it’s harder to change a database schema once there’s a lot of code and data involved so it makes sense to get to it quickly. Top priority.
And the whole site just looks awful, I need to clean it up at least a little bit. Let me google some CSS.
It could be the most beautiful of sites, but that doesn’t matter if it doesn’t work. Just get the core work done first. Pass.
If I didn’t know what I wanted to accomplish and what the minimal steps I could achieve to get there were, I’d still be working on the design of my homepage (because I am really bad at design) instead of focusing on core functionality. Also, I know me and I’m much more likely to continue developing a site if it actually functions. So while I could have spent 124 hours on the design, I’d just have a bunch of links that go to “pretty” pages. Instead, I have a board with cards that can be moved around and a plain page where jobs can be added manually.
Lesson 3: Facebook is right. Move fast and break things.
Other than this being the motto for my life, it also applies to the way I already write code and it was the most comforting idea I could have discovered in my journey.
We’re all learning something new and while you’re learning a new language or framework or what-have-you, you will not produce the most efficient or beautiful results. As you learn more, you pick up the nuances, you learn more rules, you learn more theories and with this new found knowledge, you’ll want to rewrite your code so it looks better and performs better. It’s a great feeling to reach this point, but it’s also an easy trap to get caught in. In the beginning, you should be working hard to turn out a usable product with some rough code because it’s better than spending your time trying to clean and tweak everything until it reaches this magical level of perfection.
Does it bother me that my HTML template doesn’t follow the DRY principle? Yes, but it works and spending time learning more in-depth Jinja2 templating is not worth being able to get my cards to stay put after you move them. However, learning how to make more robust query calls with Django’s built-in ORM was worth learning (along with the database redesign) to prevent creating extra functions in my views file which would reduce readability and speed and prevent scaling. Eventually, you should go back and rewrite your code, but only if it doesn’t prevent your long-term vision. So it should really be “Move fast and break things in a thoughtful way. Not just recklessly.”