The Daily Subset

Share this post

{35} Build First, Generalists & Debugging

www.dailysubset.com

{35} Build First, Generalists & Debugging

Featuring Brian, Andrew Gazdecki, Julie Zhuo, Safeyah, and Harold Sinnott

Dane Lyons
Feb 28
5
5
Share this post

{35} Build First, Generalists & Debugging

www.dailysubset.com

Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.


Product Philosophy: Build First

Brian

Twitter avatar for @thebrianto
Brian To "Creating Simple ChatGPT Guide 4 Writers" @thebrianto
Don't wait until you 'win' so you can build in public. People love the journey not just the outcome. So start building now :)
2:00 PM ∙ Feb 24, 2023
9Likes1Retweet

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

Twitter avatar for @agazdecki
Andrew Gazdecki @agazdecki
Startup building & scaling 101... Building: just make it work Scaling: make it better Building: get customers Scaling: retain customers Building: process is nice to have Scaling: process is mandatory Building: hire generalists Scaling: hire specialists
3:54 PM ∙ Jan 1, 2022
874Likes184Retweets

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

Twitter avatar for @joulee
Julie Zhuo @joulee
I've participated in too many conversations about the role of design / pm / eng to count. Of course there are differences. But every tech manager role, regardless of discipline, ends up converging at higher levels. What does this mean for you as a manager? Thread below 👇
4:03 PM ∙ Mar 25, 2021
660Likes106Retweets

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

Twitter avatar for @Aljabouri2
Safeyah @Aljabouri2
Oil painting tips I wish I knew sooner 🖌🎨
4:24 PM ∙ Feb 19, 2023
312Likes30Retweets

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

Twitter avatar for @HaroldSinnott
Harold Sinnott #MWC23 @HaroldSinnott
#Python Debugging Cheat Sheet #DeepLearning #MachineLearning #ArtificialIntelligence #DataScience #Cybersecurity #BigData #Analytics #AI #IIoT #IoT #5G #RStats #JavaScript #ReactJS #FutureOfWork #CES2023 #DataScientist #Linux #MWC23 #Programming #100DaysofCode #NLP #SDGs #Tech
Image
4:00 AM ∙ Feb 19, 2023
22Likes14Retweets

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.


Thanks for reading The Daily Subset!

5
Share this post

{35} Build First, Generalists & Debugging

www.dailysubset.com
Previous
Next
5 Comments
Austin Pocus
Writes The Pocus Files
Feb 28Liked by Dane Lyons

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.

Expand full comment
Reply
Austin Pocus
Writes The Pocus Files
Feb 28Liked by Dane Lyons

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.

Expand full comment
Reply
3 replies by Dane Lyons and others
3 more comments…
TopNewCommunity

No posts

Ready for more?

© 2023 Dane Lyons
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing