I'm a co-founder of dev.to (this website), ask me anything!

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.

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.

🙄

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.

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.

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.

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.

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.

😃

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.

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.

I think the best way to get better at anything is to practice. Challenge yourself with new problems everyday and find people to provide feedback on your approach.

Here are some articles that might be helpful:
dev.to/maxpou/typical-javascript-i...
dev.to/arnavaggarwal/10-javascript...
dev.to/vincecampanale/revisited-a-...

✔️

I was drawn to DoSomething.org because of the mission: empowering young people to take social action. And with that, the people behind the mission. I was in a place where I had the luxury of choosing where to work and given that option, I wanted to work for an organization that was adding to the world in a positive way.

DS was run like a startup, so it honestly didn't feel that different. Our KPIs were organized around activating young people, and not 'revenue', so that was pretty cool. DS is also well-connected so we were able to pick the brains of a lot of smart people.

I thought I picked up CSS easily until I realized it was the worst.

Overall, I want to say I had a good bootcamp experience but I definitely adjusted my expectations a few times. While it was happening, I didn't feel like I had enough 'support' -- there were too many students and too few professors. But in hindsight, having less support forced me to self-teach which I think is the most important skill I got out of the experience. The ability to find, read and interpret documentation has been crucial to becoming a better dev. The bootcamp taught me how to try & fail and ask smarter questions.

Hi, Ben Halpern, thank you for your question. I had to look up the speed of Canadian freight trains. A class 4 train can go up to 60 mph, wow! And if you add on the runaway aspect, that's really quite fast..though not as fast as some high speed passenger trains. Well anyway, I'll interpret this as a compliment, even though I think we'd prefer to go at the speed of runaway passenger trains.

We're popular because of our community. We believe in sharing knowledge and ideas (the most important riches in the world!), and people on dev.to are actually nice and supportive.

Got a strange feeling of a deja vue. Can't pin it down right now, but I am sure I will... But let's eat that donut first. Or 10. 😉