Fullstack Engineering Mistakes to Avoid

I've been a full-stack developer in silicon valley from 2010-2020. In this talk, we will go over the top 10 lessons I've learnt in the past decade. Specifically, go over technologies/architectures that have evolved (some for the better, some worse) and some age-old principles that have proven timeless. We will go over different parts of the stack (frontend, backend, infrastructure). We will end by looking into what's to come in the future. By the end of this talk, you will walk away with some key mistakes to avoid, best-practices to follow and things to look for in the future.

Transcript

1. Fullstack Engineering Mistakes to Avoid https://pranaysuresh.com/ https://www.linkedin.com/in/pranaysuresh/ • Early Engineer @Tesla • tons of startup experience • a decade in Silicon Valley • MS CS from Georgia Tech • Currently Perfecting Checkout at Bolt!
2. Why me, why now? • Open source • Great mentors • Colleagues … time to give back!
3. Blog Post: Fullstack Engineering Mistakes to Avoid - DEV Community ‍‍
4. Top 10 1. CSS Specificity 2. Design State From Component Hierarchy 3. Backend Spaghetti to Lasagne to Ravioli 4. Postgres in Production 5. Move Slow, Test Things 6. Invest in Automation 7. Master Your Tools 8. MVP 9. Research-Backed Development 10. Scientific Debugging
5. 1. CSS Specificity Mistake: My CSS is not applying. I am going to use !important Lesson: Using !important should be reserved for special cases because they break the whole CSS hierarchy and force a particular style. Instead, learn about CSS specificity. Essentially, ID selectors > Class selectors > Type selectors
6. 2. Designing Component from State Hierarchy Mistake: I need to add this new state, I’m just going to put it in this reducer…hmm not sure why this reducer has all this other state…Oh well! Lesson: Mismanaged redux state can cause confusion amongst developers and lead to bugs. If you use react and redux to structure your frontend applications, then you may consider this visualization technique to build state and reducer hierarchies from the UI component hierarchy. ▪ Visualize the UI in a wireframe ▪ Visualize the State hierarchy to mirror the UI ▪ Build the reducer hierarchy to mirror the state hierarchy
7. 3. Build Backend as a Ravioli Mistake: How is this codebase organized? Maybe I can just add this file here seems like all other repository code lives here. Lesson: I have written all three Italian varieties of code. And honestly, I think mini-lasagna inside a ravioli is the way to go.
8. 4. Postgres in Production Mistake: Why is this query slow? I think Postgres is slow. I need to shard or I think it’s the ORM or maybe I need a different database Postgres is not working out for me. Lesson: If you run Postgres in production then you **are **dealing with slow queries, table locks, infinitely waiting migrations, errors. That doesn’t mean Postgres is no longer the right tool, it means you need to lift the curtain and see what’s happening underneath. Pgbadger: https://github.com/darold/pgbadger Explain Analyze: https://tatiyants.com/pev/#/plans/new
9. 5. Move Slow, Test Things Mistake: LGTM let’s ship it! Lesson: It’s better to be methodical and slow with little to no production bugs than to move fast and ship bad code. ‘ilities of a software system
10. 6. Invest in Automation Mistake: We hand deploy to staging and sandbox, ad-hoc. Production is also deployed by hand but once a day. Lesson: • Having a CI/CD system manage deploys means more predictable outcomes. • Software moves through the pipeline in a promotional strategy and ad hoc deploys are relegated to special circumstances. • This ensures the stability and reliability of the software you are shipping, which is the primary responsibility of an engineering team. peril and hound, https://circleci.com/
11. 7. Master Your Tools Mistake: Oh I need to find the interface for this implementation, let me just search for it. It used to be in this folder. Eh, not anymore huh. Let’s look there….let’s just ask someone. Lesson: It’s not just about the outcome of your code, it’s also about how efficiently you build software. Start with your Editor!
12. 8. MVP Mistake: I think the feature will be useful. I am going to use a distributed-fault tolerant-replicated-highly available datastore. I will also build a plugin-based architecture that will make this software super extensible. Lesson: Before building something ensure that it is the right thing to build. This is where MVP’s come in. • https://twitter.com/jopas/status/515301088660959233?ref_src=twsrc%5Etfw %7Ctwcamp%5Etweetembed%7Ctwterm%5E515301088660959233&ref_url =https%3A%2F%2Fpublish.twitter.com%2F%3Fquery%3Dhttps%253A%252 F%252Ftwitter.com%252Fjopas%252Fstatus%252F515301088660959233% 26widget%3DTweet • https://www.intercom.com/blog/start-with-a-cupcake/ • Occam’s Razor
13. 9. Research-Backed Development Mistake: I (engineer) think this is what we should build Lesson: Development should be preceded by strong research to back a claim. Conduct user research qualitative & quantitative
14. 10. Scientific Debugging Mistake: There is a bug. Hmm, I think it’s because of this code change. Let me look into this file. Or maybe its a memory issue. It can be a combination of both too. Lesson: As an engineer, you will be debugging problems with software whether as part of an incident or in your local environment. If not done via structured reasoning, debugging can be painful and slow. 1. Reproduce the error (Often some combination time, data, user, OS, debugger) 2. Observe the facts (thoroughly read logs, error traces, etc.) 3. Explicitly state the hypothesis in a logbook instead of doing it mentally 4. If you’ve identified a section of the program as being buggy, use a structured approach to narrow down the bug eg binary search 5. Test the hypothesis: Use logging, breakpoints, asserts 6. If validated, apply the fix and ensure no new breakages 7. If invalidated, redo steps #3 to #6
15. Bonus • Share learnings • Shape your own world • Meet people
16. THANK YOU!