Hey, I'm Jess!
Here are some things that make me interesting, maybe:
- I am Taiwanese American.
- I like to rock climb.
- I studied piano in college.
- I went on tour with the KIDZ BOP Kids (not as a performer).
- I went to a coding bootcamp.
- I product managed at a nonprofit tech company.
- I co-founded dev.to
- I deal with operations.
- I code, mostly in ruby & JS.
I also kicked off our monthly progress report today, so if there's anything in there I can clarify, ask away!
Top comments (117)
What has been the hardest, most difficult, or challenging aspect of founding and running the dev.to platform? And what turned out to be much easier than you expected? 🙃
The most difficult --- remembering to give feedback! Sometimes I get stuck in the weeds and forget to set time aside to give feedback -- we have retros every Friday but even then we have a tendency to blow through everything quickly in order to 'get back to work.' I think positive feedback tends to get overlooked and we have a tendency to focus on 'what went wrong and how we can be better.'
We're getting better at it since we started doing Rose, Bud, Thorns at retro. A rose is something we celebrate, a Bud is a new 'thing' we're excited about, and a Thorn is something we need to do better at next time.
Must easier...making connections! People have been overwhelmingly supportive of dev.to and we've been given a lot of opportunities to talk about what we're doing, and have gotten a lot of great advice from people we look up to.
What dev.to feature that's not already in the works are you most excited about?
Whoops! Answered this below
But in short, I want to host office hours where devs can ask a programming/career/life question and know that there'll be another dev at the other end of the socket to answer it.
Would the mentor host be a dev.to dev or a community member? 🤔
Who is your favorite former coworker?
🙄
LOL!
Do you prefer top-rope rock climbing, or bouldering? Any tips for someone who likes bouldering but kind of sucks at it (can't get past V1s...bleh)?
OH MY GOSH, YES! Ok. I bouldered for a couple years and couldn't really get past V1s comfortably. I was still terrified of the height and always struggled on the last move -- it was super frustrating and I never ended up climbing consistently because of it.
This past year, I started climbing again...but instead of bouldering, I went for top-roping. I found a buddy in @angaither so she pushes me to climb at least once a week. Top roping has helped me focused on the actual climbing and not the fear. I feel a lot more confident in my technique and I have a much higher level of endurance because the climbs are so much longer.
Now that I'm top-roping consistently, bouldering has become a lot easier and the fear aspect doesn't play as much because those muscles have gotten stronger.
(so the tip is to add some top-roping into your routing!)
That's great advice! Thank you!
What's the hardest part about building a community?
Communities take time to blossom so we could never have a 'build it and they will come' mentality. We spent a lot of (enjoyable) time building relationships with early adopters and listening to their feedback. But the difficult part is being patient and thinking hard about which pieces of advice/feedback to take and which to move on from. So, the hardest part is figuring out what's best for the community. At the end of the day, it's all of you that make this work because our tech isn't anything to write home about.
Damn, really well put.
Biggest Achievement so far ?
Hm, I have a tendency to associate an 'achievement' with a certificate or badge, which I can't say I've really acquired in the last few years aside from graduating from a coding bootcamp.
But something I'm definitely proud of myself for accomplishing this year is venturing into public speaking. I gave my first talk at Write/Speak/Code, an awesome conference for women based in Portland, OR. It was exciting and nerve wracking to talk about dev.to (and your developer identity) in front of a group of incredible women.
Ms. Lee: How has dev.to changed in the last couple of months? What kind of workload does the PBJ have in these days with the increased userbase?
Also, what is the reasoning behind open sourcing dev.to? What does the company hope to/expect will happen when the codebase goes open source? Looking forward to learning how dev.to was built!
Also also, thank you for the must-read emails!
Let's see...well, we started doing AMAs 😛, but feature-wise we've added: reactions to articles (the unicorn reaction is up for interpretation!), notifications, a smarter home feed, and the ability for organizations to self-create their own accounts (we used to have to do that manually). Oh! And the #hiring board.
We're in a unique position where the community has the ability to build itself. When we open source, we hope people will jump in and start building out enhancements they want to see. We can make dev.to more robust, very quickly. We're also excited for our codebase to generally improve because we'll have more eyes on it keeping everyone accountable. We come from the belief that sharing work is what's best for the world and open source software is always the best software, so that's where we want to be.
Do you have any advice on attracting diverse candidates?
Yes! At the top of the funnel:
1) I'd focus on eliminating unconscious bias from job descriptions. There are a lot of articles and tools out there that can help with this.
2) List the job on platforms that care about inclusivity and have a diverse demographic (like dev.to!)
3) Promote the job at events that are also inclusive and diverse.
Reviewing process
1) If you have the resources, eliminate as much personal info from the each resume as possible. This will help prevent you and your team's own biases to get in the way.
2) Instead of reviewing resumes together, add your feedback to a form. This way, everyone on your team has a say on whether or not a candidate should reach the next level. Avoid group think.
3) Same as the above after each in-person interview. Have you ever been in a situation where you really liked someone but then a peer says they thought that person was a terrible fit? In that moment, it's easy to doubt your original opinion so giving everyone an opportunity to provide feedback without groupthink is crucial.
Also don't give up! Like any hard problem it's way too easy to say "welp, that was hard, but at least we tried".
What is the one feature (or initiative) you are personally passionate about seeing on dev.to that is not yet announced or built?
😃
Office hours and mentorship. We're planning to host office hours where devs can ask programming/career questions and know that someone will be there to answer them. We don't have the details sorted out so I can't really elaborate further than that, but that's the idea.
What are the biggest differences between a bigger engineering org and a "scrappy startup"?
More processes and more stakeholders with less change and less experiments. In my experience, decision-making takes a lot longer at bigger organizations. I've been told that a successful MVP is something that works 80% of the time -- but it's hard to take that mentality to heart when there are biz dev folks who really need everything to be running perfectly all the time, especially if the 'clients' will freak out if the padding on the user profile photo changes by 3px.
In order to not fall into that, scrappy startups should think hard about their boundaries/culture/relationships with stakeholders early on.