https://thezbook.com/code-first-vs-product-first/ Skip to content Zach's Engineering Handbook * About this Handbook * Code-first vs. Product-first * Multiply by * Host Interns * Coding + Make Small Changes + Use Feature Flags + Test Your Changes + Get Code Reviewed Early + No Unrelated Changes in a Single Review + Every Submit should make it to Head + Keep Working during Review + Don't Share Feature Branches + Use a Linter + Code Reviews + Presubmit Checks + After Submitting and Pushing * Planning + OKRs + Prioritization + The Real World is Messy + Week by Week - Sprints + Day by Day - The Daily Standup + The Perfect Process * Hiring + Startups vs. Established Companies + Hiring is a sales process + Who do you want to hire? + Branding & marketing + Writing a job description + The Recruiting Workflow + Referrals + Sourcing + Recruiting Platforms + Inbound candidates + External Recruiters + Internal Recruiters + The Pitch + Initial phone screens + Coding Tests + Technical Phone Screens + On-site interviews + Hiring Meetings + Reference Checks + Offers and closing Zach's Engineering Handbook Thoughts on Product and Engineering [IMG_1003-1] * Opinion Code-first vs. Product-first by zachlloyd * Published April 30, 2019 * Updated May 3, 2019 There are two kinds of programmers, generally speaking. There are programmers who care more about code, and there are programmers who care more about product. The former - I'll call them "code-first" programmers - are obsessed with how code is architected, what tools, libraries and languages are used, how much test coverage there is - stuff like that. Code-first programmers are psyched when they check in the perfect abstraction, when they get to use the latest language-feature, when they delete dead code. That is, they love the code they write - the code is the thing. The product-first programmer cares about that stuff too, kind of, but only as a means to an end. For product-first programmers, the code is the scaffolding, the support, the steel beams in the building, but not the end product. The end product is, well, the product, not the code, and what matters to them is how well that product actually solves the underlying problem. Does the building stay upright? Do the elevators work? Is the A/C functioning? Do people like being there? Product-first programmers love building and launching and seeing users use what they've built. The product is the thing. Anyone who has worked at a place like Google has met plenty of code-first programmers. They are the teammates who are always refactoring code and nit-picking spelling in your function comments. They are in the micro-kitchen complaining about "spaghetti code," "technical debt," and the lack of rigor in other teams' code review processes. They are probably not fixing bugs or launching features. You can probably tell I'm not a huge fan of the code-first approach. When I interview programmers I'm always amazed at how many of them seem to think the code-first approach is what I'm looking for. Trying to impress me, they ask: "What's your unit test coverage like?" Pretty close to zero; this is a startup. "Do you guys use hot new technology X." Not yet, no, how would that help us build the right thing faster? "Is there a lot of technical debt?" We will have to rewrite everything at some point, but it doesn't matter right now because we haven't even figured out the right thing to build. They have an understandable but fundamental misconception of what programming is all about. Programming is about building products that solve problems for users not about writing beautiful code for its own sake. And to be clear, this is true at all levels of the stack, whether your users are external customers, third-party developers, or internal consumers of an API. What matters is how the code works, not how the code looks. Does that mean that I encourage writing bad code? That I don't care about what technology we use or how the software is architected? Absolutely not - I care a lot! But I care because I believe if you make the right engineering choices, you will ultimately get to a better product. I recently had an engineer I'm managing ask me how his code was. I responded by asking two questions back: "Did the feature work well?" and "Did you build it quickly?" "That's what matters to me," I said. And typically, if the answers to those two questions are yes and yes, it's likely (although not certain) that the code was actually pretty good, because good product usually implies good code. By definition the opposite doesn't exist by the way - there is no such thing as good code that produces bad product. I call this my rule of good code: If the product doesn't work well, the code is not good. In other words, there is no such thing as good code in the abstract; good code can only exist if it's producing a working product (again, define product loosely here to mean product at any level of the stack). Over and over I see some engineers producing great product quickly, and when I see the code it's usually well factored and smartly built. It's not surprising since it's hard to quickly build good product in a complicated system with code that is poorly architected or factored or not tested. Conversely, when I see programmers not launching features quickly, the issue is often overengineering. Or when engineers do launch quickly but the quality is bad, then the issue is usually under-engineering or sloppy code. There's no zero sum game here: you should strive for good code, produced quickly, leading to great product. This is what great programmers produce. Image 2019-04-26 at 11.57.10 AM The best programmers I know are product-first, but actually have more coding knowledge than the coding-first programmers. They know when to use the chainsaw vs the hand saw vs the chisel. When you need to really get something right (usually the deeper in the stack you are) vs. when you can fake it and just move quickly. When it's better to just write a normal for-loop rather than a custom iterator. These choices and tradeoffs are what becoming a great programmer is all about, and the ultimate feedback mechanism is how well the product works. You may also like... * [tim-gouw-68319-unsplash] Host Interns April 28, 2019 by zachlloyd * Published April 28, 2019 * Last modified May 3, 2019 * [jo-szczepanska-1163258-unsplash] Multiply by April 29, 2019 by zachlloyd * Published April 29, 2019 * Last modified May 3, 2019 Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment [ ] Name * [ ] Email * [ ] Website [ ] [ ] Notify me of follow-up comments by email. [ ] Notify me of new posts by email. [Post Comment] Contents * About this Handbook * Code-first vs. Product-first * Multiply by * Host Interns * Coding + Make Small Changes + Use Feature Flags + Test Your Changes + Get Code Reviewed Early + No Unrelated Changes in a Single Review + Every Submit should make it to Head + Keep Working during Review + Don't Share Feature Branches + Use a Linter + Code Reviews + Presubmit Checks + After Submitting and Pushing * Planning + OKRs + Prioritization + The Real World is Messy + Week by Week - Sprints + Day by Day - The Daily Standup + The Perfect Process * Hiring + Startups vs. Established Companies + Hiring is a sales process + Who do you want to hire? + Branding & marketing + Writing a job description + The Recruiting Workflow + Referrals + Sourcing + Recruiting Platforms + Inbound candidates + External Recruiters + Internal Recruiters + The Pitch + Initial phone screens + Coding Tests + Technical Phone Screens + On-site interviews + Hiring Meetings + Reference Checks + Offers and closing About this Handbook This "handbook" is my attempt to document my way of doing things as an engineer, manager, and CTO. It's not necessarily The Right Way, but it's what I've found to be most effective so far in my career. It's divided into four sections currently. 1. Opinion == my opinions on eng and product 2. Coding == best practices on how to code, especially as part of a team; 3. Planning == how to product manage and plan a project; 4. Hiring == how to hire at startups. I'm documenting this mostly for myself. But maybe you'll find it useful too. You might also think my points are wrong, misguided, etc. That's great - I love feedback and very much consider this a work in progress. Who am I? I'm Zach Lloyd. I'm currently the founder and CEO of Warp, where we are building a modern Rust-based terminal. I used to be a Principal engineer at Google, running the Google Sheets team. Post-Google I was the Co-Founder and CTO of the venture-backed startup SelfMade, and the interim CTO at TIME. Email me at @gmail.com or send me a message on LinkedIn. Zach's Engineering Handbook (c) 2021. All Rights Reserved.