Public Learning

project-centric learning for becoming a software engineer

Week 6: A Recap

Trials and Tribulations

Last week I have hit a low point, there is no other way to describe it. I was way too hesitant with starting work on an actual code base and spent too much time trying to overcome perceived issues that felt like unsurmountable obstacles. I will not spend a lot of words on any excuses, but will instead present a few learnings about how not to start with a big solo project as a relatively inexperienced developer.

The Fear of Writing Code

Aiming for perfection seems to be an arch enemy of productivity. I felt that if I didn’t have a good understanding of my problem spaces, I would not be able to write good enough code. I was actually afraid of writing bad code (whatever that is) and it has stopped me from making progress.
There is no way to describe the absurdity of that fear. Andrew Hunt, one of the authors behind the Pragmatic Programmer book, once famously wrote: “No one in the brief history of computing has ever written a piece of perfect software. It’s unlikely that you’ll be the first." Especially in its first iteration, code is going to be messy. That’s what refactoring is for. I even noticed how many insights about my project only came once I started doing a small prototype. So why would I expect my actual code to be the perfect solution to all my problems right off the bat? It’s a dumb assumption, and let me tell you: it can seriously cripple any initial progress.

The Trap of Premature Solving

For a while now, there have been two elephants in the room that I know I need to address at some point:

  1. The choice of a data store for all API data and metadata.
  2. The possible separation of services.

If you now think “That doesn’t sound like it should stop you from starting” then you are absolutely correct. But it did. I spent an obscene amount of time just on the first point, trying to determine advantages and disadvantages of an SQL database compared to a NoSQL solution. And it’s embarrassing to admit that I didn’t even come closer to an insight: I’m simply not at a point right now where I can make a completely informed decision. So why not implement a database-agnostic interface right now, just throw a simple MongoDB store behind it and move on? I don’t have to write that part now, I can wait until I have explored more of my actual requirements and then rewrite that layer from scratch.

The Loneliness of The Long Distance Coder

Not having experienced guidance as a novice programmer sucks. Not even having a peer to discuss ideas and problems with sucks even more. The biggest value I see right now in a program like Launch School‘s Capstone is the presence of other smart students who might also be out of their depth but can provide motivation, insight and help to jointly overcome any problem.
There is nothing I can do to solve that issue, so I will just need to embrace it. There is at least a distinct sense of ownership that might arise from such a solo endeavour: every mistake is one I will learn from, every decision is reflecting my strength and weaknesses, providing ample opportunity for critical reflection. The finished project will be 100% my own doing and there is a strange comfort I can find in that. I am still incredibly proud of writing a small game over a year ago, so I can certainly draw motivation from the outlook of finishing an even bigger undertaking now.

What’s next?

I took the last three days off completely, because I felt like I needed to fully reboot my head. Coming back to work with a fresh mindset, hopefully having learned from the mistakes of last week, I can now start making some real progress. There will be code, a lot.
That’s why I will not spend any more time pondering on my flawed thinking from last week, but dive head-first into the uncharted territory lying ahead. I am confident to report more next week.



Time spent this week: 31.5 hours