In this episode: Joel rants about travel for the first time ever; Jay explains the Developer Survey (launched last week); and the hosts ponder the reason for Connecticut's existence.

This week's Developer Story is prolific programmer, teacher, writer, podcaster and so much more: Scott Hanselman! In his 3rd appearance on the podcast, Scott recounts some of the earliest inspirations that helped take his life from being "voted most likely to be convicted of white-collar crime" to the success that he is today. Just some of his great advice to us about helping the next generation:

"Stuff that you might be doing alone, find a kid and do it with that kid. Include them in soldering or in chopping down a tree or putting together a square-foot garden in the backyard. Those are all gifts that we can give to people moving forward."

As you know, we're preparing a constitution for Stack Overflow. Each week, we bring you a proposal, and you, our listeners, will decide on whether that proposal becomes a part of our new constitution. This week's question:

Is it sufficient to close a bug as NOT REPRO or do you have to write some kind of explanation?

Listen to the opinions of the hosts, and then 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! The funniest explanation, whether winning or losing, will be read on next week's podcast and win an awesome 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, answering the question: The Simonyi Amendment, Shall we bring back Hungarian Notation? Is:

"YAY but only the real Hungarian notation. Semantics based instead of type based. In Hungarian instead of English." Thanks @inka22222, you win a thing!

Week Links:

• Quark Conference India - Joel will be there if he can navigate the dropdown boxes.
• Developer Survey Blog Post
• OMTR - Lutron Light Switches
• News: Atlassian buys Trello! (Also, proof that Michael Pryor was a cheerleader.)

Podcast Links:

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

Links from our conversation with Scott Hanselman:

• Listen to his podcasts, they are amazing. Seriously, Just do it. Hanselminutes.com, This Developer's Life, (Ratchet & The Geek)[http://www.ratchetandthegeek.com/]
• Anjuan Simmons - Lending Privilege
• Babysmash.com

Most Common Benefits

Check out Stack Overflow's own company page (so meta!) to see an example of what a company page can look like; each company can list benefits as text describing what they provide. To start with, probably to no one's surprise, most companies with pages here on Stack Overflow offer developers health insurance, paid vacation, and a retirement plan. Other very common benefits include flexible schedules and stock options. When we analyzed the benefits posted by companies on Stack Overflow, these were the most common, and certainly I know they are high priorities for me!

Here we see that companies use different combinations of words to describe very similar benefits; there are really only a few separate concepts represented in this chart of most common benefits. Also notice that companies like to communicate that they offer competitive salaries, even though I am not quite sure that counts as a benefit per se.

Read the rest of "Benefits for Developers from San Francisco to Sweden" over on Stack Overflow's Developer Hiring Blog.

Want to see how you stack up against the world’s developers? Take the survey now.

We’ll publish initial results for you to peruse in March. A few weeks after that, you’ll be able to download and analyze anonymized results of the survey under the Open Database License (ODbL). We look forward to seeing what you find!

Why We Do This

We estimate that responses to the 2016 survey cost 14.6 years of total developer time. That’s a lot of missed opportunities to squash bugs and ship product. So why do we do this? And more importantly, how do we pay developers back for their time spent?

It starts with our shared, company-wide mission: Everything we do at Stack Overflow is done to make developers’ lives better. Whether it’s through Q&A, Documentation, or finding developers better jobs, we’re single-mindedly focused on doing what’s best for the developer community, and how we can promote developers’ interests. The first step to doing this well requires knowing in detail what different developers want, what their pain points are, and how they want to share and improve their skills.

Developers are generally misunderstood by non-technical managers, recruiters, and policy makers. This has led to lousy hiring practices, poor environments for development (open office concept, anyone?), and misallocation of resources. Having reliable, comprehensive survey results we can point to helps us educate companies. It also empowers developers who need more data to support their cause, whether it’s in asking for a raise to match industry standards, or because they’re pushing for a change with internal development or HR practices.

We also of course use the survey to improve our own policies at Stack Overflow, as well as our products for developers. We want to know if what we’re doing is working, and what you want to see improved.

See How You Stack Up

Last year, we fielded responses from over 50,000 developers in 173 countries. We’re looking to break our record again this year, and we need your help. Take the survey now.

Got questions of your own or feedback? Post in the comments below or on Meta.

Time for a Fashion Show

We saw many creative ways to wear hats, but here are a few of our favorites:

Some Stats about Hats!

This year, 215,960 users earned a total of 797,074 hats! The most awarded hat was our version of a participation trophy, Just Here for the Hat. This hat was awarded to all Winter Bash users on a site, once any 20 hats were unlocked on that site. A total of 269,016 of them were handed out across the network to 214,457 unique users. Some people wore the hat brilliantly:

Stack Overflow was the first site to unlock it. They were also able to get the hat less than 8 hours into the fun, with only 6 users. A big congratulations goes out to Language Learning, as it only took 2 users to unlock the hat, with one user having 18 of the distinct hats. In comparison, it took 11 users to unlock the hat on Software Recommendations, which was quite a team effort. All in all, 108 communities earned the trophy hat.

The next most common hat was I Have A Little Dreidel. It was awarded 146,403 times to 116,462 users. Because it was awarded an entire week of Winter Bash for participating on a site during any day of Chanukah, most everyone had a chance to earn it.

Many of the other time-based hats were the most common across the network: Epiphany (68,013 times to 58,157 users), Mmmm Bacon (54,058 times to 45,749 users), Bûche de Noël (33,925 times to 28,770 users), and First Responder (605 times to 508 users).

The silver badge hat, 925, was handed out 54,023 times to 50,954 users. We already knew earning a gold badge was difficult, which made the gold badge hat a bit harder to earn. 24 was awarded 9,488 times to 9,266 users. Just like previous years, we had a few hats for using the mobile applications: Cutting the Cord (2,456 times to 1,932 users), and Loungin’ Around (109 times to 104 users).

This year, was the first year we introduced some site-specific hats. Stack Overflow has two products, Developer Story and Documentation, which are not available on the rest of the network, so we awarded hats for participating in them. The NeverEnding Story hat was awarded to 5,263 users, and What’s Up, Doc? was awarded to 3,246 users.

In order to offset the Stack Overflow only hats, we created two hats that were available on the rest of the network. To earn Polymath (1,934 times to 516 users) and Running Ragged (256 times to 80 users) you needed to run ragged across multiple sites, showing off your knowledge in more than one area.

The most difficult non-secret hat to earn was Maverick, which was awarded only to 17 users. This hat required users to post an answer to a -3 question, that went to +3 after the answer was posted. Many tried to get the hat, but obviously this wasn't as easy as it appeared. The trigger was modeled after the Red Baron hat in 2014 which there are still ongoing discussions around turning into a badge.

Time to Spill the Secrets About Hats

We switched things up this year when it came to secret hats. In the past, users could guess the triggers for a hat, and if correct, and the first to guess it, another hat was awarded. This year, even though hats were not awarded for guessing the triggers, that didn't stop you from guessing or even asking. Some of the guesses were accurate, others not so much. But without further ado, here are the secret hat details (and some more stats).

There were a total of 14 secret hats (assuming you count both the sun and moon version of Where In The World? separately), which totaled 42 hats again, this year. Of course, the most you could earn was 41, since it was impossible to have both the sun and moon hat.

The most common secret hat was the solstice hat for participating on December 21, 2016. The Where In the World? Sun hat was awarded 39,078 times to 33,341 users, while the Moon version was awarded 35,784 times to 30,209 users. This was similar to last year's Flip Flop hat, but Sklivvz got creative in how randomness was assigned.

The first secret hat awarded was This Is Fine. It was awarded to Jake on Stack Overflow less than 30 minutes into Winter Bash on December 19th. The community accurately guessed this was awarded if you have an upvoted answer on a question with a bounty, but you didn't win the bounty. This hat was awarded 965 times to 958 users.

The next secret hat discovered (and accurately guessed by the community) was 180°. It was earned by ColleenV on English Language Learners less than an hour into Winter Bash. In order to get this hat, you needed to vote to close a question, edit it while it was closed, and then vote to reopen...basically you did a 180° on the post. A total of 186 users earned this hat 188 times.

Less than 10 minutes later, Don't Wanna Taco 'Bout It was triggered by users who edited or suggested an edit to 5 posts in a single UTC day, without commenting on the post. The very first user to get the hat was Jamal on Code Review. In the end, it was awarded to 1,111 users 1,177 times.

Elementary was the next secret hat awarded. Elementary was handed out when users edited 5 questions that were posted more than a year ago. A total of 466 users earned this hat 506 times, with Kris Roofe on Stack Overflow, being the first.

Two more secret hats, 6 (3,293 times to 3,193 users) and 8,243,721 (354 times to 338 users) were earned by commenting and then cleaning up after yourself. The first hat, 6 aka Bert, was earned if 6 posts were edited by the owner after you commented on them. The second hat, 8,243,721 aka Ernie, was awarded by deleting 6 comments from under posts (not your own), that were edited by their owners after you commented on them. These two hats worked hand in hand. If you commented on 6 posts, the owner edited them, and you deleted the comments, you'd earn both hats. Jaromanda X was the first to earn 6 on Stack Overflow, with TypoCube™ being the first to earn 8,243,721 on Database Administrators.

Also awarded on the opening day of Winter Bash was my personal favorite, Blue In the Face. Users earned this hat by talking so much you were blue in the face. In other words, by posting 10 comments that earned an upvote. It was first given out to rmaddy on Stack Overflow. Overall, it was earned 2,660 times by 2,523 users. It took a few days, but the community eventually guessed this trigger.

Even though it was discovered on the first day of Winter Bash, the rarest secret hat was TheyLive. It was only awarded to 133 users. To get this hat, you needed to head into the suggested edit review queue and either "Improve Edit" or "Reject and Edit" 5 times. The hat was a zombie head because the edit lived on through your improvement of the post. Emile Bergeron on Stack Overflow was the first to get the hat.

The community accurately guessed Mild Mannered, the last secret hat found on the first day of Winter Bash. Users earned this hat by posting an answer that got accepted, but received no other votes for 12 hours. In the end, this was awarded 7,299 times to 7,180 users.

On third day of Winter Bash, The Hatter was awarded. This threw people for a loop because it was seen so late after the start of hats (the lateness that was due to a bug we found). This was awarded when a user posted a positively scored question at 6:00pm in any timezone. 6:00pm was chosen because it's the time the hatter and the March Hare are stuck at. It was given out 3,761 times to 3,715 users. Once awarded, it didn't take long for users to guess the trigger.

The two remaining secret hats were awarded several days into Winter Bash because they involved performing some act over a period of time. Five days into Winter Bash, Trendsetter appeared. Fashionable users earned the hat by wearing 5 different hats, and by changing their hat using the hat rack on a site, on five different days. Trendsetter was awarded 1,966 times to 1,864 trendy users.

The very last secret hat earned was Like Clockwork. It was awarded if you voted between 3am and 9pm UTC (+/- 9 hours) on nine consecutive days during Winter Bash. Voting like clockwork earned you the hat, and it was earned 1,313 times by 1,211 users.

The Hat-Fanatics Leaderboard

Winter Bash is our way to have fun at the end of the year with all our communities. Even though virtual hats have gone away, this post wouldn't be complete without recognizing some of those who went above and beyond to earn all the hats. They are referred to as the Hat-Fanatics!

This year we had 4 users who earned the most hats network-wide:

Please join me in congratulating the users who earned all 41 hats across the network:

• Alexander O’Mara
• alecxe
• Eran
• David

And with that, it's time to say so long to Winter Bash 2016. We'll be adding more stats about hats on Meta Stack Exchange over next few days. If you have any feedback on this year's event, please chime in on Meta Stack Exchange.

It started with Stack Overflow LLC when three employees and three sites decided to "give back" with some charitable donations and to remember the people and projects that helped us succeed. In the next year, we grew to twenty-four employees and 130+ moderators across 38 sites, so it seemed only fitting to get our Moderators more involved in the process. An invitation went out where we offered to make a $100 donation to a selected charity on behalf of each Moderator representing their community.

And a tradition was born.

Giving back… 8 years and running!

Wow, what a ride! Since 2009, we've grown into a top-30 online destination with 160+ communities serving 1.3 billion page views per month. So this year with your continued support, we are able to make the following donations to charity on behalf of the 509 moderators of Stack Exchange!

And from our engineering and IT staff, it is important to remember some of the tools and organizations that make what we do possible:

Even after eight years of "giving back", this event continues to be my favorite at Stack Exchange. I wish I could share with you the rush that comes from watching the charity selections come racing back across my screen mere seconds after the invitations are sent. It is a sobering reminder of just how many people are out there on the other side of that keyboard while we quietly read our favorite posts. Think about it; right now there are 10s of thousands of people working tirelessly to help people they will probably never meet.

There's a personal satisfaction that comes from helping someone who asks for help, but that satisfaction heightens to a genuine sense of purpose when you realize that you are creating something lasting — something that will continue to help people long after you've moved on.

In this upcoming year, it is good to remind ourselves that there are real people behind the help you find among these sites. Stack Exchange isn't a piece of software, or even the work of the company behind it. It takes the collective efforts of a much larger community working together to make this all happen. It is the generosity of people like you who give so selflessly of their hard-earned knowledge to make this all possible.

So here's to renewing that sense of purpose by doing something bigger than ourselves. And here's to finding those small things that can make a big difference in someone else's life, and leaving behind something lasting… for those who come after.

Cheers!

If you’re hiring a developer, or on the job market yourself, understanding these differences can be important to your work. At Stack Overflow, we host the Developer Stories of hundreds of thousands of engineers, representing a cross-section of several decades of the software industry.

We on the Data Team took a look at the titles developers used to describe themselves, and are sharing some of the most notable discoveries we’ve made.

Common job titles

Let’s start simple. What were the most common job titles, over all time, from the Developer Stories in our database?

We can see, not surprisingly, that some of the most common self-described job titles include “software engineer/developer”, possibly preceded by “senior”. Together the above 12 titles make up 25.8%) of the CV items in our database.

We could go a step farther and come up with a Markov chain, showing common chains of consecutive words. Shown below are all pairs of words where each word appears in at least 1000 job titles, and where word X is followed by word Y at least 1/3 of the time.

One interesting distinction is between “developer” and “engineer”: while they’re generally synonyms, they’re easily distinguished by the kinds of words they’re paired with. We can see that “developer” is often preceded by specific technologies (“java”, “php”, “python”) or by stacks (“front-end”, “back-end”, “full-stack”). “Engineer” is preceded either by “software” (which in turn may be preceded by a level of seniority), or by a functional designation such as “quality assurance”, “test”” “devops” or “R&D”.

We can see other common pairings, such as “user interface/experience,” “team lead/leader”, or “program/product manager.” (Why isn’t my own job title, “data scientist,” in this plot? Because “data” was followed by “scientist/analyst/engineer” in similar proportions, not to mention “architect,” “warehouse,” and other such titles).

Despite the hype, only one in ten thousand resume items includes the word “ninja,” and only one in a hundred thousand is a “rock star.”

What do job titles show about experience?

How many years of experience do you need to be a “senior software engineer”, or a “team lead”? How much experience does the average “intern” or “assistant” have?

We can answer this by looking at the developer’s years of experience at the start of each job. Note that this isn’t measuring (or intended to measure) someone’s skill or expertise: simply how many years of work they’ve listed on a resume before a particular job. (Here we count multiple overlapping jobs as additive, so it’s possible for someone who has been in the industry for 5 years to have 6 or 7 years of experience).

First, we picked out 26 common terms that could suggest a level of experience, such as “junior”, “intermediate”, and “senior”. How many years of experience did each represent?

A few observations:

• Unsurprisingly, more than half of jobs with “trainee”, “junior”, or “internship” in the title had no previous work experience. This is to be expected, but useful to check!
• A typical amount of experience for a “mid/intermediate” developer is 1-3 years, for a senior developer about 4. This is useful knowledge for both developers and employers when interpreting these job titles.
• The median VP has almost four times as much experience as the median CEO. Some manual examination of the data confirmed this finding. Many CEOs (especially those who fill out Stack Overflow Developer Stories) are startup founders, whereas VPs often rose to that position within a company and have more experience in the industry. (This doesn’t necessarily imply that CEOs are unqualified — just that many take such a position early in a career).

In general (not just terms we expected to be seniority-related), what common words tended to have the most extreme (most or least) experience?

One surprise is that not all terms are related directly to seniority- for example, jobs with “DevOps” in the title tended to have around 4 years of prior experience, which makes it about as strong a signal as the word “Senior.” On the other hand, the median developer with “PHP” in their job title had only one year of experience, and the average “Android” developer had even less.

Words changing in frequency over time

The software industry has been changing over the last twenty years, and how developers describe themselves has been changing with it. What words in job titles have been getting more common or less common in the last twenty years?

We identified the words that showed the fastest growth and the most rapid decline.

Some observations:

• Being a “webmaster” is out, but being a “frontend”, “backend”, and “full-stack” web developer is in.
• Mobile technologies such as iOS and Android that entered the industry around 2007 quickly got their own job titles “created around” them (each now appears in about 3% of job titles).
• “Network admininstrator” is a less common title than it used to be, as are “systems engineer” and “systems administrator”, but “DevOps” has been increasing.

There’s a lot more that we can detect about changes in the developer ecosystem from Stack Overflow data, both from Developer Stories and from the Q&A site. Some future posts from the Data Team will look at the technologies people list on their resumes and how those have changed. If you want to help our experiments, fill out your Developer Story today.

Joel's rant today: Turns out, Jeff Atwood was right! Joel was FINALLY on an episode of This Week in Tech (TWiT) Episode 277, enabling him to cross off the only thing that Jeff put on Joel's to-do list all those years ago. Better late than never, Coding Horror...

Today (Dec 19) is a very special day: It's the start of Winter Bash! The season of Hats! To celebrate, our hosts chat with Stack Overflow Community Manager Bluefeet about the making of Winter Bash and what the users can expect for the next few weeks, as well as how she fell into programming and then Stack Overflow. Moral of the story? "Never quit late." Thanks, Jay. David also very modestly takes credit for the whole idea while recounting the history of "Hat Dash". There's even a totally real and not at all silly documentary!

There are 28 known hats as well as a few secret hats that users will have to find on their own. Winter Bash runs December 19 - January 9th on (almost) all Stack Exchange sites. How many hats can you collect?

This week's Developer Story is Dan Luu, senior engineer at Microsoft and prolific blogger at DanLuu.com. He and Jay discuss Dan's blog post called Developer Hiring and the Market for Lemons that challenges Joel's 2006 blog post Finding Great Developers.

"Hardware tools are really really bad... so you can get a lot of value in writing your own, only somewhat crappy tools… it's a very slow process."

This week's constitution question: The Simonyi Amendment, Shall we bring back Hungarian Notation? 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 thick! The funniest explanation, whether winning or losing, will be read on next week's podcast and win an awesome 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 is Jason St-Cyr!

"I like my Gifs with a hard G, because I refuse to unwrap Jifts at Christmas." - @AgileStCyr

Links!

• Winter Bash 2016
• TWiT ep 277 - Joel Spolsky
• DanLuu.com, twitter: @danluu, wat
• In The News: Google's BigQuery + Stack Overflow! It's a big deal, Joel!
• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

Starting today through the end of the day on 8 January 2017, you'll be able to earn and wear hats (and possibly accessories) for performing various things you already do across the Stack Exchange network.

Wait, what are hats again?

For those who aren't familiar with Winter Bash and the Season of Hats, we've documented the long history of Hats for your viewing pleasure.

Upon completing one of the many challenges while being logged on a participating site, you will be awarded the associated hat. Once you've earned a hat, you can visit your profile on any site to choose the item you want to wear. Just click the hat dressing up your badges section on your profile to show the dialog:

Upon picking a hat, you can reposition and resize it to make it fit your avatar. Here is floating head as an example:

Besides seeing all your hats from your profile, you can see how you stack up against the rest of the network on the Winter Bash leaderboard. Only time will tell who will be the ultimate hat-fanatic at the end of the event.

As always, if you're a hater of fun and hats, you don't need to participate or even see hats. You can opt out of hats by clicking the snowflake icon in the top bar, and then click the 'I hate hats' link at the bottom left. If you decide that you no longer hate hats, you can always change your mind during the season of hats.

What's new this year?

Just like prior years, we've got all new hats lined up for the event this year. There are 28 total hats you can earn over the next few weeks. We've got some secret hats lined up with a few minor changes:

• A secret hat for correctly guessing a secret hat will no longer be awarded.
• This year there are no secret hats for tormenting incessantly poking SE employees under a post. Blame our lawyers; they did not like the idea of staff being poked or tormented for hats.

Hats are awesome and a fun way to end the year. It's our way of showing the communities how much we love them. We also put a lot of love into making hats fun for all. We want to give a special nod to everyone involved in putting it together:

• The Marketing Design team for coming up with the beautiful design. With extra special thanks to Kalina Moniquet and Nohemi Olvera for the amazing hat images.
  
• Our hat-umentary team Kaitlin Pike for producing the video, David Fullerton for the idea, and Talal Sarwani for directing it.
• Our hat-velopers, Sklivvz and Oded for implementing all engineer-y stuff to get this launched.
• The hat PM, balpha, for being our fearless hats leader again this year.
• Plus, everyone else who offered up ideas for hat triggers, designs, and assisted in getting it out the door.

Now go forth and get all the hats!

We’ve seen a lot of creative uses of SEDE, from finding out “What questions does Jon Skeet have a higher/lower score on than me?” to “Where have I 'met' another user?” and many other questions keeping the community up at night.

Today, we’re thrilled to expand your ability to play with this data by working with Google and releasing it (with regular updates) on BigQuery. Anyone with a Google Cloud Platform account can use SQL queries or their favorite tool to sort, join, and analyze away.

What makes BigQuery different from SEDE?

• Go beyond 50,000 rows (our SEDE limit). BigQuery lets you go big.
• Unlike SEDE, BigQuery comes with a REST API. You can connect all sorts of tools like Tableau, re:dash, Looker, R, and pandas to it.
• JOIN all the things: BigQuery hosts a wide variety of datasets from GitHub’s to NOAA’s weather data. You can make all sorts of useful or useless but entertaining queries across these.

Go check out our dataset now and poke at it. Feel free to share your results on reddit.com/r/bigquery.

For today's shenanigans, we are so lucky to have guest host (as well as new Fog Creek CEO and close friend of Stack Overflow) Anil Dash, who rightfully mocks Joel's recent keynote at Slush 2016 in Helsinki. If you watch the video here, you will understand this reference:

Thanks @balpha

Joel and Anil talk about the past, present, and future of Fog Creek and it's ties to the origins of Stack Overflow and Trello, as well as the amazing new GoMix (formerly Hyperdev) app building software. So what's been the hardest part of taking over Fog Creek? Figuring out where to sit in the lunchroom every day during mandatory lunches! Duh. Seriously though, culture is such an important part the company's success and Anil is committed to preserving that culture so that Fog Creek can continue to "help ordinary people make extraordinary things on the Internet."

Along with Anil we have special guest Dr. Dave Robinson, data scientist at Stack Overflow, discussing a few of his recent popular blog posts concerning analysis of software developers in New York, San Francisco, London and Bangalore, (over 60k views) and the now infamous analysis of Trump's Tweets (over half a million views in the first week!). We apologize in advance to Android users. I'm sure you're not all angry…

This week's constitution question: Is it pronounced GIF with a hard G /ɡif/ or GIF with a J /jif/? I can't believe that we are opening this can of worms, but hey, the world is crazy right now, so why not? 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 winning or losing, 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, with an answer to the question, "Is it ok to get a mechanical keyboard with loud 'clicky' keys when you are sharing an office?" AKA The Punyon Amendment, is Brian with:

"PRO because they shouldn't be able to hear the keyboard over my trap music."
-@TheBestHuman

Congrats Brian, you won a thing!

Notable Links:

• Follow Anil on twitter! @AnilDash
• OMTR: ecamm iGlasses and PhoneView
• Ogg Vorbis explanation for the whippersnappers
• Slush Conference
• News items: How We Make Money at Stack Overflow, Too Young to Code?
• Twitter: @stackpodcast
• Facebook: The Stack Overflow Podcast
• Our website is now live: http://stackoverflow.com/podcast

Here on the Stack Overflow data team we don't have to hypothesize about where developers are and what they use: we can measure it! By analyzing our traffic, we have a bird's eye view of who visits Stack Overflow, and what technologies they're working on. Here we'll show some examples of what we can detect about each city based on one year of Stack Overflow traffic.

In this post we're going to focus on the four cities that visit Stack Overflow the most: San Francisco, Bangalore, London, and New York. (In this analysis, we counted all traffic within 50 miles of a city: this means San Francisco includes a larger part of the "Bay Area", such as Mountain View and Cupertino).

San Francisco vs New York

First we'll compare the two most popular American cities for software development: San Francisco and New York.

When developers are using a programming language or technology, they typically visit questions related to it. So based on how much traffic goes to questions tagged with Python, or Javascript, we can estimate what fraction of a city's software development takes place in that language.

For example, there were 187 million question views from San Francisco in the last year, and we can see that 12.8% of these visits were to questions with the Python tag, compared to 10.3% of New York's traffic.

Most of these common technologies look like they make up a fairly similar fraction of NY and SF traffic, but we're interested in stark differences. What tags (among the 200 most high-traffic tags) showed the largest difference between San Francisco and New York?

One clear difference: New York has a larger share of Microsoft developers. Many tags important in the Microsoft technology stack, such as C#, .NET, SQL Server, and VB.NET, had about twice as much traffic in New York as in San Francisco.

There are also patterns in the technologies that are more common in the San Francisco area, especially languages developed by Apple (Cocoa, Objective-C, OSX) and Google (Go, Android). We can also see several influential open source projects, especially ones associated with Apache (Hive, Hadoop, Spark).

Rather than looking only at the most dramatic changes, we could visualize the SF/NY ratio compared to the total visits:

This confirms that C# (in NY) and Android (in SF) stand out as the highest traffic tags that show different behavior, with tags such as Excel, VBA, Cocoa, and Go showing more even dramatic differences. Meanwhile, the Java tag has about the same level of traffic in each city, as do several "language agnostic" tags such as "string", "regex", and "performance".

New York, San Francisco, Bangalore, and London

Let's expand the story to include Bangalore, India, and London, England. Together these four cities make up 11.1% of all Stack Overflow traffic.

Each of these cities is the "capital" of particular tags, visiting them more than the other three cities do. Which tags does each city lead in?

This fills out more of our story:

• London has the highest percentage of developers using the Microsoft stack: while New York had more Microsoft-related traffic than San Francisco, here we see London with a still greater proportion. Since both London and New York are financial hubs, this suggests we were right that Microsoft technologies tend to be associated with financial professionals.
• New York leads in several data analysis tools, including pandas (a Python data science library) and R. This is probably due to a combination of finance, academic research, and data science at tech companies. It's not a huge lead, but as an R user in New York I'm still personally happy to see it!
• Bangalore has the most Android development, with two to three times as much traffic to Android-related tags as the other three cities. Bangalore is sometimes called the "Silicon Valley of India" for its thriving software export industry, with Android development playing the largest role.
• San Francisco leads in the same technologies as it did in the comparison with New York (except for Android). In particular (thanks to Mountain View), it's indisputably the "Go capital of the world." (This is true even if we look at the 50 highest-traffic cities rather than just the top 4).

This portrait of four major developer hubs is is just one of many ways Stack Overflow traffic can tell us about the global software engineers ecosystem. Whether you want to understand developers, hire them, engage them, or make your own developers more efficient, we have solutions to help you solve your problems. Check out Developer Insights to learn more.

For the last two years, we have contributed data on developer trends across Europe to The State of European Tech Report, created by Atomico and Slush.

The way we captured the developer trends data changed this year as we rebuilt our data analysis platform called Providence. Providence is our machine learning platform that tracks user behaviour on Stack Overflow. It analyses the questions and answers that users interact with, in order to determine what sort of technologies an individual works with. (If you'd like to see your own Providence record, you can access it here.)

The improvement that has had the most dramatic impact is the way the system registers individuals visiting Stack Overflow, making the counting of developers much more precise. Like all systems, the longer it runs, the better it gets. We fine-tune it over time.

Fine-tuning the system

The result of all these improvements to Providence is that the the Stack Overflow data within this year’s State of European Tech Report looks like a sharp increase on last year’s figures. This is not because there has suddenly been a surge in the developer community, however, but because we are no longer comparing data sets captured in the same way — put simply, we aren’t comparing apples with apples.

An analogy would be that last year we were counting developers who visited the site as if we were counting the number of diners in a restaurant by the number of people settling a bill. In fact, there are often lots more people dining in the restaurant, so we've improved our way of counting to ensure all developers (or diners) are included.

Having fine-tuned Providence, we’re excited to reveal that the number of developers in Europe and indeed other parts of the world, is in fact much larger than we originally thought.

For the technical details for some of the early rebuilding of Providence and the kind of issues that arise building such a complex system, read on.

Probability to precision

We started building Providence in February of 2014. Originally we focused our efforts on analyzing our traffic data to better match developers to jobs listed on our Talent platform. The systems and data that resulted from those efforts eventually lead to our ability to map the developer landscape in terms of geography and specialization.

Tens of millions of questions are viewed (by many millions of developers) on Stack Overflow daily. To properly analyze the many weeks worth of data that are required to build a global understanding of the developer landscape, our early system took a probabilistic approach — sampling our data to ease computational requirements. In the last year we have moved away from probabilistic approaches to more precise ones. While these new approaches required more engineering effort, they reduced variability and increased precision in the final results.

Our systems also draw a distinction between "professional grade" developers and hobbyists, students, or other dabblers; including the former while excluding the latter. Our initial versions made some very conservative assumptions, as is the norm when beginning an analysis, essentially requiring a person be "professional grade" and be specializing in one or more of a few dozen technical topics. Our notion of “capable of working as a professional developer” has been improved in the last year — becoming less conservative naturally — resulting in a more accurate count of developers in a region.

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.