Four Foundational Lessons from Solo Coding

A couple months ago, I spent four weeks grinding out the MVP (minimum viable product) for ‘iLobby’, the working title (that will need to change) for a tool to find and influence your elected officials.

• Here are some links: iLobby Demo Release | Video Demo | Github

It was, by a considerable degree, the biggest project I’d worked on to date. This magnitude was amplified by it being my first significant solo effort. I had some high highs and some very anxious lows. I pulled my first true all-nighter in 15 years! And, I came away with a lot of reflections on what worked and how to improve my process going forward. Here are four foundational lessons:

1. Design first
2. Name things well
3. Always known where you are
4. Leave time to complete

1. Design first

I built iLobby as my final project at the Flatiron School. We were instructed to spend at least two days simply designing before writing any code: user stories, interface mockups, database models, and (as we were all building in React) component hierarchies.

I leaned into these recommendations, using QuickDBD and Whismical to help with domain modeling and wire-framing. Each of these layers was a chance to think through the details of the project as a whole, adding successive layers to my thinking and understanding. (Like one of these old-school-internet progressive interlaced rendering jpegs.)

There were a lot of pieces to think through:

• There was all the data about elected officials and their districts: the need to grab that data from the Open States API and store it; the need to visualize and browse it
• And there was the user-generated data: users, campaigns, actions, call lists
• There were going to be filters by chamber, party, committee assignment
• There was going to be text-based filtering for names and district numbers
• There needed to be a relationship between filter results and the accompanying map of legislative districts
• There was going to be hover and click functionality for the map
• There was going to be full CRUD on four tables of user-generated data

By going through that whole process, and then pulling it all together as a slide deck, I had identified so many more details of my approach. The “Take Action” modal emerged as the hinge component that grabbed the correct API data and integrated it appropriately user-generated data. And, it became clear that the biggest questions revolved around the use of the Google Maps API.

By the time I started coding on Day 3, I really understood what I was building and had a good list of things known to be unknown.

2. Name things well

A mentor of mine says that naming things well (or ‘correctly’) is 80% of what it means to be an excellent engineer. From variables to methods, models, components and functions, there are so many elements that must fit within a coherent mental model, if they are ever going to work together properly.

Getting the underlying concepts right and selecting names that accurately reflect those concepts means that the more you wrestle with the code, the more you ingrain a proper mental model for yourself. (As well as for anyone else that might collaborate and contribute to your code base). The inverse is also true: incorrectly named elements tend to reinforce an errant understanding of what you are building and is itself a kind of technical debt that slows productivity.

In iLobby, SearchResultsContainer is the name of a very important React component.

I named its subcomponents with the prefix “SRC”, thinking that would help organize files, but it got deeply confusing. Moreover, that convention is neither transparent nor accessible to new devs. (The refactor is on my backlog.)

Similarly, there is a critical need to be technically precise: Rails (used for the backend) uses snake_case whereas JavaScript (frontend) uses camelCase. (More on string cases.) Places in the code where the backend and frontend interact (such as fetch requests and functions that feed data to them), had inconsistencies translating between these two conventions that caused some significant confusion. At some point, I refactored the most egregious examples and made a separate commit to handle all this, but there is certainly some left undone.

3. Always know where you are

Aka Always Pseudo-code

In some ways, this is a repeat of the first lesson: i.e. sketch first. It is so valuable to articulate the logic of a function before you start coding it for at least two reasons:

1. If you really zone in on a tricky piece of logic, when you finish and zoom back out, you know what you set yourself up to do next
2. Sometimes you realize the logic of your solution needs to change and it great to be able to document that and not simply need to keep it in your head

As I was developing the click and hover functionality for the maps, I started shooting from the hip. I’d check the docs for the Maps API, and discover a new way to try something out. But, before pausing to see what that did to my other assumptions or logical flow, I was starting to just implement in a new direction. (This was during the above mentioned all-nighter.) I wound up with contradictory hover and click logic that took a day and a half to untangle.

Pseudo-coding gives yourself a map and an enhanced ability to check your own logic for inconsistencies. In the long run, it is nearly always a time-saver.

4. Leave time to complete

Shipping is a lot of work

I am a perfectionist and I have trouble putting something down until I am forced to. As a result, I am used to working towards (and being motivated by) a hard deadline. However, having never shipped a project of this complexity before, I didn’t fully anticipate the number of steps it takes to really finish, even once you stop editing code.

There are steps with Git. There are Readme files to write. And, of course, there is the process of deploying a production build! All these things take time and, like anything in technology, introduce errors, reveal bugs, or simply present obstacles that need solving. In the future I will remember to respect this process of completion and allocate ample time .

Completing something big and significant and can be so gratifying. As always, one must find the balance between ambition and staying within bounds that will allow you to actually feel done (even if just for a little while!)