Hi CodeNewbie Community! Nice to meet you. I was a guest on this week’s episode of the CodeNewbie Podcast:
S15:E2 - How to code wi...
For further actions, you may consider blocking this person and/or reporting abuse
What is the one thing you wish you knew when you started your career?
When I had my first internships, I remember that I was really hesitant to push code. I'd meticulously self-review my own code dozens of times before pushing my changes, rewriting the same components in a way that was slightly cleaner or more efficient. I distinctly remember a conversation with a more senior engineer on my team that went something like this:
Me: "I'm not sure if this is going to work."
Them: "So push it."
Me: "What?"
Them: "That's the fastest way to see if it's going to work."
And they were right—there ended up being some corner case in production I never would have thought of, and no test would have caught. The only way to really learn was to put the code out there, potentially make a mistake, and learn. This isn't to say you should never test your code or try to refactor anything, but spending too much time trying to get something to be perfect is often a lot worse than calling it done and moving on to the next thing. Making mistakes is okay as long as you're learning, and so don't become paralyzed because you're afraid of making one.
When I was a scientist in a biochem lab we had a similar way of thinking.
There are times when you need to do a quick and dirty experiment to see if "it" works. Then there are other times when you need to find the precise answer.
Or put in EVEN another way...
"Do you need an answer right away?" versus "Do you need the right answer done to a high degree of accuracy?"
It requires a little artful thinking to learn which response is needed and when.
I think that's exactly right! A common saying at many tech companies is "done is better than perfect".
This is so inspiring & true! Thanks for sharing :D
Based on your work at Quora and observations of the current landscape of Q&A + social media and community, etc., what do you think is missing? If you could snap your fingers and change how some of these platforms work, what would you make different?
Moderation is such an important part of any community, and yet it's still an afterthought on so many platforms. Companies that are laser-focused on short-term growth might neglect moderation (if we ban users, then we have fewer users!), and people working on the product might not be fully empathizing with the experience of many people in the community. The bottom line is that it's still way too easy to be a jerk on the Internet and have a profoundly negative impact on someone else's life.
So, if I could change anything, I'd want to make technical and structural changes.
Quick, how many web frameworks can you name off the top of your head? Probably at least a few, right? Now, how many content moderation libraries can you immediately name? Probably none. The technical barrier to implementing ML-based moderation should simply be much lower than it is right now. It's certainly a hard technical problem, but one that's solvable. (And this isn't to say that ML is the only thing necessary to implement moderation, but it's a great starting point.)
Structurally, I wish more community products made strong content moderation a core pillar from the very start, as opposed to something that's tacked on at the end. Within organizations, moderation teams need to have a strong voice and ability to influence the product, which isn't the reality in many places today. Quora made moderation a top-level priority early on, and I don't think it would have grown to the same scale if it hadn't.
Thanks for the response!
What computer science topic do you recommend all non-CS major developers become familiar with?
I love this question! Something we focus on in the early weeks of CS50, Harvard's introductory CS course, is the concept of "computational thinking". Computational thinking is all about framing problems methodically and breaking down problems into logical sequences of steps (i.e., inputs and outputs). Developers naturally do this while writing code—a function, for instance, takes an input, performs some logical sequence of steps, and returns some output. But, learning to logically break down problems is a skill that can apply to any domain and help make anyone a better critical thinker and a better communicator.
For more, here's a clip from CS50's "Computer Science for Business Professionals" course! cs50.harvard.edu/business/2017/wee...
What would you both say to someone who is looking to hire the core team of their startup? What should they look for in co-founders or early teammates?
Hiring is really important, and also really hard :)
One natural challenge that someone making their first hires or looking for a co-founder might run into is that nobody has heard of your company or vision yet! So, it's really important to articulate a clear vision for what problem you're solving, why you're solving it, and how you're going to do it. Putting this together in advance of talking to candidates can make those early conversations be productive.
Along the same line, when designing your interview process, be deliberate and specific about what you're looking for at each step—"good code" and "culture fit" are not specific! Instead, think about what a successful person in the role would do. Maybe you're hiring for a growth engineering role, where iterating fast and experimenting are more important than perfect code, or maybe you're hiring for a backend infrastructure role, where stability and performance are top priority. When looking for a co-founder specifically, think about what your strengths are and where your gaps are, and look for someone to help fill in those gaps. Maybe you're a great backend engineer, but you don't have experience with products or design—looking for a co-founder with some of those traits can help create a more balanced founding team. It's important to build a diverse team with a wide variety of skills and perspectives so you're ready to tackle any challenge that might come up.
Then, design your interviews accordingly. In many cases, simply asking a whiteboard, algorithm problem isn't going to be high-signal, because that skillset might not have anything to do for the role you're hiring for. (In fact, that process alone will likely cause you to miss out on huge number of great developers.) Instead, create a process that's reflective of what that person would do day-to-day, so you can get a better picture of how they'd fit into the team.
Finally, communication is a critically important skill in co-founders and early hires, but one that's often overlooked. At a small company, things will be moving fast and constantly changing, and if the team can't effectively communicate together, it's really easy to end up misaligned or have things slip through the cracks. Make sure that you're able to collaborate well with anyone you bring on, whether through pair programming or brainstorming on a problem together.
what would you say to your past self when you were a beginner in the tech field, what are the mistakes you need to avoid, in order to increase your learning curve or progressing curve?