{35} Build First, Generalists & Debugging
{35} Build First, Generalists & Debugging
Featuring Brian, Andrew Gazdecki, Julie Zhuo, Safeyah, and Harold Sinnott
Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.
Product Philosophy: Build First
Brian
This is my mood today. Stop worrying about all the bullshit you think you need to have in place in order to build. Just build.
You don’t need the perfect idea or someone to validate that it’s even a good idea. You don’t need a ‘win’. You don’t need the ‘right’ tools or all the necessary skills neatly lined up. You don’t need a framework, a mentor, a support group, a sabbatical, or a degree.
There are very few legitimate reasons preventing most people from getting started. Once you get the ball rolling, you’re halfway there. Then think like a captain of a ship. Think about where you are headed and the micro-adjustments needed to get there.
I agree with Brian, learn to love the journey. Getting to a nice destination is great, but you’ve got to love the grind.
Scaling: Specialists vs Generalists
Andrew Gazdecki
Hiring generalists as you create a startup and specialists as you scale is generally good advice. I agree with it in principle, but it is more nuanced.
What do generalists and specialists bring to the table?
Generalists discover opportunities – Generalists are able to combine knowledge from different domains in order to find new solutions. In other words, generalists are “innovators”.
Specialists capture value – Once you’ve got a solution validated by the market, specialists are better at refining it. As the solution improves, you capture more and more value from the market.
The problem with hiring generalists early and specialists to scale is you lose the ability to innovate. As the market evolves, competitors drive prices down, and needs shift. The well dries up.
It’s more sustainable to think about how you can maintain a team of generalists to continually discover opportunities. As solutions get validated, hire specialists to help scale. At every stage, you need a mixture of generalists and specialists. The composition should change based on product lifecycles.
As products reach the end of their lifecycles, they should go into “maintenance mode”. Reduce how much you invest in new development. Focus on performance, security, and stability.
Instead of laying off all the specialists who scaled the product up, shift people to new, freshly validated opportunities.
Team: Cross-functional Roles
Julie Zhuo
After my previous discussion about specialists vs generalists, I’d like to point out that nobody is purely a generalist or specialist. Even the most well-balanced generalist has specializations. And the most narrow specialist is not a one-trick pony.
This is a great thread by Julie that talks about the value of cross-functional roles in larger companies. Even with a high degree of specialization, I firmly believe that siloing people is bad. You don’t necessarily need people who are highly skilled at everything, that isn’t a reasonable expectation. But you do need highly skilled people who are focused on different problems to work together.
Oil Painting: Tips
Safeyah
Enough about building teams and just getting started. Here are a few oil painting tips by Safeyah. Watching artists manipulate color, light, and texture never gets old.
I’d love to see a redesigned coffee shop that functions like a colosseum where the gladiators are artists. Every morning people start their day by gathering in an open space to watch skilled people perform their craft.
It would be great for artists to get exposure in a community without the pressure to teach. Not everyone is a teacher. It would also energize and inspire the community.
Debugging: Flowchart
Harold Sinnott
I haven’t written Python in a while, but every programming language should have a debugging flowchart. I don’t know how often I’ve run into an error that makes no sense. I find myself pasting gibberish into a google search, desperately looking for a human explanation. This at least gives you enough context to narrow down most issues.
Looking at the error types, I have to say Python is reasonably intuitive. I don’t think I’d have a WTF reaction to any of error types in the chart. There are other Python error types I find less intuitive, such as a GeneratorExit.
Ultimately, programming languages should invest more in the developer experience. The vast majority of errors should be immediately obvious and recoverable within minutes of seeing an error message. A lot of progress has been made over the years. But we’re not there yet.
When it comes to debugging, I know of an excellent, top-notch guide for general debugging tips, tricks, and techniques. It's "The Pocket Guide to Debugging" by Julia Evans, available at wizardzines.com. I think it's geared towards more junior devs but there are some expert-level techniques in there that I wasn't even aware of until I read it. I'd highly recommend checking it out, and all of Julia's work for that matter.
I haven't always been a proponent of the "build first" mentality, but I agree with it wholeheartedly. Another way to put it might be "just do it". Or, as the Taoists would have it, "wei wu wei", which translates to "do 'not-doing'".
The latter may sound confusing, as a lot of the concepts in Taoism don't translate well. In my mind, "wei wu wei" generally means to act without attachment to outcome, to take action in accordance with your nature or instinct without pontificating endlessly about this or that choice or consequence. In that sense, I think it applies perfectly here.
I've been guilty of ignoring this principle at my own peril. As you know, I tend to pontificate and ruminate and navel-gaze quite a bit when it comes to getting things done, especially on new projects. I think tonight I'll do not-doing instead, and start my own newsletter.