In this week's rant, the gang discusses Microsoft Connect(); // 2016 where Channel 9 premiered a video featuring our very own David Fullerton, George Beech, and Nick Craver in which they discuss SQL Server and how it impacts Stack Overflow Enterprise. Also, Microsoft has now joined the Linux Foundation; Google has joined the .Net steering committee; and Visual Studio is available for Mac. What?!? We are now officially living in the Upside Down.

Our Developer Story today is Jewelbots CEO (and friend to Stack Overflow) Sara Rey Chipps! Jewelbots (launching this week!) are programmable friendship bracelets designed to spark girls’ (and boys’!) interest in coding. Jewelbots are the first of their kind - an open source wearable device where kids dictate the functionality. Sara and Jay discuss the importance of making programmable things that girls are actually interested in instead of just taking a pre-existing product and turning it pink, as well as the challenges of actually making hardware. "Physics are real."

Additionally, we have a One-Minute Tech Review (it's the new Macbook Pro 2016 and Joel has a lot to say about that missing ESC key, among other new "features") and another installment of "Startup or Shut Up" where spoiler alert Jay actually gets one right!

This week's constitution question is: Is it ok to get a mechanical keyboard with loud "clicky" keys when you are sharing an office? This is called the Jason Punyon amendment, because of reasons. Post your answer to Twitter using the hashtag #stackoverflowpodcast, with either PRO if yay, or CON if nay, along with your explanation. Keep it short but convincing! The funniest explanation, whether on the winning side or the losing side, will be read on next week's podcast and win a fabulous STACK OVERFLOW STICKER. We also need new amendments, so tweet us your ideas and we could name an amendment after you!

Last week's winner, replying to the question "Should you be allowed to comment out code and check it in?" is @Joe_Stetch!

"CON, this dark road leads to being featured on an episode of 'Hoarders.'" - @Joe_Stetch

We will not have a podcast for the next two weeks because of the holidays, but look for us the second week of December.

Links:

Get your own Jewelbots: * http://jewelbots.com * http://www.target.com/p/jewelbots/-/A-51848933 * http://money.cnn.com/2016/11/17/technology/jewelbots-smart-friendship-bracelet/

Microsoft Connect(); // 2016

What I haven’t explained yet, and what remains a mystery to most developers I meet, is how we make money. I want to do this now not only to answer this frequently asked question, but because it’s my and Stack Overflow’s belief that being relentlessly open and honest with our community can be nothing but good. That extends to normally sticky situations like finances, and it’s why we’ve created projects like the Stack Overflow Salary Calculator to make our salary processes transparent.

Why We Make Money

For a little more context on the timing of this post: I’m the architecture lead for Stack Overflow, and I’m writing this just after our annual company meetup. Our meetup is an awesome time for remote employees like me because I get to see people I’ve never met in person before and discuss ideas. Endlessly.

It’s also a great reminder of why we do what we do and how we go farther when we work together. I’m coming up on 6 years of my life spent building what I consider to be the best resource developers have ever had. I love making it better, every day. But I don’t build these things alone. I am insanely lucky to work with some of the best developers, sysadmins, designers, managers, marketers, sales, and all of the people who support that in the world. I don’t build Stack Overflow. We build Stack Overflow.

I spent countless hours last week talking with many of these people, some of whom I’ve never spoken to before, about how we grow as a company. Much more importantly, we’re figuring out how to do it while being, for lack of a better word, honorable. I have high standards for how we behave, and I hope that’s reflected in what you think of Stack Overflow. I am extremely protective of our users. You can ask anyone who works here. It’s is my very strong belief that we have a built up a trust with the community that is not easily earned and is impossible to replace. I want to work for a company that respects that trust, and I do.

While this is a shared, company-wide belief, historically we’ve heard concerns about how we can both respect users and make money, or that the money is just this thing we do for our VCs or because we want to keep the lights on. We want to squash that perception. Sure, money is required for sustainability. But we’re here fundamentally to help users, and we exist because you decide to let us exist. That's why we've structured our monetization into a cycle that continuously improves the community, and doesn’t treat our product processes like some sort of resource extraction. How much money we make is a direct proxy for how much we are helping our users. We focus on maximizing how we help users in order to make a great business. Very few companies have done this successfully, and we take great pride in the fact that we’re one of them.

How We Make Money

Stack Overflow Talent & Stack Overflow Jobs

We help companies build their brand and source technical talent through our business products: Display Ads and Talent. These services in turn help developers find better jobs and also learn about companies in a way that is respectful to the user experience (no spammy inmail, no flash ads, etc.). We consider the developer experience in everything we do, which is what makes everything we sell as a company unique.

It’s a lot like questions and answers. Companies are asking for developers, and we need experts to answer the call. In order for this to work, we need people on both sides of the equation. The more companies and developers we have, the better and faster the matching we can do with developers and hopefully their dream jobs. For companies, we aim to match them with a handful of candidates that are an awesome match, not 500 candidates that barely match at all. This is where we can provide value. We want to optimize things. We don’t want to waste your time or a company’s time – there’s so much inefficiency here we aim to improve with the whole hiring process.

Our position is relatively unique because we can help both companies and developers at the same time. That’s not bullshit. I believe we can do this. I believe we can be better at it than anyone else. We’re already placing thousands of candidates in thousands of jobs, but there are many more thousands of jobs waiting for the right candidates right now. One step of improving that is our Developer Story. I helped build this because I think it’s an awesome way we can improve life over resumes and CVs. It helps developers show off who they are, the things they do, and (I hope) in an approachable way that’s maintainable. It also lets you find a job. If you’re looking, or even just curious, the more complete your Developer Story is, the better chance we have of matching you to the right jobs.

If you have no interest in either, that’s perfectly okay too. While we’d love to help match you to a perfect company, we built both Jobs and Developer Story to support our core mission of serving ALL developers, including those of you who just don’t care about job searching right now. We’re working to change how companies treat developers not only through the standards built into Jobs (e.g. no spamming allowed), but also through our Developer Hiring Blog, which we created for the express purpose of improving employer and recruiter practices. And with Developer Story, we want to change the perception that developers are only as good as their last gig or a title. Developers are creators with stories to tell, whether that’s through code or blog posts they’ve written or individual teams they’ve served on or even what they’re reading right now. These products weren’t just launched to hit a bottom line; they were built to shift paradigms.

Stack Overflow Ads

We’re a major website, and our ads solution is a major player in how we survive. But we don’t want you to click on something you don’t care about. We want to give you something you want.

Our goal is to give you something as relevant as humanly possible, and when that fails we’re trying to give you something as relevant as this sentient computer over here thinks is possible. I’m not sure if giving it feelings was a good idea, but we’ll see. Anyway, we’re constantly working on it. It’s our job to make the ads we need to survive also be as relevant to you as possible. We have brilliant people working on this, and a large part of it is all after an overall goal: understanding developers, so that we can serve you better.

(So, how do we feel about ad blockers? We don’t care, and here’s why.)

What are we doing with ads now? In short, we’re not adding more ads; we’re just improving what we have. We have a little more smarts about what technologies you, as a developer, like than most places do. We want to see what we can apply there to make ads always more relevant. It’ll take a little longer, but we also want to make ads load faster as well – that’s a bigger project.

What we’re not doing is lowering the quality of our ads. Did you know we have a lot of unpaid inventory on Stack Overflow every month? Every time we display a “house ad” (which is what we call an ad for another site on the network) or a “community ad” (voted on by the community), we could display a paid ad. But we don’t. We don’t because if we don’t have anything even remotely good to show you, we shouldn’t.

And we don’t want to use an automated system that selects some ads for us. We looked at this. It didn’t allow us the control we required to maintain the level of quality we want to maintain. We have intentionally left a lot of money on the table. Sacrificing quality is not what we want to be known for. We believe there are better ways.

It’s important to know that the rejection of ads we could be selling came from our ad sales team. These are the people actually making money from selling ads. And they rejected the idea because they care more about what we’re doing and what you think of us than earning more money for ourselves. Do you have any idea how fucking rare that is? Our Talent sales team that faces employers behaves the same way. All of these people care about something bigger than themselves, and that’s why I love working at this company.

We have a few ads that are loading slowly (thanks for the reports, meta users!). We’re tracking down the advertisers and figuring that out, helping where we can. That’s a complicated one due to how many people are involved, but we’re on it. Samo and I will be adding timing information to our sampling profiles for these items, so we can keep an eye on them in the future and alert on issues automatically. We believe ads that load slowly or are expensive diminish the user experience. Performance is a feature and anything on the page matters to us.

I’m working with our ad sales team to ensure starting in January 2017, all of our advertisements will be HTTPS compatible. This is mostly the case today, but not guaranteed, and in the future we’ll enforce this. I don’t want them to be a blocker for anything. We’re about to move all Imgur images to https://, and enforce it. I’m also about to move all site logos and icons to https://. We’re working on that huge project… but that’s another (very long) post.

Enterprise

We’re going to spend more time developing Stack Overflow Enterprise. It’s starting to gather steam, and it’s another way we can help developers behind company firewalls and our company at the same time. We have a few full-time people on this to make it happen. Enterprise environments are somewhat unique and need some specific love.

But, Enterprise is the same code base as stackoverflow.com. It’s the exact same git branch. And sometimes features for Enterprise are features for public Stack Overflow. For example, we’re looking at building a simple image proxy needed for HTTPS that’s just useful as an inside-the-firewall image host on Enterprise. Those client timings I mentioned earlier? Those will help us gauge bandwidth required for this adventure. It’s one big picture we’re building.

Trust

Making money at a company our size requires great marketing.

But two years ago, I didn’t trust our marketing team. Why? Because it was brand new and I didn’t know them. I knew of other marketers and I had bad experiences. So my default assumption was roughly “all marketers are bad and want to abuse user trust for quick wins”. But it turns out that’s not true. Not here. I had to work with our team on several projects to overcome that prejudice and realize something simple: we hired some awesome marketers and they care about the same stuff I care about. Especially to Kaitlin, thanks. Our new team has put up with a lot of pushback and not fought about it. They showed us why these things are a good idea, and they convinced the smartest people I know on so many things.

All of our teams know that the Stack Overflow community and its trust is the most precious resource we have. We want to communicate, not alienate. And only with users we think we can help. Yes, if we’re doing it right, sometimes these things will help us as a company too. I don’t see that as a bad thing. If we can grow the company, we can build more awesome things for the world. I have so many, so many things I want to build for you. Ask me about sticking Stack Overflow in a 2U server in Europe, Asia and South America to beat the speed of light sometime.

I saw a presentation from Adrianna (our relatively new CMO) that blew me away. I hadn’t actually met her before her talk at the meetup, but it was a hell of a first impression. They have some awesome things in the works to help us with a unified brand. While watching her present, there was a lot of “why the hell didn’t we do that four years ago?” going through my mind.

Marketing, like development, is mostly about connecting the dots. I have gone from dreading interactions with “the marketers” to looking forward to them. We’ve got smart, well-intentioned people who can really help everyone involved. I’m actually psyched now.

Mini Case Study in How We Build Trust: Email

Trusting each other and sharing values related to how we make money directly connects to how we build internal tools. Here’s the most recent example I can think of how trust is a required feature in all our products:

So that Architecture team I run? We’re the team that coded a new email system to communicate with our users in a consistent way (with a lot of help). Why am I saying this? Because I personally went from 100% opposed to ever building such a thing to being onboard... if we did it right. By the way, it’s just me and Samo Prelog. “Team” is a pretty strong word. It’s kind of lying at that level. Should we call it a pair? We’re really just two developers forming a miniature Justice League. ...anyway, email.

What’s the first thing I specced? Opt outs. That’s the very first thing we built. That’s absolutely the most important feature to us. One-click unsubscribes and a landing page for that where you can opt out of everything was non-negotiable. It’s priority #1. I’m a developer who deleted their LinkedIn account over spam years ago. If you don’t want to hear from us again, that’s just fine. I’m sorry if we bothered you in the first place and appreciate any understanding of where we’re coming from. One of my biggest apprehensions is annoying our community. Worrying about that keeps me up at night.

We are in the process of sending out an email now announcing Developer Story to the larger community in the hopes that we can help some percentage of developers. If that email is rejected, we’ll unsubscribe you. If you’re unresponsive to emails we send, we’ll unsubscribe you. If you mark it as spam, we’ll unsubscribe you. We want to be a good citizen here. Every new email, except for transactional emails like “Forgot your password?”, sent through this system will have three links at the bottom: a one-click unsubscribe, a direct link to manage all categories, and feedback.

One of the reasons we built this system the way we did (which required a lot more effort) is that if a given provider didn’t work out (we’re using SendGrid right now, so far so good!), we could be damn sure that your opt outs were carried over. We didn’t want to risk annoying users who clearly tell us they’re not interested.

While we only have one category at the moment (“New Features”), we plan on adding more. But, I’m not talking about adding new email in that. We want to move all of the existing emails like community newsletters (a completely opt-in thing, if you’ve never seen them) over to this new system so you can manage it all in a very simple way, with a one-click unsubscribe we know works. Our email preferences page is, to be blunt, a total disaster.

This is an old artifact of growing from one site to many and it needs love. We have people working on that right now. One of our designers, Donna, is working hard to tremendously simplify this. There’s a lot of backend changes needed to support that unification and simplification. We hope to have one email address for a user and a single place you can manage all email that ever comes from Stack Overflow. If you are annoyed, it must take (at most) one to two clicks to unsubscribe from everything.

All communication and interaction has to reflect our respect for you. If it doesn’t, we have failed you, and we have failed ourselves. Our mission is to improve life for developers. When I lose sleep, it’s often over worrying about this. We have to deserve your trust; we have earn it.

If we add new categories of emails later (not just categorizing something we send today), existing users will not be opted in. Only new users will get defaults. We don’t want to be “that site.” I mean it. We intentionally designed the table schema around this.

If you read our Developer Story email and don’t want one, that’s absolutely fine. I hope Stack Overflow serves you in other ways, and I appreciate your time. I hope other things like Documentation and ongoing Q&A improvements help make your life easier. It really is why we’re here. It’s why I’m here.

How We Think About What’s Next

There are so many things in my head right now. I want to put a time series database in SQL Server in a Clustered Columnstore. I want to test an idea we came up with at midnight to improve consumption of developer news. I want to build several data connections that are almost there for our internal teams to save them time. I want to do a thousand things.

I’m also excited. I’m excited about the future of Documentation. I’m excited about Developer Stories. I’m revving to go. I want to get the money part of being a company out of the way so we can build all the useful things our communities want and need. I know we can do that, and in a good way for everyone. I hope you agree. I hope my ramblings helped out what it’s like at Stack Overflow, at least a little, at least for me. If we don’t agree, that’s just fine. If you have time though, I’d appreciate if you told me why in the comments so I/we can do better.

Thanks for listening.

Joel actually doesn't have a rant today. gasp Instead, we chat about our annual company meetup, which took place this year in the sometimes sunny Philadelphia. The gang explains why getting everyone together at least once a year is so important in such a heavily remote company. Hint: it's mainly to assure Jay to his face that no one hates him.

One of the coolest things to come out of this year’s meetup was a Tiny Talk by Stack Overflow developer Bret Copeland titled "How to Land the Space Shuttle… from Space" that has gotten over 87,000 (as of 11/14) views on YouTube. He wears a flight suit and everything…

This week's constitutional amendment question (along with way too much talk about stickers) is: Should you be allowed to comment out code and check it in? Jay (tries to) explain what this means while Joel and David try very hard not to laugh. Post your answer to Twitter using the hashtag #stackoverflowpodcast, with either PRO if yay, or CON if nay, along with your explanation. Keep it short but convincing! The best explanation, whether on the winning side or the losing side, will be read on next week's podcast and win a fabulous STACK OVERFLOW STICKER courtesy of the Stack Overflow Podcast.

Our very special guest today, with her Developer Story, is Fereshteh Forough, the founder and executive director of Code to Inspire, which is celebrating its one year anniversary this week! It uses technology, education and outreach to support Afghan women in their fight for social, political, and economic equality. In 2015 she founded Code to Inspire, the first coding school for girls in Afghanistan, with the mission of educating Afghan women with in-demand programming skills, empower them to add unique value to their communities, and inspire them to strive for financial and social independence.

"During my life journey, as a student and as a teacher in computer science, I definitely felt that there is a huge educational gap... We had students that never touched a computer and didn't know about a keyboard or mouse… Now they are at the level where they are developing a responsive website. So it's amazing to see how resources and providing this situation for women can really change their lives." - Fereshteh Forough

Thanks and see you next week!

Notable Links:

• Code to Inspire - 1 Year Anniversary Celebration is happening Friday 11/18 in NYC! Sign up HERE if you would like to attend.
• "How to Land the Space Shuttle… from Space"
• One-Minute Tech Review: Kayak Trips
• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

Starting today, you can expect...

• Better filtering options: Developers can now filter by technologies, salary, experience level, company and industry.
• Faster search engine: When a user runs a search or performs an action, only specific sections of the page refresh, saving a second or two per action.
• Stronger and more specific job alerts: More filtering options allow developers to conduct better searches and set more specific job alerts.
• Sorting by best matches and salary: You’ll see the best matches at the top of your search results by default. You can also sort by salary and newest.

Match Your Stack, Match Your Experience

Work with what you know best. Our new technology filtering lets you to view jobs with tech you want to work with and exclude jobs with tech you dislike.

You can now also filter by range of experience (e.g. student, junior, mid-level, senior, lead, and manager).

Money, Money, Money & More

We believe job seekers should be empowered with as much information as possible when looking for a job – especially salary. It’s why we built and are always improving our own salary calculator. And it’s why we want to put salary filtering up front for search. Salary filtering lets you set a minimum annual salary and choose among ten currencies (USD, EUR, GBP, CAD, AUD, INR, SEK, PLN, CHF, DKK).

Want more than just cash on hand? Look for other things to sweeten the deal with our Perks filter. See which job listings offer remote work, visa sponsorship, or relocation.

Companies You Love, Companies You… Don’t

Our new updates allow you to see specific companies (like Stack Overflow) with open jobs or to exclude certain companies. You can also filter by industry.

Get Alerts For Perfect Fits

Along with all these new and improved filters to help you suss out specific criteria, we're also giving you a way to set very specific job alerts, which you can receive daily, and match alerts which you can receive weekly.

Find a Job You Love Now

Curious? Want to try it out for yourself? Head over to Stack Overflow Jobs now to search, filter, and create alerts.

Got questions? Leave comments for us on Meta. Our community's feedback is at the heart of what makes our products like Jobs better, faster, stronger. <3

Welcome to the Stack Overflow Podcast #93, recorded October 25 in our New York City offices. This week’s episode is brought to you by the Society for for Responsible Use of Jack-o-lanterns. Did you know that jack-o-lanterns are the leading cause of smashed pumpkins in this country? Do your part, and say, “Jack-NO-lanterns!” to Big Pumpkin this holiday season.

In this week’s podcast, Joel tells a scary story about the time he crafted an easter egg for Juno email, and then deviously hid it in the build server. Does the steady beating of the easter egg’s hideous heart give him away? Huddle closely and listen carefully, boys and ghouls, to hear his fate.

It wouldn’t be a successful Halloween special without something dying. This year, the victim is the Experts Exchange paywall - as of this month, it’s been taken down and is gone forever. Joel, David, and Jay discuss while dancing on its grave.

Additionally, we’ve long suspected that our studio was haunted, and during the recording of this episode, we experienced what we thought may have been a poltergeist at play: At the start of Joel’s One Minute Tech Review, the table started vibrating… although in this case it turns out to just have been David’s phone, which he forgot to turn off. While we didn’t ask, we assume the caller, a recruiter from a startup looking for a new VP of Engineering, will understand that we recorded her and David’s conversation to share with all our closest friends and listeners. Fair warning: things get dark in this segment.

As part of our on-going series, Developer Stories, Genius.com CEO Tom Lehman stops by to talk to us about his journey as a programmer and founder. Tom, aka Joel Spolsky’s own Annie Wilkes superfan, has spent years learning everything about Joel, and wants him to never stop writing. Ever. Tom tells us how he went from making such projects as BetterMetroNorth.com to Genius.com. He also sets Joel up for a classic Shakespeare hip hop joke, which you get the pleasure of hearing over and over again.

Regardless of whatever spooky things may be going on in the world, we continue each week to build our Stack Overflow Constitution. This week’s question: If somebody drops a scrap of paper on the subway and they don’t notice, do you tell them?

Tweet your answer, pro or con, using hashtag #StackOverflowPodcast for the chance to win a nifty Stack Overflow sticker. And if you have a question of your own you’d like us to use in building this constitution, tweet @stackpodcast. If we like your suggested amendment, we’ll share it on the show and name it after you.

Last week’s winner for the question, “Do you hold the door for a colleague if you know it’s going to make them run?” was…

“Pro. Not only am I being polite, I'm helping improve their health.” - Andrew Bickerton, @coder4hire

Please note: We’re taking a one-week break from the podcast and will resume episodes on November 14.

Notable Links:

• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

In this episode, you’ll learn how to identify fake New Yorkers from real New Yorkers by simply asking, “What is Gray’s Papaya known for?” You’ll also learn how many licks it takes to get to the center of a Tootsie Roll Pop. Finally, you’ll learn a new word: Recruitersplaining.

Launching this week, Startup Or Shut Up, our new game where Joel, Jay, and David have to guess which one of three startup descriptions are fake. Spoiler: Jay gets a participation award for “trying.”

But what really grinds our gears? This week, the gang rants about awful recruiter questions and responses, specifically from Google's (alleged, possibly outdated) "Director of Engineering" hiring test, such as

Recruiter: Why is Quicksort the best sorting method?
Interviewee: It's not always the case, nor even suitable.
Recruiter: Quicksort has the best big-O.
Interviewee: "big-O" ignores data storage latencies, topology, volume, available memory, and even the computational cost of every CPU instructions involved in a given implementation – instead, it merely counts the number of algorithmic operations! Big-O can be a valuable indication when designing algorithms but the best performing and scaling solution depends on the particular constraints of any specific problem and environment.
Recruiter: Wrong, you had to give me the Quicksort big-O score.

Aside from listening to the episode, if you want to learn how to do interviews the right way, go to Joel on Software and check out The Guerilla Guide to Interviewing.

More important that interviewing, however, is our future legal system. As you all know, we’re preparing the Stack Overflow Constitution week by week, amendment by amendment in this podcast. This week’s amendment: Should you hold the door for a colleague if you know it's going to make them run? Go to Twitter and use #StackOverflowPodcast to vote Pro if you hold the door, and Con if you don’t.

Notable Links:

• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

In this episode you can learn way too much about the New York Transit Museum, the word "Stack" at Microsoft, and the etymology of Channel 9, where Joel was interviewed last week with the help of gender neutral robot cameras.

We have two new segments debuting this week:

• Introducing Stump Nick Craver! Here's how it works, we call Nick Craver (@Nick_Craver) and he will have 60 seconds to answer 5 questions about servers. If he answers all correctly, he will win a 6 month supply of Clorox Toilet Wands. As it turns out, a 6-month supply is exactly one wand.

• Developer Stories! Where we talk to developers who have cool or interesting stories to tell about how they got into computers and what they build with them. Our very first guest to tell us her developer story is the brilliant Dr. Omoju Miller (@OmojuMiller), a data scientist who is interested in data-driven, machine learning approaches to solving business problems. In discussing one of her blog posts that Jay was particularly struck by, she says:

"I am the kind of person that had a very different, non-stereotypical upbringing. I had toys that were not gender specific. I had planes that I could fly down the street... I had robotic little rats… I had Legos, I had Barbies, I had Easy-Bake Oven… In our house when we were playing it was like we were building worlds. So you had to do the engineering to figure out how to build your building, you had to figure out what was going to be your power generation supply. After you built the house, you had to figure out what you were going to eat, what you were going to wear... It was a very holistic thing. Maybe because of that kind upbringing I have the ability to imagine worlds that don’t exist and just invent them. However, for a lot of people they’re bound in their imagination by what they’ve seen. And a lot of the ways in which we consume knowledge about who we can be is actually true media. If you keep on seeing images that don’t reflect a certain gamut of who you can be, then you have a very narrow view of what you think you can actually do in the world, especially when it comes to technical professions.”

For this week’s installment of building Stack Overflow’s Constitution, our hosts ask the controversial question, “Are you allowed to stand over the IT person while you wait for them to reset your password?”

Listen as our hosts talk it over and then tweet to us using #StackOverflowPodcast: PRO if you think that you should be able to stand over them and wait, or CON if you think that you should go back to your desk and wait for them to notify you. The best explanation, whether you are on the winning or losing side, will be read next week on air as well as win a fabulous Stack Overflow sticker and no Clorox Toilet Brushes.

Last week's winner for the question, "When you are at the supermarket, should you be able to eat an item BEFORE you get to the cash register?" is:

"Pro, the only problem is fitting on the scales after snacking by the bulk bins. #StackOverflowPodcast" - Jonathan Lisic, @jlisic

Congrats Jonathan, you win a thing!

See you next week!

Notable Links:

• Developer Story: s.tk/story
• Backchannel.com on Medium
• Stack Overflow Salary Calculator, now with International flavor!
• Le.Taxi info. (Editor's note: We are really, really sorry about the bad accents in this segment.]
• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

In this episode: Rant Soup™, now with Trello! If you would like to make your own Trello board of rants, or soup, go to Trello.com. Also, according to Joel, Jay is still not getting a raise. (Don't worry buddy, you'll get there someday…)

Today's special guest, calling in from not-so-sunny London, is Stack Overflow PM Kit Karrau. Kit is the driving force behind our new product, the Developer Story, launching today. Developer Story shows what you’ve built, not just where you’ve worked or went to school. It’s your story; tell it your way. Go to s.tk/story to create yours now.

As part of our favorite story about a developer in this week’s episode, we learn that Joel's hands are very small in a certain photo on a certain website (so you should definitely NOT go there right now to point and laugh).

In the News this week, the gang finds out that developers rant the most about product managers, and that AI is going to put tax preparers out of business.

It's also the third week of the Stack Overflow Constitution. Vote on this week's amendment: When you are at the supermarket, should you be able to eat an item BEFORE you get to the cash register? Listen to our hosts' points of view and then tweet to us using #StackOverflowPodcast: PRO if you think that you SHOULD be able to eat it before you leave the store (and pay for it at the register using the wrapper), and CON if you think that you SHOULD NOT, along with a brief explanation. The best answer will be read on the air next week, and by best, we mean which one made us chuckle the most.

Last week's winner is Michael Berkowski with a great tweet story culminating with:

"My request was denied, so I got to learn a little French instead #StackOverflowPodcast" - Michael Berkowski, @mberkowski 9:33 AM - 3 Oct 2016

See you next week!

Notable Links:

• Developer Story: s.tk/story
• Devrant: https://www.devrant.io/
• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

It’s your story; tell it your way.

Get yours today at s.tk/story. It only takes a few minutes, and you do NOT want some other joker snapping up the good URLs. Take it from me, stackoverflow/story/J@yH@n10n.

Technology has evolved. Tech resumes? Not so much.

The resume was invented by Da Vinci in the 15th century. It mostly served as a letter of introduction for traveling lords… and it hasn’t changed much since. What do you see when you scan the bold stuff on a resume? Employers, job titles, schools, and degrees. And a lot of small bullets. Plus maybe an other-stuff-intended-to-round-me-out-as-an-actual-human section at the bottom.

In the roughly five centuries since resumes were created to help nobility vouch for roadbound gentry, they’ve stayed mostly optimized for one thing: conveying the importance of your pedigree.

The emphasis is all on the seniority of your titles and how impressive your companies or schools have been. Which is a great way for some developers to put their best foot forward. Have a Masters in CS from Yalemouth? Cool! That’s one good signal. But it ain't the only one. Heck, even politicians know that fancy schools are only one of many ways to signal potential:

“It turns out it doesn’t matter where you learned code, it just matters how good you are at writing code.” — President Barack Obama

Show, don’t just tell.

Developers, fundamentally, are makers. Like designers… or architects… or jugglers! You wouldn’t hire any of them based on a list of titles or places they’d worked. ("Oh, a Senior Associate Juggler? Get her! I bet she can do those flaming sticks and stuff!") So why hire a developer that way? Makers' skills are conveyed by showing, not telling. Portfolios. Blueprints. This awesome juggling video.

Be more than bullets: Your best work, front and center.

The Developer Story lets you share what you've worked on by linking to actual features you’ve worked on, blog posts, or public code. Those things shouldn’t be described in the second clause of a tiny bullet, or relegated to the “Other interests” section of a resume, to sit unassumingly next to your second-place trophy in intramural tetherball.

The Developer Story puts the work you’re most proud of where it belongs: at the grownup table, right alongside your roles or schools.

No reputation points? No problem. Posting answers or contributing to Documentation is one way to build up public artifacts of your coding experience, but it’s not the only way. Your Developer Story lets you show off whatever you work on. So you’ll look good, no matter how much rep you have on Stack Overflow.

Find a job you'll love, on your terms.

If you’re ready for your next challenge, the Developer Story makes it easy to learn about jobs that fit your personal criteria. And since developers are in demand, we know it’s not about finding a job — it’s about finding the right job. The same way Stack Overflow Q&A put the right answer right on top, when you fill out your profile, Stack Overflow Jobs shows you roles that match the technology or projects you want to work on. (Even if they’re not what you’re using today.) And we always puts the developer in control. No spam, no BS. (Did you know that Stack Overflow Jobs actually penalizes blind messaging by employers?)

And it's 100% backwards-compatible with those crusty old resumes - it can still highlight fancy schools and fancy titles, and anything else you'd include on a traditional resume. So if you're like me, and still just a little proud that you got off the waitlist and eked your way into a school above your intellectual weight class, you can still show off your alma mater off with pride.

But don’t employers just want role, schools, and keywords? Nope. It turns out that they’ve just accepted that that’s all that they can generally get from a resume, leaving them stuck using “seven vs. eight years of JavaScript experience” to determine whom to interview. The employers we’ve shared it with love the way the Developer Story gives them real, tangible ways to understand what a candidate has actually worked on.

It's not just for developers who are job hunting.

Happy at your current gig, but open-minded? According to our 2016 developer survey, 63% of developers aren't actively looking, but are open to learning about new opportunities to level up. If you’re enjoying where you are, but open to finding that perfect new challenge, the Developer Story can help you keep an eye on what’s out there, and we’ll only send you the best opportunities that match your goals.

Completely not interested in jobs, but proud of what you’ve made? Listen, I get it. I never want to leave my job. The Developer Story is for you, too. Like most people who make things, devs often like to share what they’ve built. So it’s designed so you can use it as your own “coding central," even if you’re not job hunting. Just create a Developer Story, but set your job preference to “Not Interested.” You can share the features you’ve worked on, Github repos, blog posts, or even books you’d recommend. It’s your story. Tell it your way.

Once your Developer Story is beautiful, let’s work on your wardrobe.

We think one of the best ways to inspire other devs is by sharing some of the awesome stuff their peers are building. Or by showing a curious twelve year old what someone else who loves breaking machines can grow up to be.

So, for the next two weeks, if you tweet a link to your developer story, and include the #mydevstory hashtag, we’ll enter in you in a contest to win one of two hundred gen-u-ine Stack Overflow tees (50 mens and 50 women shirts each week.) And don’t forget the link to your Developer Story - we need it to contact you if you win.

Take a minute to start your story now.

(We hope you’ll indulge our use of Rear Admiral Hopper’s incredible biography as a case study for the images in this post. You should not take this to mean that the Rear Admiral endorses Stack Overflow in any way. You can, however, take it to mean that we endorse her. Wholeheartedly.)

Thanks to Abby T. Mars, Elaine Wang, Kaitlin Pike, Kit Carrau, Rachel Maleady, Taryn Pratt, and Tim Post for helping to improve this post.

Today we shipped an update to the calculator, which includes:

• International salaries
• Two new positions: Creative Director and Data Scientist
• 2016 market adjustment
• Skills now have a resolution of 0.5 (previously whole integer)

Setting the US market salaries

Our base salaries are updated once a year based on the best available information “market” rates. Sources we look at:

• Industry reports. We purchase salary data from a third-party, aggregated by job title. This gives us rough data for e.g. Software Engineers or Graphic Designers (though it isn’t specific to startups).
• VC surveys. All of our main VCs do yearly compensation surveys (which we participate in) and then share the aggregated data with us. This is our best survey data because it’s more specific to startups, though the sample size is smaller.
• Competing offers. For anyone hired in the previous year, we take into consideration any competing offers they received that they’re willing to share.

Setting the international salaries (new!)

As of 2016, we also benchmark international salaries.

Our People Team (which I lead) researches and establishes a base salary in the local currency for each country in which we have a presence. This salary is determined the same way we do it currently in the US – by researching the appropriate market rate for the country. We anchor it at skill level 1 and 4 years of professional experience.

We recognize that some countries have market salaries that are lower than the US – therefore when determining the local salary, we not only look at the local market, but also the “remote developer market” rate, i.e. the salary you would get if you were paid by a US company in USD.

The international salaries are updated yearly. If we hire someone in a new country mid-year, we’ll research and establish the base salary then.

Try the updated Stack Overflow salary calculator...

In this episode, Joel complains about things. How is that different from the other podcasts, you say? This time there's singing.

Our hosts also talk about a few recent blog posts concerning the declining quality of Stack Overflow while trying very hard, and failing, to not quote the first U.S. presidential debate. Jay and Joel break down what these posts got right, what they got really wrong, and what we can learn from them in our mission to make Stack Overflow a better resource for the world's developers. (Disclaimer: no Kewpie dolls were harmed in the making of this podcast.)

Speaking of the debate: Both candidates had something to say about tech, and we can't let that go without at least discussing the yuge problem of using "cyber" as a noun. Check out this week's “In The News” for this and much more, including hearing David ask "Grandpa Joel" to tell him more about the Xerox Alto.

Also, it's the second week of our new feature (not a bug!): the Stack Overflow Constitution. Vote on this week's amendment: Should programming languages count toward your college language requirement? Listen to the podcast to see where our hosts stand and tweet at us to weigh in yourself. Use the hashtag #StackOverflowPodcast and give us your Pro or Con with a brief explanation. The best answer will be read on the air next week, and by best, we mean which one made us laugh.

Last week’s winner, commenting on whether socks should go on before pants or pants before socks, was Bryan Bedard, who said

"Con. I tried to put socks on before pants but got an InvalidOperationException #StackOverflowPodcast" - Bryan Bedard, 3:53 PM - 26 Sep 2016

See you next week!

Notable links:

• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast
• Fascinating Xerox Alto restoration information
• Check out Esperanto on Stack Exchange and Lindsay Does Languages segment on Esperanto.

Before you listen, please note that this is episode #88, not to be confused with what should have been episode #73 since we last left off at episode #72. That episode was for The Stack Exchange Podcast, and this is The Stack Overflow Podcast. Confused? You’re literally the only one who is. Bury your feelings of embarrassment and don’t let anyone know.

This week, our usual hosts Joel, Jay and David are joined by Documentation team lead Kevin Montrose and product creative director Kurtis Beavers to talk about all the updates to Stack Overflow Documentation including the REPOCALYPSE (i.e. reputation apocalypse). Also joining this week is Ilana Yitzhaki, the show’s new News Editor.

A big change to pay close attention to: We’re writing the Stack Overflow Constitution, and we’re asking you, our listeners, to vote on the various elements of this new pivotal document. This week’s extremely important amendment says that one must put pants on before socks and NOT socks before pants. Listen to the podcast to hear the pros and cons of this amendment, then head to Twitter and submit your vote - with commentary - using the hashtag #StackOverflowPodcast.

Also be sure to listen if you want to hear the gang talk about, but not in, Esperanto (or you could check out the new Stack Exchange Esperanto site instead). By listening to this week’s show, you’ll learn what you should never say to a designer as well as what flight simulators have to do with Excel. You’ll also find out what the gang would do if they had access to a time machine (spoiler: They really, really need to revisit their priorities here). Finally, in a great show of kindness, Jay compliments David on his correct use of the phrase “for which.”

This week, our usual hosts Joel, Jay, and David are joined by Stack Overflow engineering manager Matt Sherman, who recently led the launch of our salary calculator. If you’re interested in working at Stack Overflow, or you just want to know how much our engineering, design, and product roles make according to years of experience and skill level, the salary calculator offers transparency into our compensation methodology.

Comments about the calculator were split on Reddit and Hacker News between us paying too much and us paying too little so… we’re doing it right? The gang goes deep on developers’ problems with salary negotiations, and they share an epiphany about the meaning of the classic board game, Monopoly, that they probably should have realized years ago.

As is now officially tradition — because there’s been two of them in a row — we have another One-Minute Tech Review from Joel for you. This week’s review is of Google Flights, where you can search for cheap flights in seconds. Will David throw shade on his review again? As is now also tradition, perhaps.

Finally, Jay talks about our recent decision to stamp out use of the term “rep-whore” in the community. From now on, “rep-whore” will be treated like any other term that’s inconsistent with Stack Overflow’s “be nice” policy: it will be removed.

If none of this is your cup of tea, make sure to listen anyway just to hear Joel tell a joke about the pluperfect tense. Memorize it and make sure to reuse at the next grammarian cocktail party you attend.

Remarkably, we learned that job listings which include a salary range got 75% more clicks than job listings that don’t. With this experiment, we’re even more convinced that transparency isn’t just the right thing to do, it’s good for companies, too.

Along with much of the tech community, we were impressed with Buffer’s boldness and leadership in salary transparency. So…

Introducing the Stack Overflow salary calculator

We’ve created a salary and skills calculator for Stack Overflow’s engineering, design and product roles. This has been transparent internally for a while; now it’s transparent with you.

Those who know Stack Overflow know that we work hard to work in public. This is a continuation of that tradition.

What we hope

We hope that moves like this will inspire other employers to greater transparency.

A lack of transparency is what economists call an information asymmetry: it’s in companies’ interests to keep these numbers close to the vest. Individuals are uncomfortable talking about salary sometimes, too.

We believe that conventions can change. If more companies become open on salary, perhaps openness will become expected.

Work in progress

Our salary calculator doesn’t cover every role at Stack Overflow. It doesn’t include equity, and only describes US salaries. (International employees use the same system but it’s not merely a currency conversion.) In the spirit of “default public”, we would rather share an incomplete system than not share at all.

The experimental details: 75% more clicks

(By David Robinson and Bret Copleland)

For our experiment, we redesigned the Stack Overflow Jobs ads to display salary ranges. We were curious: just how much effect does this information have?

We ran an A/B test, where for a random half of our users we hid the salary information from the ads they were shown, and measured the difference in clickthrough rate. Visually, it looked like this:

We expected to see an improvement, but we were surprised by the size: a 75% average increase in clickthrough rate (CTR) when we showed a job's salary range.

What if a job has a relatively low salary – is it still worth showing? Generally speaking, yes: we found that showing any salary range led to an increase in CTR, though higher salaries led to a greater bump. For American jobs, we saw roughly a 60% increase for jobs with salary ranges centered below $100K, and about a 100% increase (doubling) for salaries above $100K.

Is this just an effect of novelty, where users were surprised to see salary? Unlikely – we didn't see any decline in the effect, and it has been consistent in the months since. We've tried many other changes to ads and have never seen anything this dramatic.

Clickthrough rate isn’t everything, but it’s an encouraging sign that advertising a salary range will help draw developers to a position.

Try the Stack Overflow salary calculator...

Further reading

• Joel on How much should you pay developers?
• Stack Overflow Developer Survey on job priorities.

"Together, we believe we can do the same thing for technical documentation that we did for Q&A."

Documentation is community-curated, example-focused developer documentation, based on the principles of Stack Overflow.

If you ever wanted to contribute to Stack Overflow but weren't sure you could, now's your chance to give back. Whatever technologies you work with, whatever your experience level, there will never be a time your contribution is more valuable than it is today.

So, why will this be better than how documentation is today, exactly?

Examples, examples, examples - show beats tell. In Stack Overflow Documentation, examples are the star of the show. Anyone can add one, so good topics will eventually have several useful examples. And much like answers on Stack Overflow, the most helpful ones will usually be voted up to be right on top.^*

It's need-driven and self-healing. The best, most diligent technical writer out there still can't beat thousands of actual users trying to learn a function or concept while writing real code. They'll determine what topics or examples are needed most. And whenever something fails to explain something clearly, they can ask for it to be improved.

It builds on what made Q&A work, but recognizes where it can be better:

• Familiar elements, so you're not starting from scratch. Voting, requesting a topic, adding examples all mirror Q&A elements (voting, asking, answering)
  

• More emphasis on collaboration, and ensuring most developers can contribute. The more canonical nature of artifacts created means:

  • More "shared" ownership of posts and more collaboration
    
  • Small edits and contributions are encouraged
    
  • Everything is reviewed by other helpers, so you can't "break" the page trying to help
    

• More recognition for more people - More collaboration means more helpers need recognition. And documentation shares a feedback and reputation system with Q&A, so contributions to either earn you reputation and privileges on both.

• Your generosity, your content. All content is covered by the same CC-SA license that SO Q&A always used. And our regular data dumps will now include Documentation content.

• "Be Nice" still applies. We know that occasionally some folks can get a little prickly, but this is who we still are:

  Whether you've come to ask questions, or to generously share what you know, remember that we're all here to learn, together. Be welcoming and patient, especially with those who may not know everything you do. Oh, and bring your sense of humor. Just in case.

So, why does Documentation belong on Stack Overflow, exactly?

Go back and read Jeff's original introduction of Stack Overflow, you'll find this pitch:

[Stack Overflow] is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.

_{(emphasis mine)}

This was a great starting place, but over the years we've made tweaks as we've learned from the community - both from direct feedback on Meta and from observing how people use Stack Overflow. We learned that our Q&A works best when you've got a real problem, specific to the code in front of you. By coming to terms with that, and tweaking Stack Overflow accordingly, we've become much better at Q&A but have left some programming knowledge out in the cold.

Documentation gives a home to a lot of this good content that has been turned away, or very hard to "get right" in the Q&A format. Namely, the canonical, general reference, instructional content.

Once word got out Stack Overflow was expanding, the developers responsible for some of our favorite tech got a little excited. The Meta community got first dibs with the private beta, but now that Documentation is live on Stack Overflow I'm pleased to announce developers from:

will be participating in Documentation right alongside the community. They'll be watching to see what kind of great examples and documentation are created to inform their own work and help answer or clarify anything that needs it. They're Stack Overflow users like everyone else, we're all working together (to help developers everywhere), so you could see your change reviewed by a Microsoft-y or find a request from a Dropbox-er.

Ready to help?

Whether you've been posting on Q&A for years, or have always wanted to give back if you could, now's your chance. Docs today resembles Stack Overflow Q&A was right when it launched - there's a lot of white space to fill in, and plenty of chances to "actually write the book on" your favorite tech.

Oh, and since we really want to use this launch to expand the Stack Overflow Community tent, we've got some silly/shiny fun to encourage folks to jump right in!

All users who contribute to Documentation the next four weeks:

• Will get a silver "Documentation Pioneer" badge
• Will be entered in a drawing to win one of 100 Stack Overflow T-Shirts

Let's go build this thing together.

• Browse Documentation
• Take the tour
• Jump in and handle (or make!) requests for
  • .NET Framework or C#
  • Dropbox API
  • PayPal
  • PubNub
  • Twitch
  • Meteor
  • Xamarin iOS or Android
  • Twilio
  • .. or browse all tags in Documentation

_{* We literally almost called this "Stack Overflow Examples", but then we thought about having to constantly explain that it serves the same purpose as 'Documentation' used to, but we didn't call it that because the important part of documentation is the Examples, which are central to our thing. So we stuck with the term folks know.}

Our annual surveys ask developers what they’re up to, what tech they care about most, and what they want. This year, for instance, we found that JavaScript remains the most popular programming language in the world, 46% of developers don’t have a bachelor’s in computer science or a related field, and job satisfaction is highly correlated with pushing code to production.

While we like to think we know software developers better than anyone, we’re eager (and curious) to see what you come up with in your own analysis of the data. The launch of our new research site means you can compare what developers have said about the state of the programming world and workforce since 2011.

You’ll be able to answer questions about how technology preferences have changed over time, whether particular demographics correlate with certain developer job types, and even what programmers think of Stack Overflow.

If you do find something interesting while digging through the data, let us know on Meta. And if you’re ambitious enough to make it an academic paper, we’d love to add it to our collection. Finally, if you’re curious about adding even more data related to Stack Exchange sites, check out our Stack Exchange Data Explorer, designed to make it easy to query and browse the public data we periodically release for all Stack Exchange sites.

Happy data diving!

But before we talk to the guests, our esteemed hosts run through some interesting tech news. (Or maybe just tech news. -Ed.) First up: .NET Core! Microsoft is trying to turn a gigantic ship around toward open-sourciness and community-friendliness. (Said ship is apparently unrelated to the arm of Microsoft that forced you to upgrade to Windows 10.) Also: did Microsoft build their own version of Trello? You decide.

And now it's time for the first and possibly only but definitely first monthly One-Minute Tech Review with Joel Spolsky! This week's OMTR is Wallcat. It's free. You can install it. (If you know your Apple password.) It changes the background image on your computer every day! Amazing.

Let's turn from tech news to Stack news. What's shipped since our last podcast?

• A new and improved Stack Overflow Enterprise! It's for big companies with lots of proprietary code who want to run private Q&A for their development teams. Companies with 1000+ developers who want this can get it by sending an email to enterprise@stackoverflow.com.
• We updated the sitewide Terms of Service. It forbids companies from going onto Stack Overflow to scrape profile data, which protects our users from spam.

Our guests have been waiting very patiently through all this, so let's turn to them! Daniel X. and Gareth work at Fog Creek Software, the first company Joel founded. They're currently working on HyperDev, the easiest and fastest way to get your idea developed and deployed on the internet. You can get an app up and running in less time than it takes to listen to this segment--without shaving any yaks. So go check it out! We talk about the story of the product for a long time before we remember to talk about how it actually works, but rest assured, we do eventually dig into that part.

So what's next for Stack Overflow?

• Running some tests on the /ask page. This hasn't been touched since the dawn of time, more or less. The community has been discussing ideas here, so read up and weigh in!
• Documentation. We'll cover this in more detail next podcast.

And that's it for this podcast. Thanks for tuning in!

For the past several months, Monica—who writes documentation for programmers at her day job, and even holds a tag badge in technical-writing on Writers SE—has been spending some of her free time putting together a tutorial for people who are completely new to the Data Explorer or SQL. Thanks to her efforts, and those of another awesome community member, Tim Stone, the de facto maintainer of SEDE (and the SE election stats page), version 1.0 is finally live!

This new tutorial introduces the basic concepts of relational databases, and teaches the fundamental SQL statements that go with them. Examples all use the design of the actual Stack Exchange databases. And for those who find themselves getting really interested, digging into more advanced queries and having some trouble, well, there's a great place nearby to get help.

About the Stack Exchange Data Explorer

In keeping with our founding principles, all user-contributed posts are always available for reuse with minimal restrictions, and we even package up "data dumps" of all the content on Stack Exchange regularly for researchers and others who want to work with large chunks of the content.

Of course, not everyone has the time or expertise to download massive data dumps and then install SQL locally or write custom code to get what they want. So we also provide a web UI to the same information: the Data Explorer. It's essentially a publicly accessible copy of the databases behind the SE Q&A sites. It gets updated weekly with all the latest changes, minus a few sensitive things like users' e-mail addresses and voting behavior.

People have mined all sorts of interesting information out of SEDE. Ever been curious how much reputation you would have if the 200-points-per-day rep cap didn't exist? Or wondered how true someone's claim that "downvoters are ruining everything" really is? Maybe you have an idea for a new badge, and want to see how many people would meet its criteria before you propose it on meta. For all of these situations, SEDE is the answer.

But even though SEDE is nicer to work with than a raw data dump, it can still be pretty intimidating to new users, especially those who aren't trained database engineers. Up until now, the Data Explorer's own help docs have been a little thin, and mostly covered very specialized, advanced features. We've wanted to expand the guidance there for a while, but never quite got around to it. Then Monica rewarded our procrastination by helpfully volunteering to take on the writing.

So please check it out, try your hand at answering that question you've always had about your favorite site but never knew who to ask, and let us know what you think on meta. And again, a big thank-you to Monica and Tim for their work in creating this great guide!

On May 26th and 27th, Stack Overflow has the privilege of participating in the inaugural White House Foster Care & Technology Hackathon. This event - hosted by the White House, the U.S. Department of Health and Human Services, and Think of Us - will bring together child welfare leaders, non-profit organizations, and foster care families and alumni, as well as engineers, technologists and leaders from the technology sector.

At the Hackathon, Stack Overflow will team up with subject matter experts to "hack" on the topic of preventing unplanned pregnancy for foster youth. We will create a prototype solution to try and ensure that youth in care have access to culturally relevant information and resources about sexual health, including pregnancy planning and prevention. Our hackathon team - Adam Lear, Kirti Thorat, Geoff Dalgas, and David Haney - are very excited to put our skills to use in a field that is deserving of positive change.

Over the past few decades, it has become clear that technology brings about positive social change. From bringing education to underserved populations, to printing medical devices for third-world countries, to raising awareness of social inequities, technology is one of the best resources we have to solve the problems we face as a global community. As humans we have a responsibility to help each other in whatever ways we can. As software engineers, we're equipped to create technology that can change lives. To that end, our proposed solution is a mobile app - easily accessed by foster youth via smartphones - that can provide geo-aware addresses, information, and ratings about trusted resources, clinics, and support groups that foster youth can access and learn from. A major issue identified in the field currently is uncertainty about who foster youth can talk to - often on short notice - about a broad spectrum of sexual health topics; this app can become a powerful on-demand resource for social workers and foster youth everywhere.

Stack Overflow will continue to serve programmers of all ages and upbringings. We are honored by this amazing opportunity to improve the lives of foster youth, and look forward to meeting - and being a resource to - the many foster youth that will pursue careers as developers in their future.

We fundamentally believe that developers are writing the script for the future. The work that developers do every day is transforming industries and shaping the way we all live, work, and experience the world around us. We also believe the professional generosity of developers is unmatched; Stack Overflow wouldn’t be what it is today without the contributions of millions of developers and their desire to help one another while advancing the world’s collective programming knowledge.

We’re thrilled we have a veteran storyteller like Adrianna on board to help us show the world just how important we believe developers really are and what we’re doing as a company to support them. Beyond Q&A, developers can go to Stack Overflow Jobs to find opportunities targeted to their interests while connecting with recruiters (no spam allowed). We also want to make sure businesses know that the best place to source technical talent and gain insights about the developer community is through Stack Overflow Careers. We have a ton of exciting products on our roadmap, all of which support our mission to help developers learn, collaborate, and advance their knowledge and careers.

Adrianna will drive our global branding, communications, digital marketing and demand generation – basically raising awareness about Stack Overflow and sharing with the world the industry-changing work being done by the Stack Overflow community. As part of her responsibilities, she’ll join the Stack Overflow executive team, helping support our continued expansion into services that make developers’ lives better.

Please join us in welcoming Adrianna to the Stack Overflow team!

Source

This is our starting point for this article. We have the Stack Overflow repository on a developer’s machine. For the sake of discussing the process, let’s say they added a column to a database table and the corresponding property to the C# object — that way we can dig into how database migrations work along the way.

A Little Context

We deploy roughly 25 times per day to development (our CI build) just for Stack Overflow Q&A. Other projects also push many times. We deploy to production about 5-10 times on a typical day. A deploy from first push to full deploy is under 9 minutes (2:15 for dev, 2:40 for meta, and 3:20 for all sites). We have roughly 15 people pushing to the repository...

Read the rest of Stack Overflow: How We Do Deployment - 2016 Edition on Nick's blog here. It's the second in an extensive series of blog posts on Stack Overflow’s technical architecture.

In the context of servant leadership, it’s our job as managers to ensure that our time together meets this high bar.

Optimize for presence

Meetings are synchronous communication. In programming parlance, they are blocking, which is to say they prevent other work from being done. They are expensive in terms of both actual time and context switching.

Therefore, meetings should be reserved for interactive communication that requires presence. This is especially true at Stack because our engineering team is majority remote and distributed across time zones.

Reciting status while others listen is not good use of presence. A list of facts can be read just as easily as it can be heard. Can we do better?

Question-driven

My particular team (Careers) does something a little different. We update a status document ahead of time. We block out 5 minutes of silent reading at the beginning of the meeting.

Then, we go to every team member and ask if anyone else in the meeting has a question for them. There is no status recital. A conversation must be prompted by a question. There are usually plenty.

No questions? Great! Let’s get back to things that aren’t meetings.

Talk-show host

That said, we want to tease out conversations.

When I run that meeting, I will do my research ahead of time and have questions in my back pocket if others aren’t forthcoming. I ask follow-ups. A bit like a talk-show host.

Also? We like guest hosts. We pick a new team member to run the show every two weeks. Running a meeting is FizzBuzz, remember? Nice opportunity to broaden skills for future managers.

Managers like to talk

A further advantage of the question-prompted format is that we managers don’t get to talk in an open-ended way.

Talking needs to be about something someone wants to know, and which is worthy of our valuable, synchronous time together. Managers set an example here, by deferring to the team to choose the direction of conversation.

Every team is different

To be clear, what I describe above is what my team does. Others at Stack share these principles but go about it their own way.

The question-driven format has been good for us on Careers. We’re a big team (13 developers!) so it’s especially important to ensure that meetings are lively, informative, and time well spent.

My final attempt (which is among the fastest) ended up using a lot of tricks, which I think may be of general interest – so I’m going to walk through how the code works.

View the full post at kevinmontrose.com...

According to the proposal on Area 51 at the end of the beta, the site had:

• 115.7 questions per day
• 82% answered questions
• 1,499 avid users and 33,678 total users
• 1.7 answer ratio
• 42,464 visits/day

While I was writing this post, the site was in fifth place by questions per day, it is one position above Server Fault (which, among other things, is one of the trilogy sites)! To build a community of this size, it took us only nine months! Well, not really, actually. We, the community of Russian-speaking developers, have been building up our professional culture and the knowledge base for several years now.

We started our story with three issues in mind.

• Compensate for the lack of professional communication at work. Some of our colleagues (I mean, physical ones) are not willing or able to be engaged in professional communication in their spare time. Experts and those seeking new knowledge and skills often have to search for knowledgeable programming enthusiasts outside their company, and, moreover, sometimes they even have to change companies because of the absence of necessary skills and passion for the profession among their peers.
• Collect a base of notes ready-made solutions for work. Whether we’re working with new or very old technologies, we are faced with the need to seek a solution by browsing through vast volumes of documentation, and finding it, just to forget in a few days; not just the solution itself, but also where it was found. This process may drag on until someone responsible publishes, in a public place, a minimal solution with comments and appropriate links to sources.
• Share experiences with colleagues. How many times have we experienced frustration after looking for the right gcc options for a week, realizing that lots of people had spent weeks solving the same problem? Problems like this could be solved within a few minutes, if you knew where to look for the solution. It would be wrong not to share the solution with colleagues!

We did not just think about how great it could be to solve all these problems in the scope of the Russian language, we have started solving them! Together.

Graduation allows us to say that Stack Overflow in Russian is no longer a site for a couple of enthusiasts who strive for excellence in their profession. Stack Overflow in Russian is now a big crew of enthusiasts who strive for excellence in their profession!

Perhaps it is not visible at first sight, but by the words “Stack Overflow in Russian" we mean real people. Those whose efforts would be hard to overestimate: @VladD, @Nofate, @Nick Volynkin, @Etki, @andreycha, @Suvitruf, @Discord, @alexander barakin, @ЮрийСПб, @PashaPash... These are just a few randomly selected folks. Cannot believe that the community is so strong? Check it out – http://ru.stackoverflow.com/users.

А few facts:

• Per month, more than 2,000 developers join the community.
• The site is most popular in (descending): Moscow, Kiev, Saint Petersburg, Minsk and Kharkov.
• Monthly, more than 3,000 developers get correct answers from their colleagues on the site.
• To get as much developer attention as on Stack Overflow in Russian, you would need to hire 23,000 developers full-time.

Imagine how many person-years are being saved each month due to these people who ask questions and answer them on Stack Overflow in Russian. It's amazing, isn’t it?

We think it's not a secret that professional growth is only possible among more advanced colleagues. With the launch of Stack Overflow in Russian, the Russian-speaking developers can constantly improve their skills without needing to change jobs again and again in search of an exemplary team (if it is not the goal, of course). Today, no matter where you work, — at a Google or at a Mickey Mouse company, — you will still be able to grow professionally in a community of experienced colleagues!

What People Are Saying:

The strategy of looking for an answer in the Internet is easy. I type a question in a search engine and usually I see the answers on the first page of the search results.

I ask questions on Stack Overflow in Russian because there I can get very quick answers to my questions. Also, the interface is nice and user-friendly.

I see plenty of benefits :) Because of the users’ answers I learn a lot. Thanks to Stack Overflow in Russian I learned almost everything that is required for my work and so I do not ask stupid questions anymore.

The questions I asked, of course, are helpful to others. Many questions have gained lots of views, most likely from the search engines, and some questions got upvotes, which means that colleagues are interested in the same topics, too.

Once in 2012, if I am not mistaken, I had to find an answer to a question and typed a search query into Yandex. Along with the search results list, a block of advertisements appeared, and the first advertisement lead to Stack Overflow in Russian. Since the search results did not contain the right answer to my question, I clicked the ad and asked the question on the site. That was the first time I visited such a site. Of course, I got an answer almost instantly. I have been here on the site ever since :)

Currently my profile is 3 years 9 months old :) I visit Stack Overflow in Russian every day to look through the questions and answer them, if I can. On my mobile, Stack Overflow in Russian is the first in the "Last Visited" list!

The site is certainly useful for everyone, and I am delighted to have found it just by chance. Thanks to Stack Overflow in Russian, I have learned so much!

– ModaL

I found answers to all (!) my questions here. Even when I expressed myself, perhaps, not entirely clearly, I was guided in the right direction and to a suggested plan of action. I studied the programming on my own, and each time I had questions (frankly, I had a lot), Stack Overflow in Russian helped me to answer them.

Within a few hours, up to one day maximum, all my questions were answered. I'm fascinated by the founders of the site and the colleagues who helped me.

– Rakzin Roman

Glad to see how Stack Overflow in Russian is gradually growing and accumulating knowledge. It is even more pleasant to realize that I had a hand in it.

I am glad that we are, compared to the same Stack Overflow in English, somehow more democratic and kinder.

I have been on the site for a long time. I have noticed a gradual trend to systematizing and organizing knowledge. I am really amazed with how much time people contribute to Stack Overflow, which is very exciting.

I am glad that I am part of a community that helps people. And, answering questions, we also systematize our own knowledge and discover something new for ourselves.

So, thank you all, and let's make Stack Overflow in Russian even better :)

– Suvitruf

We can proudly say that together we are gradually building the best place on RuNet, where everyone can get a detailed answer to any programming question. And please, don’t take my word for it, check it yourself — ask your question or answer someone’s! (After all, all professional software developers know Russian, don't they? Or are you not a professional developer?)

Still here? Awesome. Or your browser is crazy slow, in which case you should think about some new hardware.

I've repeated many, many times: performance is a feature. Since your code is only as fast as the hardware it runs on, the hardware definitely matters. Just like any other platform, Stack Overflow's architecture comes in layers. Hardware is the foundation layer for us, and having it in-house affords us many luxuries not available in other scenarios...like running on someone else’s servers. It also comes with direct and indirect costs. But that's not the point of this post, that comparison will come later. For now, I want to provide a detailed inventory of our infrastructure for reference and comparison purposes. And pictures of servers. Sometimes naked servers. This web page could have loaded much faster, but I couldn't help myself.

In many posts through this series I will give a lot of numbers and specs. When I say "our SQL server utilization is almost always at 5--10% CPU," well, that's great. But, 5--10% of what? That's when we need a point of reference. This hardware list is meant to both answer those questions and serve as a source for comparison when looking at other platforms and what utilization may look like there, how much capacity to compare to, etc.

How We Do Hardware

Disclaimer: I don't do this alone. George Beech (@GABeech) is my main partner in crime when speccing hardware here at Stack. We carefully spec out each server for its intended purpose. What we don't do is order in bulk and assign tasks later. We're not alone in this process though; you have to know what's going to run on the hardware to spec it optimally. We'll work with the developer(s) and/or other site reliability engineers to best accommodate what is intended live on the box.

Read the rest of Stack Overflow: The Hardware - 2016 Edition on Nick's blog here. It's the second in an extensive series of blog posts on Stack Overflow’s technical architecture.

Because of this, we like to think we know software developers better than anyone — and we have the data to back up that claim. Each year since 2010, we’ve asked developers what they’re up to, what tech they care about most, and what they want.

With more than 50,000 responses fielded from 173 countries, this year’s Stack Overflow Developer Survey is the largest and most comprehensive survey of the programmer workforce that has ever been conducted.

View the full results here.

Key Findings on Technology:

• JavaScript remains the most popular programming language in the world.
• React is the fastest growing technology on Stack Overflow. Swift is exploding too, and Objective-C is in decline.
• Rust is the most-loved programming language. A higher percentage of developers who program with it want to continue to do so more than any other programming language.
• Visual Basic is the most dreaded language. A higher percentage of devs who program with it don’t want to continue with it more than any other programming language.

Key Findings about Developers at Work:

• 91% of developers in the workforce are "gainfully employed" either full-time, self-employed, or freelance.
• 46% of developers don’t have a bachelor’s in computer science or a related field. So if you’re an employer requiring one of these degrees in order to consider a developer candidate, you may want to reconsider your strategy.
• Developers just want to code. Job satisfaction is highly correlated with pushing code to production. And 57% of developers told us they check-in or commit code multiple times per day.
• Make it rain! Cloud technologies like Spark and Cassandra pay better than anything else. The median salary for developers in the US who know Spark is $125k, and there are plenty of cloud devs who are making a lot more than that.
• Don’t call programmers “rockstars” or “ninjas”. Only about 10% of devs call themselves ninjas, and 7% consider themselves rockstars.

Thank you to everyone who participated in our survey and shared information about yourself. We’ll be releasing the full data set in just a few weeks. Do you have ideas for what we should ask about next year? Tell us in the comments.

Oh, and one more thing. Here’s the answer to how many pennies were in that piggy bank.

Developers come from all walks of life, and have many unique interests, passions, and hobbies. Often the only thing that developers have in common is their love for programming. It follows that some are good negotiators; others get the double digit percentage finance rate at the dealership when they go in to buy that new car.

How Does Your Company Determine Compensation?

When you hire developers, how do you decide on their salary? Do you allow for negotiations to take place? Is there a strategy in place where you offer a low value, expecting the candidate to counter with a higher number? Are you pleased when they don't counter, and you get good talent for cheap?

The thing is, developers are the linchpin in your tech company. They make or break your products - quite literally, in fact. They're worth a lot of money. You should be paying them what they're worth as one of many strategies to keep them happy. If you're low-balling developers with a salary strategy that rewards negotiation skills, you're probably underpaying them while overpaying the developers who are good negotiators (but maybe not amazing coders).

Your underpaid talent might not feel comfortable asking for a raise to the income that they are worth. Can you guess what happens then? They leave your company for another that values them correctly. The result is that your department has high turnover, lots of churn, and high costs around replacing the fleeting talent.

Stack Ranking: Upsetting Developers Everywhere

One of the most common ways to compensate employees is by employing a stack ranking system. There are varying approaches to stack ranking, but a typical implementation of a stack rank system is as follows:

• A company employs a ranking system, often a scale of 1 to 5, to assess employees.
• These numbers often come with generic and impersonal descriptions. The scores themselves are bucketed with percentages that limit the number of employees that may receive a given grade:
  • 1: Exceptional (10% of employees)
  • 2: Highly Effective (20%)
  • 3: Consistently Strong (40%)
  • 4: Partially Effective (20%)
  • 5: Not Effective (10%)
• Managers are given a fixed $X in raises to hand out for annual reviews.
• The $X budget for raises is distributed per the grading, with the 1's getting the biggest chunks, and 5's often getting nothing.
  • Note that this is how stack ranking is used to control budget costs. You always know exactly how much money is being given out in raises.
• The 4's are warned that they're on the way to being fired if they don't shape up.
• Typically, the 5's get fired or put on a performance plan.

This system - also known by the endearing terms "rank and yank," "forced distribution," and "grading on a curve" - is popular because it control costs, both in terms of annual raises and also under-performing employees. It serves as a system that forces the bottom 10% (or whatever the bucket is set at) out of your company regularly. This is not a bad thing in-and-of itself, assuming that the replacements hired are any better. Of course, this is where one of the major problems becomes evident.

Why Stack Ranking Sucks

Here's the thing: someone always has to be a 5. This system is built on the false assumption that there's always someone who is Not Effective on your team. It institutionalizes the idea of mandatory mediocrity.

It is easy to see how ridiculous this concept is when you apply it to objects instead of people. For example, let's review 5 cars with stack ranking: a Ferrari, a Lamborghini, a Maserati, a Porsche, and Rolls Royce. Which one is the exceptional one? Which two are under-performing and mediocre? In this all-star set, they're all great, but stack ranking demands that one is worse than the others by a large margin.

What happens if you employ good hiring practices and recruit a team of 10 amazing developers? What if they're all 2's and 3's, but you have to give out 4's and 5's? You end up having a difficult annual review where you find yourself apologizing and telling your developer how great you think they are. Because you really do think that. But your words are hollow, and their raise and review are the actions that speak louder; at this company they are thought of as mediocre, because someone has to be.

Have you ever had a review where the actions of your manager didn't match their words? You're being told what an all-star and amazing player you are on the team, how important and awesome you are, and how everything you touch turns to gold, but your review says "you're average" and that big fat 3 rating is searing itself into your brain. You're wondering "if my boss thinks I'm so great, why is my rating average?" That's what stack ranking gets you. This review probably upset you, and now you're contemplating your options. Not a great outcome for you or the company.

Stack ranking also stifles the desire of your developers to try new things, take on new roles with more responsibility, and take risks to grow their careers. This is because a 1 or 2 player won't want to take on the risk of joining a new team, or getting a new boss, who might rank them as a 3 or lower compared to their more seasoned colleagues. Indeed, the smart play is to stay right where they are, and reap the benefits of being on the good end of this ridiculous bell curve.

My biggest concern with stack ranking is the fact that compensation is relative. Your assessed performance depends entirely upon the performance of your peers, as subjectively assessed by your manager. You might have been a 1 if it weren't for that person who happened to claim it. Now the best you can be is a 2. But if they didn't work there, perhaps you'd be a 1. Doesn't seem fair (or even rational), does it?

My Personal Experience With Stack Ranking

I have had a few jobs in the past that employed stack ranking. At one of them, developers picked 3 projects to be assessed on, and then both they and their manager ranked their performance on the projects from 1 to 5. One of the projects that I picked was something that I had built from scratch with a team of 4 people. The thing we built had made the company millions of dollars that year, and I was the lead on it. Naturally, I gave myself a 1 on it. My manager gave me a 3.

I asked him how I could possibly be average at the thing which I created, was the most experienced with at the company, and which had led to millions in additional revenue. His reply was that I was awesome and not to worry too much about the grade. It was very confusing; what he said didn't match what he wrote.

The review continued, and I ended up being given a 3 out of 5. I got a small raise. This was all conveyed to me as my boss happily told me that I was awesome, to keep up the great work, and that to keep it between me and him but I got the biggest raise on the team.

The idea of having the biggest raise made me feel less wronged... Right up until I found out that it was a lie. My team and I were at lunch a few days later when one person bragged that he got the biggest raise on the team. Another immediately said "what? I was told that I did." I began to laugh as I realized what my manager had done. He had told us all that we received the biggest raise, and to keep it to ourselves. Perhaps as damage control for the pain that the mediocre grades had inflicted, but unfortunately for him we talked to each other. The jig was up, and now most of us were madder than we would have been had he said nothing to us at all.

A side note: leaving that job was one of my favorite resignations. When I quit, my boss was distraught, but I said (paraphrased) "hey [boss], don't worry about it! I'm a 3 out of 5, so you should have no issues hiring any other average developer to take up the work I was doing." The look on his face told me all I needed to know: he had now realized for himself why stack ranking sucks.

How to Properly Review & Compensate Developers

The key to happy developers is fair compensation. Fair compensation is all about transparency. At Stack Overflow, we have a transparent system for assessing employee skills and compensation, which is lovingly called Be More Awesome. There is no magic in employee compensation here, and all developers know exactly what they're getting paid, why, and what they could get paid in the future. There are no negotiations, no bell curves, and no quotas.

Be More Awesome (BMA) is pretty simple. It is meant to measure skills; we use performance as evidence of skill. A person may rate highly on their BMA for a skill, even if they haven’t used it in the previous year. There are 4 possible grades that can be awarded for each skill:

• B: Could be more awesome. This is a good thing to work on over the next year -- and your manager will help. This can also be applied for new employees who haven't been in the company long enough to demonstrate that they deserve a higher grade.
• A: Does as expected, at our high Stack standards. Completely, utterly able to accomplish what is needed.
• A+: Does more than your team expects, even at our high level. Exceptional and noticeable skills.
• A+++: Widely recognized level of amazingness. Does and teaches. When people think of this skill, they think of you (or would if they knew you). This will be rare, even on our amazing team.

You might notice that there is no grade below a B. We don’t have C's or lower because we believe that everyone that works here is awesome. If one of our developers were doing C, D, or F level work, we would already be working closely with them to correct it - prior to reviews.

It's also not uncommon for people who are earlier in their programming career to receive a lot a B's. This doesn't mean they're doing poorly at all. It just means they're closer to the beginning of their career than the middle and there's a lot of opportunity for them to grow.

The actual skills that we assess each year change, but the 2016 BMA chart for developers currently looks like this:

There are descriptions that explain what each of these categories are, and they are available for all employees to review at any time.

Once a developer is assessed on a BMA, their letter grades get converted into a numeric score by using a formula that is also published internally for all developers to review. This formula outputs a numeric score between 0.00 and 5.99 (with 5.99 being the best grade), which is then rounded down to the nearest whole number. In short, a developer can receive a score of 0, 1, 2, 3, 4, or 5.

Next we assess the years of programming experience. This is a value that falls in a range from 0 to 25. Naturally, this goes up by 1 at every annual review.

The score and years of experience are then looked up on a chart that has years of experience on the X axis and score on the Y axis, and details salary amounts at each cell. It's worth redundantly noting that this chart is published internally also and can be reviewed by all developers at any time. Unsurprisingly, the cell that your score and experience points to is exactly what you get paid.

Make Compensation Transparent

There are no secrets or magic in our compensation system. All aspects of it are published internally for all developers to review at any time. They also get input into the changes to the BMA skills each year, well in advance of their annual review. They know the formula that we use to calculate salary. Most importantly, their compensation doesn't depend on the performance of anyone else. Everybody can be a 5 in our system and everybody can be a 0.

Above all else, our system is fair and evaluates individual performance, not team performance. If you want happy developers and low turnover, I highly encourage you to try adopting such a system yourself. If your company is unwilling to do so, perhaps evaluate why. Are there secrets and magic in the compensation system that you don't want your employees to know about? Why do you value these hidden metrics? Do your employees feel valued?

A happy developer is a productive developer, and while a fair system does not allow you to easily control salary costs in terms of budget (because everybody can be a 5), it does help increase job satisfaction, lower turnover, and maintain a relationship of trust with managers. And as I've written about before, if you don't have the trust of your employees, you will fail.

EDIT (7/27/2016): We have published a salary calculator based on our internally transparent compensation numbers! Take a look.

PS - hate stack ranking but love Stack Overflow? Come and work with us!

Follow David Haney on Twitter at @haneycodes

As I write this, Donald Trump is well on his way to winning the Republican primary even though most people predict he'd lose a two candidate race. The problem can be summed up with this (hypothetical) chart:

Trump supporters tend to be pretty adamant about their candidate, so let's suppose they wouldn't bother to vote if he weren't running. And let's suppose that Cruz and Rubio supporters would rather have the other candidate rather than Trump. And let's suppose Bush, Kasich and Carson are stealing votes that would go to one of the leading "not-Trump" candidates. In this scenario, it's clear that Trump is only in play because the rest of the field is divided. He'd lose to Rubio in a two-candidate race.

This is precisely the sort of paradox that single transferable vote (STV) systems are designed to resolve. While the math can be daunting, the idea is rather simple. Instead of waiting for candidates to drop out, an STV system allows voters to rank their preferences and resolve the voting accordingly. So in the example above, Carson, as the least-supported candidate, would be dropped and his votes would be transferred to Cruz.¹ The new tally would be:

Then the process of dropping the candidate with the least votes would continue until some candidate gets a majority:

It's as simple as that.²

Moderators on Stack Exchange are elected using single transferable vote because we believe it provides the best method for representing the interests of broad and diverse communities.³ Instead of forcing voters to judge whether a candidate might be popular among other voters, the system allows people to vote their preferences without throwing away their vote on losing candidates.

Footnotes:

1. To simplify the explanation, I'm assuming all of the supporters of Carson would have identical preferences. In reality, other candidates, including Trump, would pick up some of those votes.

2. Again, the real world is a bit more complicated because some people would have Trump as their second or third choice over Rubio. There would also be people who leave both Rubio and Trump off their ballots resulting in "wasted" votes. Finally, the party might decide it worthwhile to award delegates proportionally to, say, the top three candidates. On Stack Exchange, we use the more sophisticated Meek algorithm that solves all of these problems.

3. Even the fact that we allow our users to select moderators at all is a bit unusual.

First: it’s hard

Technical interviewing is hard. The best companies in the world haven’t cracked this nut.

Here’s what Google had to say about the process.

Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess...

This is coming from a company that interviews tens of thousands of engineers, and knows a thing or two about analyzing the data. If it’s hard for them, it’s hard for all of us.

Smart and Gets Things Done

Even so, we have some strong opinions about how to hire (and keep) good developers -- our founder wrote the book on the subject, called Smart and Gets Things Done. This forms a framework for our process.

Mostly Remote

We perform most of our technical interviews remotely, using Google Hangouts and a shared doc for code. It’s quite rare for a technical interview to happen in person.

Stack Overflow has a strong culture and history of remote work, and our interview process reflects that. More than ⅔ of our technical staff works remotely.

A conversation, not a quiz

Our interviews are designed for conversation, and to learn how the candidate thinks. We don’t want our interviews to feel like a quiz.

To be clear, the interview is highly technical and challenging. However, we work hard to make sure the questions lead to productive exploration and conversation.

Fairness and comfort

The interviewing process is artificial. We know this. In real life, no one expects an engineer to program on the spot, in an hour or less, with someone watching.

It is in our interest, and the candidate’s, to relieve their nervousness as much as possible. A relaxed interview is much more informative.

We explicitly tell them to think out loud, take their time, and if they need to back up and fix something, that’s great. That’s how programming works.

We reiterate that we are not looking for the answer to the question, per se.

Decisive

After each interview, the interviewer must make a clear decision: Hire or No Hire.

We don’t do “maybe” – that’s not good for us or the candidate. If the interviewer is on the fence, that’s a No Hire.

We would prefer to risk losing a good candidate rather than hire the wrong person.

Mitigating subjectivity

We also work to mitigate the subjectivity of the process. We standardize on a small number of technical problems, and we write out a script to guide the interviewer. We want to give every candidate a fair shake.

But we also acknowledge that every interviewer, candidate and interview is different.

When the answer is No

We want the candidate to feel respected, even when it’s not a match. Programmers have friends! It’s important to maintain our employer brand.

OK, now tell me about the interviews...

Sure thing. Watch the video above.

• 209,420,973 (+61,336,090) HTTP requests to our load balancer
• 66,294,789 (+30,199,477) of those were page loads
• 1,240,266,346,053 (+406,273,363,426) bytes (1.24 TB) of HTTP traffic sent
• 569,449,470,023 (+282,874,825,991) bytes (569 GB) total received
• 3,084,303,599,266 (+1,958,311,041,954) bytes (3.08 TB) total sent
• 504,816,843 (+170,244,740) SQL Queries (from HTTP requests alone)
• 5,831,683,114 (+5,418,818,063) Redis hits
• 17,158,874 (not tracked in 2013) Elastic searches
• 3,661,134 (+57,716) Tag Engine requests
• 607,073,066 (+48,848,481) ms (168 hours) spent running SQL queries
• 10,396,073 (-88,950,843) ms (2.8 hours) spent on Redis hits
• 147,018,571 (+14,634,512) ms (40.8 hours) spent on Tag Engine requests
• 1,609,944,301 (-1,118,232,744) ms (447 hours) spent processing in ASP.Net
• 22.71 (-5.29) ms average (19.12 ms in ASP.Net) for 49,180,275 question page renders
• 11.80 (-53.2) ms average (8.81 ms in ASP.Net) for 6,370,076 home page renders

You may be wondering about the drastic ASP.Net reduction in processing time compared to 2013 (which was 757 hours) despite 61 million more requests a day. That's due to both a hardware upgrade in early 2015 as well as a lot of performance tuning inside the applications themselves. Please don't forget: performance is still a feature. If you're curious about more hardware specifics than I'm about to provide---fear not. The next post will be an appendix with detailed hardware specs for all of the servers that run the sites (I'll update this with a link when it's live).

Read the rest of Stack Overflow: The Architecture - 2016 Edition on Nick's blog here. It's the start of an extensive series of blog posts on Stack Overflow’s technical architecture.

What’s the deal with ad blockers?

At this point, it’s pretty clear that ad blocking is a big deal. A recent study suggesting the advertising industry is set to lose over $22 billion in 2015 alone as a result of ad blockers is setting off alarm bells. That is a LOT of money. Companies are scrambling to ‘fix’ the ad blocking problem, as active users of ad blocking utilities hits nearly 200 million. But it’s not just that tiny stop sign in the toolbar raising alarms. Apple caused a panic when they announced that iOS9 would permit the use of ad blockers, as many see mobile ads are an important piece of revenue for the industry.

First, the ad industry went up in arms over ad blocking, offering suggestions like developing ways to deliver specific ads to users employing ad blockers. Then, they considered going after Apple when they announced iOS 9 would permit ad blockers. Later, they began asking users to turn off their ad blockers as a sign of good faith. That did not go so well for some. Finally, they prevented Ad Block Plus from attending an industry event. Through all of this, those of us at Stack Overflow sighed and shrugged our shoulders. Clearly, many in the industry just don’t get it. Publishers can’t win by forcing ads -- especially low-quality ads -- in people’s faces. But some in the industry do get it. Eyeo (the company behind Adblock Plus) outlined in their ‘Acceptable Ads Manifesto’ some strong ideas for how to improve digital advertising-- not to mention the iAB’s L.E.A.N Ads program. While there is criticism for both of these solutions, the positive takeaway is that powerful organizations are finally moving toward addressing the problem. Reddit is proactive in their public outreach with their ads. Quartz is trying new and interesting ways to engage with users, to mixed reviews. I’m going to toot our own horn by saying that Stack Overflow started doing these things a long time ago via a numerous channels on our Meta sites for both Stack Overflow and Stack Exchange.

Ads at Stack Overflow

The display ads team grew from just two in 2012 to nine today. In that time, traffic on SO tripled, and sales have grown with it. One of the attractions for new hires on our team is the unique relationship we have with our users and the challenge that represents for a salesperson. We entered into an agreement with Stack Overflow users long ago that we wouldn’t subject them to low-quality ads. Think scantily-clad women selling flight deals, weight-loss supplement promos or wacky waving inflatable arm-flailing tube-men promoting car dealerships. But really: anything that doesn’t speak specifically to the Stack Overflow audience is not permitted. We also don’t accept rich media like animated ads, expandable ads, or video, which are the norm for most publishers today. This strict policy means we leave money on the table, but our team wants to protect Stack Overflow from those kinds of ads, as they run the risk of alienating that established trust.

Salespeople and campaign managers on our team do much more than they do at other companies. They’re more involved with a campaign from start to finish. From explaining to a new client how reputation works to working with ad ops to suggest a shift to a new and popular tag like [tag:swift] because it is attracting many new users. This may seem irrelevant to the ad blocking debate, but it’s not. It encourages edification and awareness for people who otherwise would have little or none, which in turn breeds respect and appreciation. This works for a new member of our team much better than simply saying ‘Stack Overflow is important for reasons x, y, and z.’ And they grow to learn over time what IDEs and SDKs are, and it’s remarkable to watch. This acquisition of knowledge really just means that our team cares about keeping ads useful and relevant on Stack Overflow.

We don’t care!

The truth is: we don’t care if our users use ad blockers on Stack Overflow. More accurately: we hope that they won’t, but we understand that some people just don’t like ads. Our belief is that if someone doesn’t like them, and they won’t click on them, any impressions served to them will only annoy them-- plus, serving ads to people who won’t click on them harms campaign performance. That focus on relevance and performance arrives early in the QA process. Whether it’s our sales people explaining that ads must have borders, or our campaign managers checking landing pages to ensure they adequately inform, we are thorough.

An important part of the QA process is ensuring that not just the creative, but the advertiser is relevant to our audience. Every single ad to appear on any of our sites is vetted by the operations team.* We check copy and content on the ads as well as the landing pages. What we repeatedly ask ourselves in this QA process is quite simple: is this relevant to users? ‘Kiss your hosting problems goodbye’ with a provocative image is not something we want on our sites, and I’m sure our users don’t either. The purpose of this heavy QA is to ensure that our users get the most out of their experience on Stack Overflow. The content is helpful-- why can’t the ads be the same?

This ad tries to be relevant, but falls on its face. Also it’s fake. Sorry, future herpetologists.

The Value of Valuing User Experience

User experience is always on our minds. Indeed, others believe that putting user experience ahead of revenue is a path toward long-term growth for publishers. As the chief revenue office of The Washington Post said, “...the product experience has to be every bit as good as the content.” Our approach is in harmony with that belief, as we keep ads confined to certain areas, and we permit users to downvote or close ads that they don’t like.* This allows users control over their experience. QA, curating content and advertisers, and a consideration of the user experience have been successful tools preventing ad blockers from hindering our growth.

The recent resizing of the sidebar from the non-standard, completely made up, for reasons unknown to us 220x250 to the industry standard 300x250 went through thorough research prior to launch. The problem boiled down to this: we wanted to increase the sidebar size, but wanted to ensure that the content wouldn’t be harmed in any way. Bret and the ad server team dug in and investigated screen size of every user across the Stack Exchange network and concluded that only about 2% of users would be affected by the change. As a result, we proceeded confident that our new increase in size would be a net gain for all involved.

Stack Overflow’s mission to make the world a better place for developers remains a central tenet for the Display Ads team. Everyone on our team considers the impact on our users in most of our primary functions. This dedication to keeping content relevant and beneficial to users is what makes the Big Scary Ad Blocking Problem not so big or scary for us. We want advertising to benefit our users and be a resource, not an eyesore. We want advertising on Stack Overflow to be better for our users and advertisers than anywhere else. I’m proud of what we’ve accomplished so far, and I’m excited to see what’s next.

*Special props to the sales support team, as they manage these functions but for the Careers sales team. This QA process used to go through the ops team on the Display Ads side, but it became too much for an army of two to handle. Sales support now consists of seven excellent support specialists.

I think we have to enjoy what we do if we are to succeed.—John Wooden

Looking back on the past year across the network, it strikes me that we are very fortunate that so many people take pleasure in sharing their knowledge with others. Everything we (as a company and as a community) accomplished was made possible by that singular reality.

Since last year’s report, we changed our company name (back) to Stack Overflow and got an epic new logo. Partly it’s simple branding; causal visitors recognize Stack Overflow and other individual sites rather than the network as a whole. Another reason reflects the reality of our (current) goal: building programmer Jerusalem.

This year alone users asked 2.5 million questions and contributed 3.2 million answers on our flagship site. People gave out 16 million upvotes last year and for the fourth straight year more than a million questions were answered to the askers’ satisfaction. That's a lot of programming puzzles solved. Not every post started as a gem of perfection (there were 2.3 million downvotes), but nearly 10 million comments and 3.4 million edits sorted many of them out. (These statistics come from public data. Feel free to look up the results for your favorite site.)

Nearly two years ago we expanded the Stack Overflow community beyond English. This year the experiment paid off: Stack Overflow em Português graduated from beta status. Building on that success, we started a Japanese-language Stack Overflow, absorbed a Stack Overflow in Russian, and Stack Overflow en Español began its beta. Non-English Stack Overflow sites collectively field 159 questions per day. None of this activity seems to have come at the expense of the English site—people just enjoy sharing knowledge using the language in which they are most comfortable.

Have you ever looked at your digital collection (books, movies, music, games and so on) and realized you have titles you’ve never consumed and don’t even remember obtaining? Stack Exchange is like that except all 150 communities prove to be amazing. As a Community Manager, I’m obviously biased in my evaluation—except the quality of these sites has almost nothing to do with us. Instead credit goes to the thousands of core users who write posts, improve them and vote up the best content.

Excluding Stack Overflow, users asked 967,039 questions and provided 1.3 million answers. Over 4 million comments helped clarify those posts and people submitted 1.6 million edits. There were 7.1 million upvotes and 1 million downvotes to rank posts and reward authors with reputation. In addition to the 3 million reviews completed on Stack Overflow, 1.5 million posts were reviewed on other sites. Askers "accepted" 402,647 answers as particularly helpful in 2015. Answers don’t just benefit the people who ask the questions either. Last year the Stack Exchange network (including Stack Overflow) racked up 8 billion page views. Nearly all of that traffic came from people searching the internet at large and discovering an answer on the network. Quantcast ranks the stackexchange.com domain (excluding the trilogy and sites with custom URLs) in the top 50 US sites.

In order to handle that much activity we need a massive data center, right? Well, not really. After serving faithfully for four years, we upgraded the hardware in our "New York" data center. Instead of failing over to our backup data center in Oregon (which was moved to Denver in June), the Site Reliability Engineering team updated hardware live. This requires careful planning and plenty of redundancy: 11 web servers, two SQL clusters, two Redis servers, etc. Most of the time those machines run at single-digit CPU load. We expect the new hardware to keep up with the load for the next four years.

We used to joke that all of our sites should be named "$topic for programmers". But as sites and the network mature, that’s getting less true. Last year the network expanded to 17 new topics, including Woodworking, Music Fans, Health, and Law. Instead of renaming to Stack Overflow, we could have gone with Socratic University: there just aren’t many topics you can’t ask about. Several of our sites, especially the mathematically oriented ones, boast serious academic chops. Papers regularly cite posts from Theoretical Computer Science, Mathematics, MathOverflow and Physics.

A tiny sample of the smörgåsbord of tasty content posted last year:

Gaming wins the title of most viewed question with:

1. How do I deliver a baby? Presumably a fair number of the 867,960 views were to figure out what game the question is about.
2. Why does "effective. Power" text crash the iPhone OS? (Apple, 448,473 views)
3. How to disable the "Get Windows 10" icon shown in the notification area (tray)? (SuperUser, 416,421 views)

The top voted answers?

1. New warnings in iOS9 (Stack Overflow, +812)
2. On OS X, why does sudo ls show hidden (dot) files? (Super User, +378)
3. Leaving intentional bugs in code for testers to find (Programmers, +374)

The top posts by anonymous feedback:

1. Is it 'OK' to use the root user as a normal user? (Apple, +783)
2. How to make Windows 10 File Explorer open "This PC" by default? (Super User, +693)
3. How do you raise an intelligent and happy daughter in a sexist world? (Parenting, +353)

The community team used to imagine that we could individually evaluate every site in detail. But even after hiring four more people we just can't scale as quickly as the network has. Fortunately, our subjective evaluations of Stack Exchange sites, small and large, show they're exceptionally committed to quality. As a result we’ve switched to objective site evaluations (Daniel Kahneman would be proud) and graduated a record number of beta sites:

1. ExpressionEngine
2. Movies
3. Chemistry
4. Stack Overflow em Português
5. Biology
6. Network Engineering
7. Cryptography
8. Code Review
9. Stack Overflow на русском
10. Raspberry Pi

Our designers worked with each of these communities to come up with pleasing designs that fit the aesthetic of each topic. In addition, WordPress Development and Skeptics got beautiful redesigns. Additionally, most sites were updated to use the Less preprocessor, polished for higher-resolution monitors and have new profile pages. This very blog got an overhaul too. We've been hiring designers, but not as fast as our sites are growing. So the following sites elected moderators while awaiting their designs:

1. Blender
2. Computer Science
3. Anime and Manga
4. Magento
5. English Language Learners
6. Japanese Language and Usage
7. Software Recommendations
8. Musical Practice and Performance

After five years of democratically electing moderators, it’s mind blowing that Stack Exchange is still the only major network (with the notable exception of Wikipedia) that embraces this form of self-governance. It’s a strategic advantage we wish more internet communities would adopt. We simply cannot thank our 476 volunteer moderators enough for their patience and dedication.

At "Stack Exchange, Inc doing business as Stack Overflow", we think of our communities as our partners. The company’s responsibility is to provide our users with the very best platform for helping each other and creating lasting artifacts. This year, we plan to roll out some mighty big changes that we expect will improve the lives the world’s software developers. (If you are a programmer, please take our survey to help us know how to serve you better.) As with Q&A, we intend to open these features up to other domains as makes sense.

We aren’t finished with our existing products either. Each week, the community team asks our developers for three or so improvements often selected from the various Meta sites in the network. Some of them are small, such as allowing privileges links to be clicked without JavaScript. But we’ve also fixed highly upvoted requests such as preventing canonical questions from being deleted. JNat put together a report describing the 75 requests directly benefiting either the community or moderators. He also reports 433 community-requested features and 1,267 community-reported bugs were marked as completed in the year.

Our users pay attention to these changes too. Feedback, whether encouraging or critical, reminds me that what happens on Stack Exchange matters to the daily lives of folks around the world. That enthusiasm and industry made 2015 our most successful year (so far).

Punyon started working at Stack Overflow on the Careers team in June 2010 (back when Careers developers were *de*valued associates). His interview process involved a party and a change of pants. You should listen.

So why are we having Punyon on the podcast, anyway? Because of Jobs on Stack Overflow. (We talked about this last podcast, too, and Donna wrote a blog post as well.)

And now, a story about how David was wrong and Jason was right! Basically, we made a wrong decision a long long time ago and built Careers as a completely separate application. When at last we decided to fix this, we thought it was more or less insurmountable, or that it would take years. But then we had our annual company meetup at a hotel in San Diego with weird showers (take our word for it) and everything changed forever... because Dalgas and Punyon put their heads together. The summary: Careers is putting on a Stack Overflow outfit. (Jason does a better job of explaining it, don't worry.)

Then Punyon went home and crammed years worth of work into a week. At least that's how I think it happened. It's live for everyone now, and you can go look at it, and it probably won't break because we did a lot of work to make it perform better for Stack Overflow's scale. Anyway. It's here: http://stackoverflow.com/jobs.

Lest we make it sound like Jason singlehandedly shipped Jobs on SO, David made him recite the list of his co-conspirators from memory: Donna, Dalgas, Nick Craver, Dean Ward, Kirti Thorat, Nick Larsen, Roberta, Ana, Shog, Mike McGranahan... and if you worked on this but aren't listed here you should go yell at Jason and not me.

Anyway, this was a cool project for Jason, who spends most of his time interpreting whale songs (which is apparently what the data team does). It was also cool because he gets to ship it and immediately run away to parental leave - babby #2 arrives on January 8! Congratulations, Punyon family!

So! Is there anything else going on? There was some kind of bash going on at the time of this recording. A Winter Bash, you might say. Also, Stack Overflow en Español is in beta público, Stack Overflow на русском is graduating, and Stack Overflow スタック・オーバーフロー is continuing to flourish. And check out the new design on the Raspberry Pi site!

Thanks for joining us for Stack Exchange Podcast #70. See you next time!