#7 | Channeling the Customer
Until now, all of my projects have been intended for me with no intention of really sharing anywhere else. However, now that I’ve settled into the routine of building each week, I’ve been thinking that in order to meet my eventual goal of making money on a software project I need to start thinking about customers beyond myself.
With this goal in mind, I have started asking family and friends who have interesting jobs about how their industries work. So far I’ve learned about the business behind international imports, pharmacy, and temp staffing agencies. One of these conversations reminded me of a recent annoying anecdote in my own life where I was looking for some specific health information and couldn’t find it in the places I expected. When I brought this story to my pharmacist-in-training friend, he didn’t relate to it as directly himself but was open to the idea that it might be relevant for myself and others. That would make sense because he has highly specialized training in the field and doesn’t represent the average Joe like me who needs Google (or their doctor). Eventually my anecdote became the inspiration for this week’s project.
The story doesn’t end there though. While building the MVP, I realized that I’m not actually sure how common my customer story really is. As I saw already in Week 4 (meditation app), I have a hard time being both the sculptor and the marble at once. In the spirit of the book Principles by Ray Dalio, whose lessons I’ve been trying to apply: if I zoom out and get honest with myself, I can see a pattern where I’m able to convince people of ideas that get me really excited at first, and then later feel lukewarm on. That either means I’m getting too excited in the beginning, or too doubtful later. There may be a risk that I got over-excited in this case too.
This was an excellent realization because it highlighted a problem in my process until now: I haven’t spent enough time talking to customers to validate my ideas. So, this upcoming week, I’m planning to try exactly that. For instance, I could post on Reddit, DM people on relevant subreddits, or talk to my friends in real life. Having effective conversations with potential customers is probably its own skill that will take time to learn, but as far as I can tell, it’s one of the essential things I will need to do regularly if I want to achieve my goal of making money from a software project(s).
Here are the open questions I’m thinking about and will continue to refine:
Where can I find trustworthy and insightful people to talk to?
How can I figure out what real problems they are facing?
How can I confirm whether any of my current ideas would solve a real problem?
How can I make space for them to suggest their own ideas I haven’t thought of?
How reliable are they really at understanding their own problems?
(I may message you all on this list soon to set up 15 minutes!)
I have no clue how many days this experiment may take or how fruitful it will be. Talking to a couple people might answer all my doubts within a couple days or yield nothing after the entire week. It may completely disconfirm my current work-in-progress idea. If that’s the case, I will probably wrap it up quickly, just shipping something for the practice. Better to know now than after sinking in even more time.
I’m grappling with the realization that future projects may involve more stops and false starts. I don’t see a way around it right now, because:
I’m seeking to build things other people will value
I don’t know what other people will value until I ask them
It doesn’t make sense to build anything ambitious until I’ve gotten positive responses from them
I don’t want to give up the idea of “ship something regularly” as the deadline pressure has really helped me stay consistent and get things done. However there is tension between this and “ship something valuable” which requires more open-ended exploration of ideas. If you have thoughts on how to get the best of both worlds, I would love to hear them as an email reply or in the comments below!
If you don’t know the answer, then lucky you—you get to watch me figure it out and come along for the ride!
Developing Front-end with React
For this week’s project work, I didn’t think it makes sense to show much until I talk to more people as described above, so I’ll hold on to specifics and instead talk generally about the tech stack.
After writing my last UI (MotivationDashboard in week 2) in vanilla HTML/CSS/JS, I wanted to build this project’s frontend using a proper framework. These days, the dominant frameworks I hear about are React, Angular, and Vue. Based on some data I saw, it seems like React is the best combination of widely-adopted and widely-loved by developers. Most importantly, my roommate is a big React fan and sold me on it with his enthusiasm! I only scratched the surface of what React can do this week, but here’s a taste of the secret sauce that makes it so special.
State Updates and the Virtual DOM
In the “old” model, web applications used to be multiple pages of mostly static text/UI elements given dynamic functionality by JavaScript, styled by CSS, and connected by links. However, a new paradigm has emerged called the Single-Page Application (SPA). In this approach, instead of clearing the old page and adding new elements to a new page, we actually replace the old contents with the new contents on the same page. Not actually loading a new page can give better performance- once we load the initial page, we don’t need to hit the server again to get the next ones. But along with swapping all the content on the current page like during a refresh, there are also many cases where we only change part of the content. For example, adding a new product to cart on an ecommerce site and having it show up in a list- this shouldn’t require a full refresh.
React is so popular because it deals with the question of when and how to swap the content on the current page very well. Imagine that we build a shopping list web app and want to add a new item to the list. Now the data that’s shown on screen should be changed, and even though we only need a new child element to be added, maybe the browser would try to redraw the entire list container since its state technically did change. It turns out that refreshing any of the elements on screen is very costly, and if we can save time by only refreshing exactly what we need (the child element and everything underneath it which gets pushed down), the app will be faster.
This is where the Virtual DOM comes in. Your browser maintains the “real” DOM, which is like a blueprint for all the UI elements currently displayed by your website. React maintains its own “fake” DOM called the VDOM, which is much faster to update because it doesn’t actually cause the browser to re-draw what’s on screen. By first updating the VDOM and then comparing that against the DOM and figuring out exactly what needs to be updated, we don’t need to update larger chunks of the DOM than we intended to. It’s still a complicated process under the hood, but this is my 10,000-foot understanding of how the magic trick works.