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

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

Introducing the Stack Overflow salary calculator

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

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

What we hope

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

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

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

Work in progress

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

The experimental details: 75% more clicks

(By David Robinson and Bret Copleland)

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

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

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

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

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

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

Try the Stack Overflow salary calculator...

Further reading

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_{(emphasis mine)}

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

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

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

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

Ready to help?

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

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

All users who contribute to Documentation the next four weeks:

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

Let's go build this thing together.

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

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

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

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

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

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

Happy data diving!

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

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

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

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

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

So what's next for Stack Overflow?

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

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

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

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

About the Stack Exchange Data Explorer

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

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

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

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

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

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

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

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

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

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

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

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

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

Source

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

A Little Context

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

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

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

Optimize for presence

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

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

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

Question-driven

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

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

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

Talk-show host

That said, we want to tease out conversations.

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

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

Managers like to talk

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

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

Every team is different

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

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

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

View the full post at kevinmontrose.com...

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

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

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

We started our story with three issues in mind.

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

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

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

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

А few facts:

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

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

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

What People Are Saying:

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

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

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

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

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

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

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

– ModaL

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

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

– Rakzin Roman

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

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

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

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

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

– Suvitruf

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

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

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

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

How We Do Hardware

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

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

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

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

View the full results here.

Key Findings on Technology:

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

Key Findings about Developers at Work:

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

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

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

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

How Does Your Company Determine Compensation?

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

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

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

Stack Ranking: Upsetting Developers Everywhere

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

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

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

Why Stack Ranking Sucks

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

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

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

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

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

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

My Personal Experience With Stack Ranking

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

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

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

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

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

How to Properly Review & Compensate Developers

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

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

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

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

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

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

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

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

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

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

Make Compensation Transparent

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

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

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

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

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

Follow David Haney on Twitter at @haneycodes

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

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

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

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

It's as simple as that.²

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

Footnotes:

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

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

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

First: it’s hard

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

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

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

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

Smart and Gets Things Done

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

Mostly Remote

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

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

A conversation, not a quiz

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

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

Fairness and comfort

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

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

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

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

Decisive

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

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

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

Mitigating subjectivity

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

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

When the answer is No

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

OK, now tell me about the interviews...

Sure thing. Watch the video above.

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

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

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

What’s the deal with ad blockers?

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

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

Ads at Stack Overflow

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

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

We don’t care!

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

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

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

The Value of Valuing User Experience

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gaming wins the title of most viewed question with:

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

The top voted answers?

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

The top posts by anonymous feedback:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Who Wore It Best?

Most of the fun of Winter Bash is, of course, seeing the actual hats on avatars. So let's kick off with some pictures!

And a very honorable mention to Role-Playing Games SE's BESW for taking the Timey Wimey hat and really running with it!

Numbers, We Want Numbers!

The most commonly awarded hat this year was, of course, Every! Body! Gets! A Hat!, the hat that was automatically given to all Winter Bash participants on a site once any 20 hats were unlocked on that site. A total of 99,388 of them were distributed across the network, to 70,103 unique users. Sadly, that means the hat didn't quite live up to its name, and a couple thousand people did not get to look like Oprah… or sport fabulous mustaches, like this fancy gentleman:

Congratulations to Mathematics SE for being the first site to unlock this hat, less than 18 hours into the event! Also to Code Review SE and Blender SE for technically needing only three users each to get this hat (i.e. at the time that the hat was earned, one user had 16 or more hats, and two other users had enough hats that the first user didn't, filling the number up to 20). The biggest "team efforts" occurred at Aviation SE and English Language Learners SE, on each of which ten users came together to get the site past the 20-hat mark. All in all, 90 communities managed to "get Oprahed."

Not surprisingly, the next-most-common hats were "participation hats," given for doing little more than showing up on a given date: A New Hope was earned the most total times, at 35,329, but Sufganiyot was earned by the most distinct people, 27,050. The most common hat for an actual achievement was Cerro de Potosi, with 21,720 awarded users for earning silver badges; fortunately, our badges don't require any destructive real-world silver mining. Actually, more people earned silver badges during the event than visited on Christmas; Cerro de Potosi edged out O Tannenbaum, which was earned 20,104 times.

Many Explorers (4285, to be exact) used Winter Bash as an opportunity to venture to new sites, where they were welcomed with upvotes by the natives. Some 1994 of those natives may have been designated Greeters as a result.

On the other end of the spectrum, the rarest non-secret hat was Living in the Future, which only 42 people earned, and nobody got more than once. It was doubly challenging, requiring users to have learned enough to solve their own problems and preventing them from custom-designing questions for the purpose of the hat by requiring the question to predate Winter Bash.

People were much more likely to close questions than to reopen them, with 10,015 Melpomenes going out compared to just 1556 Thalias. However, given that the only questions that can be reopened are those that have been closed in the first place, and that many closed questions never get improved to a point where reopening is appropriate, that's not a bad showing.

While many users enjoyed playing along casually, there was a strong corps of "power users" as well, as evidenced by the numerous awards of Specialist Hatsman (earned 1911 times, for earning 11 other hats; a play on "specialist batsman" from the game of cricket) and Fan-hat-ic (earned 20,469 times, for visiting on ten consecutive days; a play on our badge "Fanatic").

Do You Want To Know A Secret? Do You Promise Not To Tell?

Well, actually, at this point, you can tell. There were a total of 13 secret hats this year (or 14 if you count the white and blue Flip Flop variants separately… which is highly recommended, because it results in an even 42 hats for the year).

The first one awarded, and first one the community figured out the trigger for, was Odinson. It ended up being awarded 1817 times, and was triggered by closing a question as a duplicate using the "dupe-hammer" privilege or voting to close a question as such that was later closed by hammer.

The first user to correctly explain Odinson was Undo. In doing so, he earned himself a second secret hat: Archimedes, the hat given out for correctly identifying another secret hat's trigger. Veteran Winter Bashers may remember it being called Eureka in past years. This year's only manually awarded hat, it was earned by 18 people.

Next to fall was Hairboat's Revenge, which was given to any user who replied to everyone's favorite Community Manager, Jon Ericson, by answering one of his questions, commenting on one of his posts or replying to one of his comments. A total of 516 users did this, and it was apparently so fun that many did it on multiple sites; the hat was given out 614 times.

Soon afterwards came 007, for posting an answer that received 0 comments to a question that had 0 comments and reaching a score of at least 7 for the answer. A simple reward for posting a good, clear answer to an equally clear question, it was awarded 402 times.

The final secret hat to be deciphered on day one of the event was Sun Wukong, for posting a meta question or meta answer that attracted at least five upvotes and at least five downvotes. It was a lightweight test for a moderately popular old badge request, and it was given out 165 times.

Day two kicked off with a team of users solving Amazing Grace, another nod to one of our favorite people. By asking a bug-tagged question on a meta site, scoring at least 10 and attracting an answer that also scored at least 10, users could make themselves look like Admiral Hopper. This was one of the rarest hats, as only 30 people earned it (32 total times).

Returning to the realm of fantastical headgear, users could get It's Over 9000! for racking up a total of 9000 views across all of the questions they asked during Winter Bash. This turned out to be another hard one; only 48 people did it, and nobody managed it on more than one site.

After that, things quieted down until Friday, when It's Always 5 O'Clock Somewhere first appeared. It was awarded for asking a question at exactly 5:01 pm on Friday, though it didn't have to be 5:01 in your local time zone, just at some standard time zone currently in use in the world. It was earned 170 times, by 167 users.

That was followed by another break, and then the arrival of the Flip Flop hat(s), triggered by posting or voting on Dec. 22 (the solstice). As expected, it was a pretty common one; 17,531 users got the blue and black version (13,489 distinct) while 17,446 got the white and gold (13,112 distinct).

It took until nearly the end of the event for three more secrets to be cracked. Flying Tiger was a successor to last year's Red Baron. The original trigger was to find a question with a score of -3 or lower, post an answer that reached a score of 5 or better, and bring the score of the question up to 3 or better. This year, the trigger was the same, except that your own votes didn't count. Because of the natural difficulty of the hat and the late date at which the community realized the trigger, only 11 were earned (all by different users), making this the rarest hat in the history of Winter Bash!

Next up was Cleanup Crew, which probably produced a greater variety of trigger theories than any other hat this year. It was earned by deleting ten of your own comments that were left under someone else's post, before the author edited the post. In the end, the crew was 195 users strong, though a few of them pulled duty on multiple sites, bringing the total hat count to 198.

The last hat to be successfully solved, Edward Edwards, was awarded to users who won a bounty even though a competing answer had already met the criteria for the bounty to be automatically awarded. This was another uncommon hat, with 47 going out to 47 people.

And now, what you've all been waiting for: the mystery of the Onion Knight, revealed! This hat sparked debate almost immediately, with most people split between whether it referred to the Final Fantasy job class or the Game of Thrones character (and a couple people piping up for a Dark Souls NPC). Who was right?

None of them! A hint midway through the event directed guessers to focus on the word "onion," but it probably should have done a callback to 2009 and prodded them to do so "as a programmer." The hat was meant to make people think of Tor (now a proper name of its own, but originally an acronym standing for The Onion Router), and evoke the concept of anonymity. Users who received the Onion Knight hat posted questions that received at least three anonymous feedback pseudo-upvotes from visitors who did not have full voting privileges on the site. There ended up being 369 Onion Knight hats, awarded to 361 distinct users.

Mad Hatters

Finally, even though it's not a competition and the points don't matter, this post couldn't be complete without declaring some winners. This year, nobody earned all of the possible hats, but three people tied for "most hats" at 39 each:

Thanks to everyone who got involved for another fun year!

For those who are especially interested, I've posted additional statistics and analysis on Meta Stack Exchange (along with more screenshots).

Here's to a great 2016!

We've been doing this since almost the beginning of Stack Overflow; and still, when the call goes out to our Moderators — "Make your charity selections now!" — the outpouring of enthusiasm for giving back grows stronger with each passing year.

It is a precious gift to have the means of helping someone who desperately needs it. Whether it's an organization providing clean water, a warm blanket, or a light in the dark for families fleeing violence; these charities make it possible for another year of school in a war-torn country, while others are defending our very way of life. There is a lot of emotion and heart-felt concern in deciding which causes most need our help each year. And when violence rocks our biggest cities and millions of refugees have nowhere to go, moderators coming together to "give back" takes on an especially meaningful tone.

But came through, they did!

This year, on behalf of the 483 moderators of Stack Exchange, we were able to make the following donations to charity:

And on behalf of our engineering and IT team, we also like to remember the organizations and tools that make what we do possible:

We are immensely grateful for the incredible year we've had at Stack Overflow. Stack Exchange was conceived out of a crazy idea that people would be inspired to create and share information online in the spirit of peers helping each other — and to see that kind of passion spill out into the real world to help others overcome real adversity is truly heart-warming.

With the holiday season upon us, it is a good time to reflect on what we've accomplished this year. With almost 100 million users visiting us each month, we are literally changing the way people work and learn. Our fellow community members are generously contributing their time, their passion, and their leadership to make these sites worth visiting and participating in.

So as we enter this new year, let's tip our glasses and make 2016 the year to share in our good fortunes. It's a year of new beginnings… so set aside some time to learn something fun, take pride in what you do, work because you love it — and most of all… enjoy!

Cheers!

We believe that all programmers need and deserve jobs they love. Last week, we added a Jobs tab to Stack Overflow in order to help you do just that.

What’s changed?

You’ll no longer need to login to a separate account on a separate site in order to use Stack Overflow Jobs. This means that the family of products we’ve built with the goal of improving programmers’ lives - Q&A, Jobs, and soon-to-be Documentation - will live side-by-side on Stack Overflow.

Tim has already summed up the problem that this decision was designed to solve:

Many of you reading this have great jobs that you love, but many more do not, and don't realize that Stack Overflow has a product that could help get them a much better job. Some might have poked at it, but got lost in the hassle of having to sign up all over again and tell us things they thought we already knew about them.

I already have a job I love. Why should I be interested?

You don’t have to be. In Tim’s words, this is our attitude toward bringing Jobs to Q&A:

It's all there when you need it. For many users, it should be a lot easier having all these things in one place. For those who only choose to use Q&A, or Docs, the rest will be waiting patiently out of the way.

If you are interested in a new job - and based on an experiment we ran earlier this year, we learned that 40% of you are - we’d like to help you. Because even though the demand for skilled programmers is on the rise, only 1 in 3 of you told us “I love my job.”

In the last few months, we’ve focused our efforts on several key features designed to help you land the job you love.

1. Better job matches

About a year ago, we began a long-term experiment that used our machine-learning technology to surface more interesting jobs to our users. This drove a 40% increase in overall applications, which was awesome - it meant that we were making it easier for you to find and apply to jobs you found interesting.

This experiment taught us that we can help the programmer community by showing relevant jobs without asking anything of the user. But how could we make the experience even better? What about specific criteria that you’re looking for? How could we better empower you in your search for not just a job, but the right job?

We believe that we can serve up even better jobs if we allow you to define your own preferences for important things like tech you’d like to work with, where you’d like to work, and desired compensation. Our matching algorithm uses this information to sort the latest jobs for you, putting the best matches on top.

To start seeing jobs that match your criteria, just login and visit the “matches” tab.

2. Better job listings

Last year, we asked you what you care about most when looking for a new job - and this is how you responded:

We’re working hard to get more companies to provide this info in their job listings. So far, we’ve focused on tech stack - and today, about 80% of our jobs offer tech stack data. Now we’ve set our sights on compensation. Currently, about 30% of our job listings provide compensation data - but we’re working hard to bring this closer to 100%.

3. No recruiter spam

If you’re a programmer, you’ve probably never tweeted this:

Because chances are high that you’ve received a message like this:

My associate forward me your contact info. and the hiring VP of Engineering is interested in your technical background for a senior position. The company I’m working for is very successful, profitable and well funded by several top VCs. Also can you please email me your current resume in word so I can forward it to the hiring VP of Engineering so he can review it, the resume he has is a bit dated... The compensation is excellent with great stock options, bonus, 401k and comprehensive package. I can call you with all the details on the position and company, please let me know the best # to call you at.

We’ve taken a few measures to help ensure that Stack Overflow users only receive personalized, high-quality messages from companies - and of course, only after you’ve given us explicit permission.

1. Our Job Search Status feature gives you full control over who is allowed to talk to you, whether you want to hear from companies right away or not at all.

2. We limit the number of outstanding messages that a company can send. This feature helps us control generic, copy-and-pasted messages to candidates, while encouraging companies to send messages that are relevant to the unique interests and background of each user.

3. We refund company subscriptions when we receive reports about bad behavior, and all of our job listings are required to disclose a company name. Furthermore, we seek out opportunities to work with developer-friendly companies that would be appreciated by the Stack Overflow community.

Okay, but how does this affect Q&A?

As Jason neatly summed up:

That ^ is about the extent of the changes to existing Stack Overflow. There's nothing else changing about Q&A. We aren't going to put jobs that look like questions in the middle of a question list, or jobs that look like answers in the middle of the answers for a question, or any other dark pattern garbage. The Jobs tab will be there for you should you need it, and otherwise Stack Overflow is essentially as it was.

We also won’t start hassling you about things that aren’t relevant to your interests. That means we’ll only push relevant Jobs content to users who’ve indicated to us that they’re interested in looking for a job. For everyone else, it’s there when you need it.

Stack Overflow Jobs is now live

Each of us has a different dream job. Some of us want to work quietly from home; others want to build products in offices filled with colleagues and free perks. Some of us want to make more money, while others want to push the first line of code on a product that will eventually be used by millions. Whatever it is that you’re looking for, we hope that your search starts with Stack Overflow.

Starting now and going until the end of the day on Jan. 3, 2016, you'll once again be able to earn and show off hats for all sorts of things you're already doing across the Stack Exchange network. As in previous years, we're rolling out an all-new array of hats for this year's event. (For those who are wondering, this is entirely because we on the SE team love our communities and think you deserve the best, and not at all because we forget where we store the old hats every year.)

That means we owe another big thank you to amazing freelance designer Elias Stein, who deftly handled the conversion of all hats from crazy vague concepts into beautiful digital reality for the third year in a row, and our very own unicorn lord balpha, who once again worked tirelessly behind the scenes to perfect the hat distribution process.

Hats, for those who don't know, are sort of like badges, but better, because you can "wear" hats on your avatar, displaying them wherever your avatar appears, network-wide! (And thanks to a labor of love by Brian Nickel, that includes the iOS app this year!) The triggers for hats are a little different than the triggers for badges; to find out what you have to do to get some headpieces, check out the Winter Bash mini-site. There are 28 total hats you can earn over the next few weeks… that we're telling you about. How many secret hats are there this year, you ask? You're on your own. We're not spilling the beanies.

After you've earned some hats, you can visit your profile on any site to choose the hat you want to wear (or simply admire your own personal hat rack). Just click on the bobble hat adorning your badges section to bring up a dialog.

(No, you can't wear the bobble hat yourself. Your badges would get cold!)

Once you've picked a hat, you can resize and reposition it in the selection window to suit your avatar. Last year's example image for this was so perfect that it just has to be reused:

Finally, you don't need to worry about tracking all this stuff yourself. You'll get notifications about new hats via a special, Winter-Bash-only top bar inbox: .

Of course, if you think all this is weird and don't want any part of it, that's okay, we won't judge you (much). You can opt out of the event by clicking on the snowflake icon in the top bar——and then the "I hate hats" link at the bottom left of the box that pops up. (NB: the reverse is true on Stack Overflow; fans of hats on SO will have to go through the same procedure but click a link to opt in at the end.) You're welcome to change your mind about wanting hats at any time during the event.

Just remember, all the hats will vanish again after three weeks. Now go! Other people out there are already working on their degrees²!

1: As in the past, tradition defeated accuracy in the naming decision. Hopefully some of our summertime audience will be at least partially mollified by the fact that the Winter Bash site will be available in Portuguese, Spanish, Japanese and Russian this year, thanks to the efforts of our international Community Managers.

2: The University of Winter Bash has not been accredited by any organization recognized by the Council for Higher Education Accreditation or the United States Department of Education. Yet.

In part 1 of this blog post I talked about getting a better job by building awesome stuff. In this part, I'll talk about how to communicate your awesomeness.

Write for humans

Applying for a job normally involves writing a cover letter and CV. The whole process can feel very impersonal - filling in online forms, typing words onto a screen, hitting the Submit button and maybe never hearing anything back. Yes, it sucks. But remember where your words will go, as you send them off on their journey. They will be read by another human being.

Sometimes I've seen people applying for a job who must have thought that their cover letter and CV would simply be fed into some kind of computer that would check their skills off against a list of requirements. While it's true that some companies have systems which automatically check your CV against a list of keywords, you don't want to optimise your job application for their simplistic software.

Software is not going to get excited by your CV, but a human should. Unfortunately, human beings are flawed - they sometimes come to irrational decisions, they are clouded by emotions, and they get bored. Humans like stories.

So tell your story. You want to make that person on the other side interested in who you are. You want to make them excited because they've found a promising candidate for the job they're trying to fill. You want to give them a clear idea of what you're all about. You want them to be on your side.

Who are you?

I've been involved in recruitment a few times, both at Stack Overflow and elsewhere. When I'm reading your cover letter and CV, I'm trying to answer one question - "who are you, and why should I care?". It might sound harsh but that's what it ultimately comes down to, especially when you have a big pile of applications to go through.

There is no "correct" way to write a CV or cover letter - you can read lots of advice about structure and formatting, but the sole purpose of these is to answer the question. If you fail to answer it, you'll have a hard time getting a great job.

To answer it, you need to communicate a story about yourself. Who are you? What have you done that's interesting? What excites you about the job you're applying for? How can you convince somebody that you're capable of doing the job?

It's a story about you, so write in your own voice. Don't waffle - anything that doesn't add to your story only detracts from it. Get to the point and keep it simple.

You want to leave the reader with a clear, convincing message. They should be left with a clear feeling that you're obviously a great candidate for this position.

What we're looking for

So, what things should be in your story?

At Stack Overflow, when we hire developers, we're looking for people who are passionate about coding, have an appropriate level of experience (both breadth and depth), and who Get Things Done. Other companies will have their own criteria, but if you're the kind of person who is smart and gets things done, and you want to work with other people who are smart and get things done, then your cover letter and CV should be all about that, whichever company you're applying for.

How do you convince us you've got what it takes? We want to see that you're passionate, experienced, and get things done, so you should just say that, right? Wrong. You don't get to inject thoughts into people's heads just like that. You have to give us the evidence that leads us to that thought. You want us to come up with the thought ourselves. If you tell us what to think, it's not just patronising but boring.

Here's the kind of thing people write in cover letters all the time:

As an outstanding senior-level software engineer with over 8 years of experience using Microsoft technologies, I believe I possess the skills, qualifications and vital experience necessary to make a very profound contribution to your business operation. In my current and previous roles I have delivered substantial improvements in creating high quality systems and streamlining operations, resulting in improved revenue, increased profits, and a high rate of client satisfaction.

This is just tiring to read. And it doesn't even say anything! There is no actual information in there, just a list of things this applicant wishes us to think. Tell us an actual story, give us the evidence, and let us come to our own judgements. If I read something that makes me think "this person must be really passionate about coding", that's a lot more convincing than simply telling me you're passionate about coding.

It all boils down to that classic writing advice - "show don't tell".

Be interesting

Chronology is not the most important thing, so you don't need to start at the beginning of your story. I often see people start cover letters with things like:

I started computer programming 18 years ago as a hobby ...

Sure, this is the first thing that happens in the story, but it's not the most important thing, and it's not a great hook. You know how movies tend to start with something exciting happening, and then fill you in on the background later? Try doing that instead. Hook me in with something interesting and unusual about you. A lot of programmers started programming as a childhood hobby, so lead with something else.

Don't waste time on things we already know

Another common way people start cover letters:

I recently came across your job posting on your company website for the “Full-Stack Web Developer” position. After reviewing the details of the position I found that the requirements necessary and my experience could be a great fit if given the opportunity.

This doesn't tell me anything at all. It's even less interesting than why you started programming - you're just telling me you're applying for a job. I knew that already. You think you fulfil the requirements of the position - well, of course you do!

Don't waste time on things we don't care about

There's no need to give us your complete life history. One applicant included this on their CV:

Drove dump Truck, operated machinery, all manner of physical construction work.

What did they think they were adding by giving us this information? You don't need to include every detail of every job you've ever done. You don't want to distract from the overall story you're telling.

An example

Here's an example of a cover letter that worked - it's my own, from when I applied to work at Stack Exchange almost two years ago.

Looking back at this now, what's interesting is that it's not brilliant. At all. In fact it's embarrasingly short - I clearly didn't spend as long on it as I should have. However, it does demonstrate the points I'm making. The first sentence just gets straight to the point, saying who I am and what I'm all about. There's a link there to all my open source code so anybody can go and look through that. It explains why I'm applying now, to this company, and why I'm excited at the opportunity.

Completing the cycle of awesome

That's it! In part 1 of this blog post, I talked about breaking into the "cycle of awesome" by building awesome stuff. If you build awesome stuff, it's a lot easier to tell people how awesome you are. You're much more likely to be passionate and excited about stuff you've built yourself, so it's actually easier to write your story - it's much easier to write about things which you care about.

Now you can complete the cycle, and find your way to an awesome job. It's not the easy way - there is no easy way to be awesome - but it is possible, and you can do it.

By the way, we're changing everything. We should talk about that! First, let's review: you may remember how the last time we had a podcast, we talked about Documentation. It's now in private beta, and you can sign up.

So here's the new stuff: we're working on something we're calling integration, or possibly unification. The legend has it that once upon a time, Stack Overflow was invented, and so was this bolted-on Careers site where programmers could get jobs. But they were two separate things, and if you wanted to get a job through Stack Overflow, you had to go to a whole different website and make a whole different account. Our unification project will move all of that stuff back into the Stack Overflow fold, making it an unobtrusive part of your day-to-day experience on the site. (Which you can just ignore if you aren't looking for a job.)

We asked a sample of people signing up for Stack Overflow today if they were actively searching for a new job, not searching but open to opportunities, or not interested in jobs at all. We found that of those who answered, 23% were actively looking for jobs and 38% were open to opportunities. (There's a point here, but we digress to talk about Twitter's new hearts.) Oh, here's the point: 61% of new Stack Overflow sign-ups might be interested in the right new job. What all of this means for the average Stack Overflow user is that you no longer have to bother to keep a second profile on a separate site. Oh, and if you're at all interested in finding a new job, we want to be able to help you look for one in--here's the kicker--a way that isn't awful.

We've been thinking about ways we think we can continue to help help make developers' lives easier. We're not about programming on a boat or making designer shoes for programmers. We're just about helping programmers learn, improve, and share their knowledge, and that's why Documentation and Jobs feel like natural fits into what we're already doing well with Q&A.

[Producer Alex is now eating delicious seaweed snacks. Further bulletins as events warrant.]

So! By now we've talked about integration a little bit on MSO. We're trying to take the pain out of the Jobs piece as quickly as possible while we're building out these other features.

But wait. Joel makes an excellent point: why are we working on all of this new stuff instead of going back and fixing all of the problems with Q&A? Well, the answer is... why not both? Let's be clear: this is not about any shift in our focus on Q&A. Q&A is the thing that we're confident that we've done really well, and it's what our community is built on and uses to teach a new generation of programmers in a new way. Q&A is the killer feature, and it will stay that way. You know what? Just listen to David for this part, because my attempts to summarize his impassioned monologue are coming off cheesy and/or arrogant, and he's really nailing it. (Don't tell Jay I complimented David; he'll kick me off his team.)

Okay. Moving on! Teams is in private beta and you can sign up to participate if you want, or just check out the teams that have already signed up. (So far, NetGuru is winning the non-competition.) Tune in for more Teams talk. We're gonna get a lot of stuff wrong at the beginning, like we always do, so we look forward to community input on how Teams should evolve.

Here's the post Joel is talking about when he says "Harley Davidson Bike Buckle" a bunch of times. Also, Joel is a hypnotist. Also, we're done now, so thanks for wasting another hour of your life listening to the Stack Exchange Podcast!

For hiring developers or for developers looking for jobs, we’re able to show jobs to the right developers based on the content they look at on Stack Overflow. This behavioral targeting is more accurate than profile-based targeting, and something that Stack Overflow can uniquely do to provide the best experience for both candidates and recruiters.

When you post a job on Careers, we show the job on Stack Overflow, the world’s largest developer community. There are lots of different kinds of developers out there. Providing us with some descriptions of the kind of developer you are looking for helps us advertise directly to the right people for your company.

The targeting screen

On the targeting screen you have a few options for how to describe the role you need filled.

Developer types

Developer Types is the most general role: “Full Stack Developer” and “Mobile Developer” are examples. This is the most impactful feature you can select. Although two selections are allowed, you are almost always better off just choosing a single option here. Only if your job requires developers to be very proficient in multiple roles will two selections help. If your job sees a second role as a benefit or you are willing to train for it on the job, selecting just the more important one will help find more qualified candidates.

Technology ecosystems

In this category you will find stacks or collections of technologies that roles might require. You might have heard someone say “I’m a Node developer,” or “I’m an Android developer.” They are describing the set of tools with which they are most proficient – and we can target that directly.

In addition to ecosystems, there are many complementary tools listed in here such as “SQL Server” or “Cloud.” While these are not the primary stack, they are helpful to know. Selecting any choices that apply here is encouraged.

Region

This allows you to specify the list of countries in which we should advertise your job. We only show your job to developers in these locations. Developers browsing Stack Overflow from anywhere else will not be able to see your listing and we will not show ads for your job to them. Use this if you are looking to recruit developers from specific countries.

Potential targets

As you modify these high level targeting features, you will see the Potential Targets widget on the sidebar update. This number is a rough estimate of the size of the market for developers you want to hire based on your targeting criteria.

In this expanded details view, you can see a breakdown of the market. Total targets are the developers in the area around your Targeted City. Close matches are the developers who match any of your targeted criteria, and strong matches are the developers who match most of your targeting criteria.

If the number of Potential Targets drops too low (depending on location, there are just very few developers in some of the more remote areas of the world), then you are made aware of that up front with this tool. You can alter your targeting criteria or consider offering flexible work options such as allowing remote workers to increase the size of your targeted market.

How we know

Nearly every developer in the world uses Stack Overflow to find solutions to the coding problems they encounter in their daily lives. That’s important. Stack Overflow sees what developers actually use, not what they say they use on resumes and online profiles. There are no other companies in the world with direct access to this quality and quantity of data on developers.

Our advanced targeting technology makes use of this data to determine the tools and roles each developer is proficient at. As developers use Stack Overflow, we show them ads matched using your job’s targeting criteria. Targeting your jobs leads to more qualified candidates applying to your job as well as a better, more relevant experience for Stack Overflow users.

The panel was formed when a group of employees noticed that conversations were happening all over the company about diversity, or the lack thereof, both at Stack Overflow and in the tech industry. We wanted to consolidate the discussions and efforts to get everyone on the same page and make a bigger difference. DIP’s Google Group and monthly meetings served this purpose for quite some time before we decided it wasn’t enough. The conversations that we were curating were too valuable to keep to ourselves; the entire company deserved to be part of those conversations if they were interested. We needed to create a comfortable space for everyone at Stack Overflow to be able to engage with each other on diversity issues.

Our Experiment

Roughly once a month, we host a one-hour chat in our company-wide chat room to candidly and respectfully discuss diversity. It’s 100% internal and only for employees who are interested in participating. The chat is structured with 1-3 volunteers, who are arranged ahead of time, starting our discussion by sharing personal experiences related to diversity. Anyone can ask questions, offer support, share their own experiences, or simply observe. We chose our existing chat room because we wanted to meet people where they were already talking and eliminate speaking over each other. It would also allow us to save the conversations as artifacts that employees could read after the fact if they miss the live chat or want to re-absorb the information.

I know the idea sounds risky. How could that possibly work? People would either be too timid to say anything of value, or make everyone super uncomfortable by oversharing, or even worse, begin to brawl in all caps. I wouldn’t even be surprised if someone cried. And this would all be in our chat history, never to be deleted.

Spoiler: none of that has happened. The conversations have been productive and civil; the volunteers have been open-minded and allowed themselves to be vulnerable, while other participants have asked questions, offered support, and shared different perspectives. In several instances, people responded with things like, "WHAT??!! Really? I can’t believe that happened to you!" or fervently agreed that they had experienced something very similar. People have even been brave enough to ask if their own behavior was perpetuating the issue, and asked to be called out if they did something that bothered anyone.

What We’ve Learned

By no stretch of the imagination do I think this would be a good idea in every workplace. Stack Overflow seems to be just the right size with the appropriate tools to make something like this work. Furthermore, people were at least willing to give it a try, and kept open minds. So we had the means to make it happen, and I think we also found a formula that heavily contributed to it being productive:

Focus

Each chat has a topic, like English as a Second Language, LGBT, or Parenting/ Work-Life Balance, that we discuss within the scope of working at Stack Overflow or in the workplace in general. By keeping the focus small, we are able to dig in deeper. We also have a moderator to make sure things don’t derail by slipping off-topic or becoming toxic. (So far we have not experienced the latter, but I will concede that we have been guilty of the former.)

Respect

There is a lot of respect amongst peers here. I firmly believe that this idea can only work if people trust each other enough to make themselves vulnerable — there can be no hostility whatsoever. We also follow the same Be Nice Policy that we practice in our communities, and keep everything 100% internal.

Vulnerability

The real secret sauce, though, is that our volunteers share (very) personal experiences. By giving firsthand accounts of dealing with bias, they are bringing the issue close to home — it's a lot easier to have empathy for experiences that are different than yours when they come from someone you care about personally and respect professionally, especially when they are putting themselves out there.

Impact

I don’t think DIP Chat is a silver bullet. We haven’t “fixed” diversity at Stack Overflow by any means, but it is doing us some good. Employees from different parts of the company — and all over the world — are learning from each other and strengthening relationships in a way that previously wasn’t available. For me personally, DIP Chat has changed the way I think about myself, other people, and our responsibility to each other.

The real reason that I think that this is working for us is that the heart of Stack Overflow is asking and answering questions. We are professional lovers of sharing knowledge, and this spirit extends beyond our Q&A sites.

Having no idea what reaction the program would invite, we had an astounding 375 applicants from all over the world. With the program open only to those living within the New York City area, 221 students were accepted. 110 students went on to complete the course requirements, which included attending 5 out of 6 classes and passing the project-based homework assignments. Prior hard coding/design experience was required for this program, as the focus was instead on mentoring, training, and confidence building.

The Knowledge

In collaboration with the New York Tech Talent Pipeline, Beyond Coding included courses from Stack Overflow, Crest CC, Foursquare, Kickstarter, Tumblr, and Trello. Speakers from each company (be they developers or recruiters) shared insights and practical knowledge that they themselves wish they had known when starting out careers in the tech industry.

Each course was catered specifically to developers and aimed to increase overall confidence; they included perfecting elevator pitches, business networking, learning how to find new resources on the job, working with data, technical communication best practices, and tech interviewing tips. The classes were designed to be highly interactive by encouraging students to discuss their ideas and projects and solicit feedback from one another.

The Students

We couldn't have asked for a better group of students to spend the next few months with. They came from a diverse range of backgrounds and genders - 69% identified as male, 31% identified as female. Each student came to Beyond Coding for a different reason. We met graduates, career changers, self-taught techies, and part-timers looking for full-time roles just to name a few.

At the beginning, confidence was on the lower side, with 30% of students stating they were not confident in their ability to get hired in a technical role. At the conclusion of the program 90% of students were confident they would be hired or had already accepted a job offer.

Students were highly encouraged to utilize social media outlets such as LinkedIn to present their coding skills and qualifications and create a professional online presence. On Twitter, you can check out #beyondcodingNYC student conversations and photos.

The Hiring Fair

Hosted at AppNexus, the Hiring Fair was held on September 9, and was open to employers hiring entry-level technical roles. Participating employers ranged from large corporations such as Morgan Stanley, American Express, NY Times, and HBC Digital, to local start-ups including App Partner, Decoded, and Percolate.

Over 80 students were in attendance, with around 20 students gaining “Early Bird” access by consistently attaining high marks for their homework projects. The evening was a great mix of networking, resume reviewing, and getting to see students confidently engage with employers.

The End Result

The program caught the eye of BRIC TV, a Brooklyn arts and media nonprofit, who have created this fantastic video overview of Beyond Coding and the Brooklyn Tech Triangle Internship Program, whose students were required to attend all Beyond Coding courses.

Each student who completed the Beyond Coding program should be proud of the hard work and late nights they put in. We’ve been impressed with the caliber of everyone involved and can’t wait to hear about the new roles and internships that will be taken on in the coming months.

I'm lucky enough to have what I consider to be an awesome job - I'm a web developer on the Stack Overflow Careers team. I've been working for here for 18 months now and I still love it.

This is unusual for me - in the past, the honeymoon period for my jobs has been short, and after only a few weeks I've been sick of them and dreaming about the next thing. But here at Stack Overflow I'm doing work I believe is important, it's exciting and challenging, and I'm surrounded by wonderful smart people.

So if you're currently stuck in a non-awesome job, how do you upgrade? Note that I'm not necessarily talking about how you can get a job exactly like mine - this is about how you can get a job that is awesome for you.

The cycle of awesome

I have a theory. My theory is that having an awesome job is part of a self-fulfilling cycle, which I like to call the "cycle of awesome".

The cycle works like this:

• If you already have an awesome job, you get to build awesome stuff.
• If you've built awesome stuff, you can show people how awesome you are - "look at all this awesome stuff I built".
• If you can show people how awesome you are, you can get an awesome job.

This is the self-perpetuating "cycle of awesome". If you can break into the cycle somehow, you're set. But what if you're outside the cycle, in a crappy job building stuff that sucks?

Stuck in a trap

Five years ago my day job was working on a large Windows desktop app for fund managers, which was largely written in VB6. It looked very much like an enormous Excel spreadsheet, and I don't think a designer had ever been near it. The code was split across maybe 300 different projects, and the limitations of VB6 meant you could only ever load a small handful at once. It was the kind of "line of business" application that a small number of people absolutely depended on, but I doubt many of our users could honestly say they loved it.

The year was 2010, and we were using technology from 1998. To me, this was an emergency level of technical debt, but the management didn't see it that way. We had started building a few new components using .NET 2.0 (by 2010, only five years old), but this was only adding to the already enormous complexity of the application, and there was no sign of the fundamental VB6 foundations of the software being replaced any time soon.

Looking at the world outside the company, it was clear the way software was being written was changing. New applications were being written for the web and mobile, not Windows desktops. The company could not expect to keep acquiring customers, and hiring and retaining developers, if it carried on like it was still the early 2000s. But they had no desire to change.

I could possibly have coped with the glacial pace of technological change if the company had been a really great place to work. But it was the kind of heavily corporate environment bogged down with procedures, timesheets, pointless meetings, a dress code, locked-down PCs and heavily filtered internet (when Stack Overflow launched I had to put in a request with the IT department to allow access, which my boss had to approve).

So I was stuck in something more like the "cycle of suck". I was building stuff that sucked, my CV was not going to get any better, and so I was trapped in my sucky job.

Breaking in to the cycle of awesome

How do you break out of the cycle of suck, and hop on to the cycle of awesome?

There are three places in the cycle you can try to start, but I think there's only one that really works:

• Start at "Get awesome job"? Well yes, some people do get on the cycle here. Some people come out of university with great grades in Computer Science, they've done some impressive internships, they actually remember all that algorithms stuff, and they breeze through the interviews at a Big Famous Tech Company. Maybe in another reality I could have done this too. Unfortunately I did a degree in Physics, and instead of putting any effort into planning my career, I spent my summers working in supermarkets and packaging factories. That was all in the distant past anyway. I'm an entirely self taught programmer - programming had been something I only ever did in my spare time, right until I got that VB6 job in 2007.
• Start at "Tell people you're awesome"? Maybe you can get on here if you can talk the talk. It works for some people...
• Start at "Build awesome stuff". This. The great thing about being a software developer is the opportunity that most people in other professions simply do not have. You can build awesome stuff on your own. And there are loads of free resources to help you do that. It's entirely within your power to build awesome stuff and get it in front of other people. You can do it now, you can do it on your own, and you don't need to wait for your boss to tell you to go and do something.

Going it alone

So that's what I did - I decided to build some awesome stuff. In 2010 I quit my job and threw myself head-first into building the things that I wanted to build.

I'd been spending much of my spare time working on my open source project Quest, a system that lets non-programmers write text adventure games, and I knew that teachers were starting to use it in their classrooms, so I thought there might be some opportunity there to make some money out of it.

To be honest, quitting my job to focus on building a text adventure engine did seem kind of silly - but the iPad had just been released, and I was wondering if interactive ebooks might become a thing. If so then maybe I would find myself in the right place at the right time. All the best ideas are kind of hard to distinguish from ridiculous ones, and there was only one way to find out on which side of that dividing line this fell.

And that was really the extent of my "business plan" - I didn't think it through in more detail than that. It was more a case of "what's the worst that could happen?" And the worst case scenario didn't seem too bad - I'd quit my job working as a VB6 developer, but if I wanted another crappy developer job then it wouldn't be that difficult to find one. What I wanted was a good job, and the best way to find one was to increase my skills.

Being quite a frugal person I happened to have enough money saved up that, even if I didn't have any income for a year or so, it wouldn't be a big problem.

I made this

So I spent most of the next four years doing various things with Quest and interactive fiction:

• I finished my Quest rewrite, and kept on iterating with new releases, turning it from a Windows desktop application into a web app
• I massively expanded and improved my website, turning it into a hub for all kinds of text-based games
• I built a new product for schools using text adventures in the classroom
• I ran workshops in schools getting kids to create their own games
• I experimented with being a publisher, turning text games into mobile apps
• I wrote my own game which was an experiment in what a modern text adventure might look like
• I worked with writers and filmmakers on a project for a book publisher, building a promotional text game for a new sci-fi novel

I made small amounts of money here and there, with a larger amount of money from a few months of contract .NET developer work to top up my finances. Ultimately though, my money ran out.

I had failed to build a successful business, but I had spent years doing work that I enjoyed, and I now had a vastly increased set of skills and a much more interesting CV. I had built some awesome stuff - now I just needed to follow the cycle around, to tell people about it and try to get an awesome job. That's what I'll be talking about in part 2 of this post.

Just in case you think the only way to build awesome stuff is to quit your job and spend four years trying to build an entire business - you don't have to be as batshit insane as me. You can build stuff in your spare time - I still do, it just takes a little bit longer. Build something you're interested in building, something you can be proud of, and ship it. It's the best way to learn, and it's the best way to upgrade your CV.

Video

If you want a sneak preview of what I'll be talking about in part 2, you can watch my talk "How to be awesome" which this post is based on:

UPDATE: Part 2 is now available here

Usually, about two years into a job, I start dreaming of greener pastures with better pay and more interesting work. Working at Stack Overflow has been the exception to that rule. In the wake of the recent Amazon exposé and my 2 year work anniversary, I’d like to share some thoughts about what it's like working at Stack.

Some background: I am not one of the founding developers of Stack Overflow. By the time I arrived in August 2013, the core Question & Answer (Q&A) team (our most popular product) was well established; the site had been around for four years already.

On Turnover

During the two years I’ve worked at Stack Overflow, only three web developers have left the company. Of the three, two of them left to work on a startup, and one of them - Matt Jibson - went to work on a technology stack he was more interested in. The day he left, Matt tweeted:

Our lack of turnover speaks for itself.

On Continued Employment & Trust

During my two years at Stack Overflow, I have gained a solid understanding of its many facets. I've learned about our mobile apps, our core Q&A product, our technology stack, the Stack Overflow Careers product, and even sales. However, I feel I’ve barely begun to make an impact on the company.

Having spent a year and a half on the mobile team, I recently decided to change teams, eventually finding a balance of fit and interest in our Careers product.

Tenure with a company is extremely valuable for both parties. You build trust and rapport with your co-workers. Today I feel comfortable and familiar with all of my fellow developers, product managers, and even the VPs and “C-level” execs (who are very accessible). On a typical day, I’ll talk to sales representatives in the morning while making espresso, chat with our office managers and assistants, and say hello to our incredible chefs. I would talk to the walls too, if only they’d give me interesting insights about the company. I’m working on that.

Some business folks that I've worked with in the past don't like to talk. Isn’t it better to be secretive about your work and get ahead of your co-workers in this dog eat dog world?

We have a good answer for that. In the book The Five Dysfunctions of a Team, Patrick Lencioni explains that many of the basic problems of a modern team are structured in a pyramid. It's similar to Maslow’s hierarchy of needs, but from a corporate perspective. At the base of Lencioni’s pyramid is the absence of trust:

Clearly, if you don’t trust each other, the bottom dysfunction isn’t resolved, and thus the upper dysfunctions just crumble under a bad foundation. On the other hand, when you do trust people you work with, you can avoid feeling any of the following:

• This person will think my idea is stupid, and will conclude I am stupid.
• This person will steal my idea and take the credit.
• This person doesn’t really know me, and will misunderstand / undervalue my perspective and background.
• I’m too shy to share since I barely know her/him.
• I don’t want to share my idea with this person. I don’t trust him/her.

This means that the best ideas in a dysfunctional company are never shared. People are afraid to speak their mind freely, and thus the flow of information (which is essential to a business’ success) is slowed down.

It Isn't Just Trust

For me, trust has led to a deeper knowledge of the organization, its products, and our business goals which allows me to work with confidence and propose ideas without fear. I would never have gained that knowledge without communicating with my co-workers. I recall many talks shared over lunch where I listened intently and asked lots of questions without being afraid of appearing dumb.

In my case, developing trust has been key to my success. I am proud to see a few recently hired co-workers who are more trusting than I was, and therefore are having an impact on the company sooner than I had. By letting yourself become vulnerable, you begin to build trust with others.

This is what we do at Stack. We make sure people aren’t afraid to challenge each other, and are comfortable in constructive conflict. Challenging a co-worker that you haven't built trust with can seem aggressive and cut-throat, because she or he isn’t sure of your motives.

Side thoughts:
I’m sure I’ll read this post in 10 years and laugh, but right now it’s hard to imagine finding a better place to work. Actually, I hear this a lot in our office. People regularly quip, “I never want to leave”. When the company’s mission is about serving the software developer community and creating a healthy community of learning, it stands to reason that the company will treat, not only its developers, but all of its employees in a fair and humane way. Stack does this by giving its employees all the tools that we need and simply getting the hell outta our way.

Want to work with me? We’re hiring.

You may know us from such popular websites as Stack Overflow Q&A, Stack Overflow Careers, The Stack Exchange Q&A Network, and most of your Google search results.

tl;dr - We’re changing our company name.

Here’s what’s changing:

1. As of today, our company will be known as Stack Overflow.
2. Our logo is different. But only a little.
3. Not one other damn thing.

Here’s what “Stack Overflow” is:

• A community where millions of programmers ask questions and share knowledge
• The best place to get a job as a developer, or to hire a developer
• The flagship site of the Stack Exchange Q&A network, which covers over 140 topics
• (new!) The company behind all of those things

Seven years ago today, Joel announced the public launch of Stack Overflow. Since then, our strategy has centered around building useful tools for developers and then - if they worked - expanding them to serve a wider market. We think our new company name better reflects this core philosophy, and will continue to lead to good things for devs and non-devs alike.

And... that about covers it. But just to be safe, I’ve tried to answer the questions we expect some of you may still have.

Q: So, what’s actually changing?

Well, as of today, people like me will start saying we "work for Stack Overflow.” I guess we’ll need new business cards, too? Hopefully someone’s on that already. But I digress. In the weeks ahead, we’ll change the name of things like the blog, podcast, and any other places where “Stack Exchange” was referring to the company, as opposed to the network of Q&A sites. Our Q&A sites will still be collectively known as the Stack Exchange Network.

Q: Are you “just not that into” the Stack Exchange network anymore?

No. Nonononono.

Our commitment to the Stack Exchange network is completely unchanged, and we’ll continue to invest in its expansion and growth. SE’s users have built a network of constructive, civil communities of helpers on a previously unheard-of scale, and we’re insanely proud to be a part of it. Here are just a couple of facts to drive home how much you’ve all achieved:

• The network as a whole has more monthly 5-time posters than English Wikipedia has 5-time monthly editors.
• Stack Exchange is the 47th most visited website in the US without Stack Overflow, and gets roughly as many US visitors each month as the New York Times.

Here’s what one of our investors had to say on the topic:

I believe Stack Exchange’s growth has now reached escape velocity. Not only will the existing topics continue to grow, but many new topics will emerge, until the network covers every topic that is amenable to objective Q&A. As new generations of people grow up on the internet, old habits — searching through textbooks or how-to books, or asking friends—will fade away.”

​ --Chris Dixon, Andreessen Horowitz

You hear that, books?? We’re coming for you, you filthy tree-based anachronisms.

Q: So, why the change?

We started with better Q&A for developers.

When we named the company Stack Exchange, we were only making Q&A sites. We’d had great success with Stack Overflow Q&A and we were expanding that engine to serve new topics. So, using the Q&A network’s name for the company made sense. If we’d decided to make one of those lame, corporate hierarchy charts,and for some reason had chosen to ask an untalented child with a crayon to draw it, it would have looked a lot like this:

And just to be clear, Q&A remains our core product, and we’ll continue to invest in helping it serve more of the world’s developers, chemists, photographers and whatever the heck these awesome people are.

Then, we focused on better jobs for developers.

It was pretty obvious that even though developers were scarce, valuable talent, most job boards were still designed for recruiters’ needs, and were full of fake “exciting new startup!” listings and jobs requiring things like “8 years experience with Swift”. Tired of that nonsense? So were we. So we built Stack Overflow Careers. Which totally effed up my corporate chart structure. But Joel was all,

“We’re supposed to be relentlessly serving devs, not charting dopey crap. Figure it out, or I’ll take your standing desk away, and tell the pastry chef no seconds for you.”

But I still couldn’t come up with any good spot for Careers, so I just stuck it somewhere random. And since Joel had said "relentless" a bunch of times, I added a drawing of Batman, cuz he’s super-relentless and I was a lonely teenager:

Next up? Better EVERYTHING for developers.

Which brings us to today. Now, we could just sit on our laurels and reflect on all we’ve achieved. I actually proposed that laurel-sitting plan, but you know how Joel is:

"You know when you get to sit on your laurels? When every developer problem has been solved. Last week, Carmack Instagramed that that he was eating a crappy sandwich. YOU ARE FAILING HIM."

Honestly, some days I worry about Joel, but he’s on to something:

Developers have a lot of problems.

We got here by focusing on underserved developer needs, and asking the world’s developers to help us solve them. I think that if we’d set out to build the best Q&A platform for everyone’s needs, it wouldn’t have helped anyone. By narrowing our focus to a specific group we thought we could help, we were able to create a product opinionated enough to actually make a difference.

So, we’re going to stick with the plan. As we look for new ways to serve our users, we’ll focus on what we know best: solving developer problems. Today, we’re working on our biggest expansion since Stack Overflow launched: Documentation. You can learn more about it here, or sign up for the beta, and be part of building what we think will be our next Big Thing.

I should point out that we fail a lot around here. But wherever we’ve succeeded, it’s come from focusing on how we could better serve devs’ needs. And when that success looked transferable, we passed it along to the rest of the world. So, we’re gonna run with that, and hope you all keep on running with us.

Here’s what that crayon wielding kid thinks we look like today:

Do I hope to see more multi-colored, (poorly-drawn) networks spring up around some of our other dev products? Hell yeah. Will they? Beats me. But as always, we’re counting on you to help us figure it all out.

Didn’t you say something about the logo?

Oh - right. With the exception of a few minor tweaks, the Stack Overflow logo that you know and love has been essentially unchanged since we paid $512 for it in in a 99 Designs contest back when that was a lot of money for us. We thought it was pretty awesome then, and it’s still pretty awesome now. So, the design team didn’t change much, and just made a simple, clean update to the existing logo. Next week, they’ll share how it fits into a new style guide we’ll be using to help us standardize our visuals and save valuable design cycles downstream.

But for now, we were inspired by Google’s video explaining how they arrived at their new logo concept of “kindergarten letters, most of which are actually aligned correctly.” So we made a short video. While ours doesn’t include the phrase, “…and just the right soupçon of whimsy” nearly as much as theirs did, I think it does a nice job conveying exactly how ours got changed.

(Film by our own Benjamin Dumke-von der Ehe, aka balpha, music by Zero Project)

We are Stack Overflow. And we’d be nothing without all of you.

Here's what seersucker looks like (in case you were wondering about it while the gang talks about seersucker for a weirdly long time):

(image via wikipedia)

We've got two exciting things to talk about. First up: Stack Overflow has 10 MILLION QUESTIONS! We made a web page to celebrate, because that's what geeky web companies do. If you're too lazy click on that link don't worry because Jay eventually just starts describing the page to you. (Predictably, the conversation quickly devolves from celebration to discussion of how we can actually measure activity and helpfulness. Views? Sessions? Answers?) To celebrate, we asked folks to share their Stack Overflow stories on Twitter with #SOreadytohelp. Tons of people have shared so far (which may have something to do with the fact that you could win a t-shirt).

Some of Jay's favorite selections:

StackOverflow is the definition of all what's noble about this field: knowledge, sharing, rigor and dorky jokes. #SOreadytohelp

-- Ahmed (@halflings) August 20, 2015

(The dorkier, the better.)

#stackoverflow in Nairobi helped me skip condescending librarians,unreliable Internet to stream tuts,limited dev community #SOreadytohelp.

-- Geoffrey Cimani (@asgardjotunheim) August 20, 2015

(Take that, librarians.)

#SOreadytohelp Of all the "world changing startups" I think SO secretly is the most impactful one in the world. http://t.co/rXSuON6Vsq

-- Goktug Yilmaz (@Esqarrouth) August 20, 2015

(Oh no! Our secret's out!)

Okay, enough of that boring celebratory stuff. Our next topic is so big and exciting that I think it warrants a horizontal rule:

Welcome to life below the fold.

So! It's time to talk about what Stack Overflow could do next. It was just about a year ago that we thought to ourselves: "we need more things besides questions and answers!" At least that's how Joel remembers it. To make a long story short, we're talking about a possible new content type: Documentation. If you haven't read the meta post yet, you might want to skim it while you listen to this part. (I'll wait right here.)

Done skimming? Welcome back. We're still talking about documentation. As it currently stands all around the internet, documentation is frequently:

• Poorly written or included as an afterthought
• Out of date
• Incomplete
• Lacking in clear examples

We're thinking the Stack Overflow community can help improve the situation the way it did with Q&A, and we think that's the next thing we can do to serve developers. Here's what it could look like:

(image via kevin's meta post, seriously, go read it)

Documentation is a really early-stage project, which is why we went to the community for feedback. We're still figuring out what level the docs will be at (but we already know there will be NO toString() DOCS ALLOWED).

Also, the Power Glove used to be a thing:

(image via wikipedia)

After a bunch of discussion, David has determined that we're about halfway through the Documentation project: we're 6-8 weeks in, and we've got 6-8 weeks to go. Perfect!

Questions from the audience:

• Is SO inadvertently going to make projects stop writing their own docs? Maybe, but we doubt it. Other Q&A sites and forums still exist elsewhere on the internet, and documentation will too.
• How did you do you plan to solve the issue of distributing reputation for a collaboratively edited page of documentation? The short answer is we aren't sure yet, and we have to observe how people actually use docs in the private beta. One thing we've kind of decided is that we don't think it makes sense to take rep away from you when someone else adds to something you wrote. (If you want to help solve this problem, sign up for the beta!)
• (paraphrased) Why are you working on a Stack Overflow-specific new content type instead of something more applicable network-wide? The short answer is that it's really hard to solve problems or develop tools for hundreds of diverse needs, and you'll probably be bad at most of them if you try. If we'd set out to solve Q&A for the internet at large (instead of just programming) we wouldn't have ended up with Stack Overflow and it probably would have been worse for everyone. But something like documentation could be useful for a lot of sites, once we figure out how it will work for developers. Also, we have to very aggressively constrain so we can iterate as quickly as humanly possible.

Jay wants to talk about some other stuff, so here's another horizontal rule so nobody gets confused.

We haven't talked about new sites in a while, so here's a very brief rundown:

• We have a Law site now
• We have an Open Source site, which deals with open source software and also other things that are not software
• We have a Portuguese Language site
• We have a Computer Graphics site
• We had an Arabic site at time of recording, but it's closing due to low activity levels
• For more, have a look at the list of newest Stack Exchange sites

Thanks for joining us!

Name: Aurélien Gasser

Job Title: Web Developer

How long have you been at Stack Overflow? I joined on September 23th 2013, so that's almost 2 years.

How did you join Stack Overflow? What made you want to apply?

As a developer, I love Stack Overflow in a lot of ways. But I actually ended up getting this job in a very funny way. I'm originally from France and I was visiting a friend in NYC for 3 weeks. After only 10 days or so, I had decided I wanted to get a job and live here. So I started interviewing for jobs all over the place. I started using a dating website, OkCupid, where I met a girl I quickly became good friends with. She wanted to help me find a job so she accessed the alumni repository of the university she went to, Yale. In this repository, she got several email addresses which she sent my resume to. One of the alumni she emailed was a certain Joel Spolsky (co-founder and CEO of Stack Overflow). Joel threw my CV on the pile, and after that I went through the regular interview process.

What big projects are you currently working on?

I'm working on a project named "match quality". I like to think we operate like a dating agency: guys are candidates, and girls are employers (or vice-versa, if you prefer). In the "match quality" project, I focus on the candidate side, trying to find the best job for a candidate not only by looking at each case in particular, but rather by identifying patterns that give us a better idea of what makes a job interesting. This way, we can come up with algorithms which suggest relevant jobs to candidates. I think it is very important because it gives us a competitive advantage. And it's the best place to do it because we know developers more than everyone else. I hope one day, when you go to Stack Overflow Careers, your dream job will be right in the middle of your screen, you'll just have to grab it.

What is your favorite part about working at Stack Overflow?

Working with smart people, for sure. Facepalming is something that used to be common in my professional life, but not anymore. Well, I facepalm sometimes, but most of the times it's because of my own derps. Though always arguable, the decisions that are made always make sense. Also, there is always something I can learn from each and every developer (yes, each and every developer). It feels great to be around Stack devs, and I find it is a privilege to be in such an environment. Oh, and all the benefits are pretty cool too. I'm writing this from home, on my MacBook pro, with 2 Thunderbolt screens, on a stand-up desk. And I just had a nap.

Outside of Stack Overflow, what are you working on? What hobbies do you have?

I don't have a side project at the time, though the last one I worked on was an online multiplayer game. It allowed me to fiddle with node.js, write my own physics engine, implement lag compensation. I learnt a lot about game development and read terrific articles (I recommend the Valve article on lag compensation). I'm always happy to read or talk about tech things; a few weeks ago a guy explained to me how he built his own automatic headlights for his old car.

To be honest, I spend most of my free time playing video games (Dota 2), or hanging outside. I have been living in NYC and London for the past 2 years, so hanging out in bars is a cultural thing, right? :)

So... I wrote my own DSL to solve those problems. It's called Schyntax, and we're already using it in production at Stack Overflow. Part 1 of this post is about the language itself. In Part 2, we'll look at how to setup Schyntax-based scheduled task runners in both JavaScript and C# (there is also a Go implementation in progress, if you'd like to know when it's ready, follow me on Twitter... where I almost never tweet anything).

Schyntax Syntax

In contrast with other scheduling DSLs, Schyntax explicitly tries to be powerful, easy to remember, and terse, but human readable. To a programmer, the syntax should feel immediately familiar and intuitive. For example, hour(5) means to run on the fifth hour of every day. minute(*) means to run every minute. seconds(3,8,52) would run on the third, eighth, and fifty-second seconds of every minute.

Ranges

Want to define a range? Borrowing range operators from modern programming languages, minute(5..7) would run every minute between the fifth and seventh minutes, inclusive (5,6,7). minute(5..<7) is the same range, except it excludes the end value (5,6).

Intervals

What if you want to run every fifth minute? As a programmer, if you wanted to run a command on every fifth iteration of a loop, you might use the modulus operator (typically %).

for (var i = 0; i < 50000; i++) {
    if (i % 5 == 0) {
        // code to run on every fifth iteration
    }
}

Schyntax captures the spirit of that by using minute(* % 5) to indicate "run every five minutes." Or, you could use minute(10..22 % 3) to run every third minute starting at the tenth, and ending at the twenty-second (effectively the same as minute(10,13,16,19,22)).

Intervals always reset at the beginning of a range. For example, minutes(*) is implicitly the range minutes(0..59), so the interval is always relative to the 0 minute of each hour. minutes(*%17) does NOT mean "run every 17th minute of the day." It means, "run every 17th minute of every hour starting at the first (0) minute of the hour."

Exclusions

The logical negation operator is ! in many programming languages. So if you want to say, "run every minute except the third," you could write minute(!3). To run every fourth hour except the fifteenth, use hours(*%4, !15). You can exclude any value, range, or interval. Exclusions always take precedence, so be careful not to exclude too much.

Expression Names

You might have noticed that both plural and singular expression names work (i.e. hour() vs hours()). In fact, most expressions have several aliases to make it easier to remember without having to go look at the documentation. For example, for minutes, you could use m, min, minute, minutes, minuteOfHour or minutesOfHour.

Schyntax is whitespace-insensitive and case-insensitive, so hours(*) is the same as HOURS ( * ) is the same as hOuRs( *).

In addition to the hours, minutes, and seconds expressions we've seen so far, Schyntax also supports daysOfWeek, daysOfMonth, and dates expressions. Complete documentation of the supported expressions can be found on the Schyntax GitHub page.

Examples

• Every hour from 0900 UTC until, and including, 1700 UTC (all dates and times are UTC in Schyntax):

      hours(9..17)

• Every five minutes from 0900 until, but not including, 1700 (notice the half-open range operator ..< instead of ..):

      hours(9 ..< 17) min(*%5)

• Same as the previous schedule, except only on Monday through Friday (inclusive):

      days(mon..fri) hours(9 ..< 17) min(*%5)

• Same as previous, except it won't run any time during the noon hour (UTC):

      days(mon..fri) hours(9..<17, !12) min(*%5)

• Noon UTC every Monday through Friday, except on Christmas:

      days(mon..fri) hour(12) date(!12/25)

• Noon UTC on the first and last days of the month:

      daysofmonth(1, -1) hour(12)

• Every minute between 2300 and 0100 UTC (ranges which wrap around are okay):

      hours(23..<1) min(*)

• Here's the Schyntax version of the Cron schedule example I gave earlier (10 8,20 * 8 1-5). See if this feels more readable to you:

      minute(10), hours(8,20) days(mon..fri) dates(8/1..8/31)

Groups

What if you want to run every five minutes during the week, and every half hour on weekends? You can do that by grouping expressions inside curly braces:

    { days(mon..fri) min(*%5) } { days(sat..sun) min(*%30) }

You could break the groups up into multiple lines if you wanted. Remember, Schyntax is whitespace-insensitive.

Full syntax documentation is available on GitHub.

Implementations

Although you'll generally want to use the "Schtick" task runner (described in Part 2), you can actually use the DSL directly to generate schedules. Let's show how to extract the next five event times for a schedule in both JavaScript and C#.

JavaScript

Schyntax is available on npm via npm install schyntax.

var schyntax = require('schyntax');

var sch = schyntax('min(*%2)'); // create Schedule object
var events = [];
var d = new Date(); // start from right now
for (var i = 0; i < 5; i++) {
  d = sch.next(d); // get next event time after the `d` Date argument
  events.push(d);
}

C# .NET

Schyntax for .NET is available on nuget.org.

using Schyntax;

var sch = new Schedule("min(*%2)"); // create Schedule object
var events = new List<DateTimeOffset>();
var d = DateTimeOffset.UtcNow; // start from right now
for (var i = 0; i < 5; i++)
{
    d = sch.Next(d); // get next event time after the `d` Date argument
    events.Add(d);
}

→ goto: In Part 2, we'll use a scheduled task runner to put schyntax to work.. We'll also look at how my team at Stack Overflow is using it to improve consistency in our scheduled tasks.

Many know Anil because he comes free with every new Twitter account. There is a small number of other places you might know him from:

• He's on the board of Stack Exchange, Inc.
• He's on the board of Data & Society
• He's on the board of the Lower East Side Girls Club
• He's on the board of NY Tech Meetup
• He's an advisor to Medium
• He's an advisor to Donors Choose
• He's a founder of Activate
• He and Gina Trapani founded ThinkUp
• He and Gina just released Makerbase
• He co-created Monegraph (not to be confused with MoneyGram)
• He directed Expert Labs
• He's got a little blog you might have heard of

Whew.

When Anil started blogging, he felt he was late to the party (and said so in Vanity Fair). And while it's true that he didn't invent blogging (Justin did, probably), he certainly wasn't late to the scene either - he started his blog in 1999. Also, he's Prince's #2 fan (right behind ?uestlove).

So! Anil's current all-consuming project is Makerbase, which is sort of like IMDb for digital projects.

His cofounder Gina built the site while Anil sat around and watched supportively. Joel is in there already, because anyone can add or edit a page for a maker or project. Makerbase helps increase transparency in the digital world (so founders can stop getting all the credit for features and things that other people actually made).

Makerbase is really simple: there are makers and projects. No companies, no job titles. Just makers and projects. You can add things you worked on for six months at your job, or just something you hacked up as a side project over the weekend, and Makerbase treats those projects equally.

Makerbase was a little bit of a "pivot" for ThinkUp (and by "pivot" Joel actually means that ThinkUp is "a company with two products"). ThinkUp is "social media analytics, but way more interesting than that sounds". You hook up your Twitter or Instagram or whatever you have, and ThinkUp will tell you who your biggest fans are or that you should dial down your cursing. In a nutshell, it's sort of like the opposite of Ashley Madison. (You'll have to listen to the podcast to get that joke.)

Jay asks Anil what project he's most proud to work with, and Anil deftly avoids the question by observing that computer science programs don't have ethics classes baked in, like law or medicine programs do. This is an odd disconnect, Anil feels, because software has immense power to create and alter culture. So a lot of the organizations Anil has gotten involved with address the intersection of technology, policy, and culture.

David observes that the tech industry is shifting toward design in addition to (as opposed to?) straight-up technology. At some point, we all started to recognize that programmers are just not good designers, and that design is not just beauty: it's a real discipline that is worth thinking about. Jay says there's an indescribable element to it (and then he describes it adeptly). Design has been an integral part of the 30- or 40-year march toward accommodating people.

Next, we ask Anil about how he spends a lot of time and energy thinking and speaking about social issues that are important to him. (He compares his efforts to learn from as many people as possible with Stack Overflow, and we didn't even know he was going to say that. Win!) Also--and this is related, in a "you had to listen to the show" kind of way--it's awesome when folks come along with you when you nerd out about something. That's why you should read Anil's blog post about Prince's "Purple Rain" video. And here's a link to Paul Ford's What is Code? piece.

Jay asks Anil the best way for people to use their powers for good:

The biggest thing is to ask yourself what you are probably getting wrong, and who can help you get it right. I think that's it.

(That was way too deep, so we'll end with a warning that it's camworld dot ORG and you should NOT try the other one unless you want your IT department to look at you funny.)

Thanks for listening to the Stack Exchange Podcast! You can read more of Anil's stuff on his Twitter or his blog - now at anildash.com! Or check out his extensive list of projects on Makerbase. See you next time!