Support and thank Josh Heyer for his work building Stack Overflow

Yesterday I wrote about Josh Heyer, and the Community he built. He cultivated Stack Overflow’s community, his outsized efforts made it what it is today.

On Monday, he was let go from Stack Overflow. I don’t know whether or not they gave him severance. What I do know is that given how this all transpired, I’m not confident it was enough.

If you believe, as I do, that Shog deserves our support and a thank you for his years and years of effort cultivating Stack Overflow, please join me in supporting him.

The software community that Josh Heyer built

You probably don’t know Josh Heyer. In fact, I can count on less than one hand the number of times I’ve said his name: Josh Heyer, and yet he is responsible for how you and I learn. You may know him as Shog9, but mostly only if you frequent Stack Overflow.

Until yesterday, Josh Heyer, aka Shog9 (Shog for familiarity purposes) was a community manager for Stack Overflow. This seems like a simple title and his unceremonious dismissal a trifle; but it’s so much more than that. Josh did so much more than that. Josh is the reason you and I use Stack Overflow. Josh is the reason Stack Overflow became and flourished as a community. Josh is the reason Stack Overflow became a model of how to manage an online community.

If anything, I am understating his accomplishments, but for those of you who didn’t frequent Meta Stack Overflow (later Meta Stack Exchange), a site where the decisions about Stack Overflow (and later Stack Exchange) were made, let me go into a little more detail about why and how Josh is the one responsible for Stack Overflow’s success.

In the early days of Stack Overflow, it was a one man community management show: Jeff Atwood (, founder of Stack Overflow, founder of Discourse) spent his days trying to be product manager, community manager, and CTO of a fledgling startup called Stack Overflow. He had borrowed what ‘worked’ from other sites such as Metafilter, but he was missing a key ingredient to what makes an online community flourish: glue that holds it together. That glue can be in the form of shared values or a common purpose, but without someone to constantly and consistently reinforce that purpose, the community falls apart. Jeff needed a leader, he needed someone who would tirelessly listen and help shape and mold the community towards a common purpose.

And so he hired. First Robert Cartaino (the first “Community Coordinator” for Stack Overflow), and later as a community manager, Shog9, aka Josh Heyer. Hiring Josh was a no-brainer. He had been a part of the community since the beginning, and had molded his thoughts and his words for maximum effect. In fact, checking the date and seeing that he was hired in 2011, three years after Stack Overflow started, is a bit surreal to me — historically he was there from the beginning.

I could link you to any one of Josh’s 3162 answers given over the past 10 years. I could talk to his patience, kindness, diplomatic skills, or his ability to show you what the other person is thinking with empathy. I could spend hours regaling you with the times he shaped community opinion. Instead, for the sake of keeping you engaged, I’ll share only two such occasions:

During a recent community crisis, where the community had been attempting to figure out how to welcome newcomers without being overrun with people who didn’t care to make the community better, Josh gave an answer about water:

Maybe it’s the drought here in Colorado, but… I’ve been thinking a lot about water lately. In our society, water is simultaneously essential and a menace, a problem to be dealt with and a treasure to be chased after.

Water doesn’t care what you want. No amount of pleading or nicely-worded signs are going to convince water to wet your parched plants when it wants to tear out a gully and carry away your precious topsoil. You can dam it, drain it, redirect it, slow it… But sooner or later, water always finds its level.

One of my earliest memories involved standing out on a freezing hillside helping my father lay out contour strips. Once plowed, the water would catch in the furrows and be absorbed, providing for the young seedlings and slowing the torrent that had previously cut deep ditches into the land. It took years and a lot of work to fully implement, but it worked: the entire farm was altered to accommodate what water wanted to do… Because the alternative was letting water destroy it. And water doesn’t care.

Josh Heyer, aka Shog9, on Community Building

I invite you to read the entire answer he gave. It is a masterclass in describing the problems facing the modern internet community, a masterclass in diplomacy and trust building.

It doesn’t do justice to Josh’s career at Stack Overflow to call it just a career, or a job. It was a calling, a vocation. He spent over a dozen hours, every day, for ten years, to meet with members of the community in chat, or to answer questions on meta, or to help guide Stack Overflow-the-company’s goal to make this thing profitable. This was Josh’s personal mission, a mission he exemplified in everything he did. You see, Stack Overflow would ‘work’ without community — and in fact Jeff resisted the idea of it becoming a thing people were too invested in, but it was precisely that investment by Josh and the investment that Josh encouraged out of others that made it work.

Josh Heyer made stone soup.

The second Shog9 story I’ll tell goes a bit further into the past, when Stack Overflow went through its second iteration of the “eternal september” that plagues online communities. Josh posted a question explaining what an answer was on Stack Overflow.

In the span of a few paragraphs, Josh’s explanation was able to focus thousands of thousands of people into a coherent and easy to follow explanation that could be used over and over again.

That’s Josh’s super power: distilling a complex issue down to its core, relating it to each listener, and doing so with empathy and grace.

I could stop there, but Josh’s influence doesn’t stop there. Josh spent thousands of hours helping moderators learn to moderate. He taught us and mentored us. He acted as a sounding board. He helped us grow. I’ve recounted his impact on me personally here. What’s not surprising to me at all is there are dozens (if not hundreds) of other people who could say the same thing about Josh. His leadership and wisdom affected everyone who interacted on Meta, even if they didn’t interact with him.

There are well-founded objections that Stack Overflow isn’t welcoming to new programmers. There is no one that did more to try to bridge that divide than Josh. He taught without ego, he showed a model example through his actions, he helped lift others up always.

In Seth Godin’s parlance, Josh Heyer is the linchpin of Stack Overflow’s developer community. He is why it all works.

I am saddened that Josh was not given the due he deserved from Stack Overflow’s leadership during his unscheduled departure. He deserves so much more from Stack Overflow, and so much more from all of us, but this is all I know how to give.

If you are looking for a leader, someone who can build trust between you and your community, someone who can build your team and be an example for leadership and kindness, you want Josh. He’s a developer by trade, but a natural leader and community builder by his actions. He will make a fine addition to your team.

This is Josh’s Act I, and from where I’m sitting, the best is yet to come.

In Memoriam of K. Scott Allen

I only knew K. Scott Allen in a professional context; as a teacher and developer that loved to dive deep in .NET and teach others what he knew.  He was a wonderful teacher, speaker, and a joy to be around.  He passed away last Friday.​

I met K. Scott Allen at the 2009 Stack Overflow DevDays. He was showing off some features in ASP.NET MVC (this was way back in the 1.0 days), and as invariably happens during a presentation, he hit an exception.  So naturally, I tweeted to him:

Going through 404-based development with @odetocode MVC talk at #devdays. develop untill you get rid of 404. 

And thus started a twitter friendship that has lasted. He went on from that presentation to become one of the most popular (if not the most popular) Pluralsight author, and share his love of programming with hundreds of thousands of people (if not millions). He was the cohost of the Herding Code podcast, and maintained a blog at

His grace, charm, and the devotion he had to helping others will not be forgotten.  I shall miss him greatly.

When should software teams set up deployment pipelines?

Stop me if you’ve heard this one before.

Enterprise Software Team gets new project. Team rushes into requirements analysis and development. Team gets development environments set up, and team gets closer to deadlines. With the deadline looming, the team realizes they don’t have a deployment pipeline set up — Deploying to a shared development environment was always ‘good enough’.

In a recent example a team was modernizing a system through a rewrite (things you should never do), one of the new team members asked, “How do we deploy this system?”

The answer was that they manually copied files to the shared development environment, and manually ran database scripts for updates, and that there was no pipeline set up to deploy to any test, staging, or eventual production environment.

When that team finally got their application to a staging or production environment, they realized they still had weeks worth of work to do to be able to deploy.

If you’re a software developer or former software developer, that line should shock you.

But, if you’ve worked on an enterprise team, or an R & D software team, that may feel normal.

In reality, not having a deployment pipeline set up first of the riskiest parts of any enterprise project.

In Enterprise software projects (moreso than in product development) deadlines are driven by executives that have an older-school mindset about work. You set a deadline, and work is done by that date and the project is delivered. It doesn’t help that waterfall is easy to understand and therefore easy to gravitate towards.

Software isn’t a process that lends itself to deadlines well. Unless the team is doing the exact work, in the exact environment, in the exact political structure they were working before, any estimate they give is as good as a guess, and about as accurate as throwing a dart against the board.

Take this example: Hangfire (a technology for running automated tasks) has a particular version that has a bug against a particular version of SQL Server, and in certain environments (like an enterprise environment) it causes unintended behavior (in this case, a proliferation of xp_userlocks). No one could plan for that, even if they’ve used Hangfire before. No one could have planned that the corporate IT team would strike the use of hangfire, causing the development team to scramble to rearchitect their solution to make up for this.

But, you know what would have caught that error sooner? The deployment pipeline the team didn’t have.

Enterprise environments (and organizations growing towards a more rigid governance model) have these separation of environments to ensure their data and business remains secure. Software Development is necessarily new every time a project is created. The software stacks change, the third party libraries change, and the practices change. As I write this, Angular (a common client side web application framework) has iterated on 6 major versions (Version 2-8) in the last three years alone. They release a new major version every 6 months!

Because things are changing so fast and because data security is important, it’s critical that enterprise software teams set up their deployment pipeline first. Without integrating their work into the IT Governance infrastructure, there’s no way to tell what risks will come to fruition without it.

In the beginning it may seem like a waste; but it is a bit like insurance: You’re paying early so that when the deadline gets closer, you have less risk for delivery, and due to the way that software works, that decision will pay for itself many times over.

“We don’t need architecture diagrams! We’re doing agile!”

Where baseball is superstitious, software development is trope-filled. We love metaphors and cliches as an industry, and sometimes those metaphors or cliches get weaponized against that thing Software Developers don’t want to do.

Like architectural diagrams.

Having worked with and around effective teams, I’ve found shared understanding boils down to one or more of the following:

1. Having a vision so clearly communicated that everyone just gets it. (This is shockingly rare)
2. Working with extreme amounts of technical discipline and in very small increments
3. Clearly laying out the path through diagrams and usable documentation as a starting point

It doesn’t help the conversation that one of the pillars of agile is working software over comprehensive documentation. This harkens back to the horror stories of the enterprise documentation process. It is this pillar that lends cover to the idea that if you’re “doing agile”, you don’t need documentation.

In the same way if you know how to drive a car and you know where you’re going, or you’re following someone, you don’t need a map…

…until your GPS craps out, or you hit the first red light and get separated from your party, or a funny light pops up on your dashboard and you have no idea what that light means.

Agile is a specific context; a context where the team is co-located; the customer is readily available; there are a high number of automated unit and integration tests, and the team works in the smallest increment possible.

There are contexts where that work; and lots of contexts where that can fail pretty hard: like when you’re modernizing an existing system through a rewrite.

If you find your developers are often confused as to what they’re delivering, or they keep needing to revisit their design or implementation; then one of the first places to look whether or not the team has chosen to visually diagram how the technical pieces fit together.

P.S., It’s worth noting the agile pillar says “over”, not “Instead of”. Agile teams value working software over comprehensive documentation, but sometimes you need that documentation to get to the working software part.

Systems Run your Business, People Run your Systems

I’m a big How I Built This fan, and recently I listened through the OtterBox episode. One of the quotes (originally from E-Myth) that Curt Richardson (The Founder of Otterbox) talks about that struck him was:

Systems Run your Business. People Run Your Systems.

If I had to sum up the goal behind the current DevOps revolution, that’d be it. “DevOps” is the attempt by the Software industry to systematize what we do. If I had to sum up the why behind the why behind the work I do, it’d be to help software teams systematize their process. I’ve helped teams systematize their process and have seen the productivity gains that arise from that work, and I believe enterprise software teams can benefit from that as well.

Systematization has several parts:

1. Ensuring relevant information is easily visible and communicated.
2. Ensuring the methodology used to develop software (Scrum, XP, Waterfall, RAD) is the best fit for the team and is molded to the culture of the team.
3. Automating and molding software creation processes to the business to ensure software creation is low friction (this is where I spend my time)
4. Ensuring Build and Delivery Systems are seamless and automated (CI/CD)
5. Ensuring the feedback loop from customer to team is effective; allowing the team to respond to change.

For your team, or your larger organization, how are you doing? Are all those aspects systematized? Can you say that each part flows into the others without friction? Do your systems allow your team to move as fast as possible to respond to change?

Develop Software the French Way

Every late project I’ve been a part of has had one thing in common: We didn’t say no enough.

No to ourselves, to try to ‘future proof’ the system.

No to our customers who wanted the system to do ‘just one more thing’.

No to the business people who insisted on working overtime to deliver the ‘just one more thing’ customers asked for.

French Culture is intriguing in this regard.

They say no, a lot.

There’s a particularly relevant quote from the article: “Answering ‘non’ gives you the option to say ‘oui’ [yes] later; [it’s] the opposite when you say ‘oui’, you can no longer say ‘non’!”.

Think about that. When you say yes, you can no longer say no.

And it’s true. We want to be accommodating, we want to give our customers and stakeholders what they want. And we somehow believe that by saying ‘yes’, we’ll be doing that.

What we’re actually doing is we’re adding time or money (or both) every time we say yes to a feature request, enhancement, bug fix. Software is a strange beast that way: If you don’t build a feature, it doesn’t exist. Not building a feature is free. If your business is deadline or date focused, not building a feature helps ensure you meet the deadline.

It’s by no means scientific, but the next time you either ask or are asked to say “yes” to something, think of it this way: Every yes adds time until whatever you’re working on will be shipped.

Big request: 6 weeks
Medium sized request: 3 weeks
small request: 1 week

That also causes a dilemma: The time you should say no the most is at the beginning of the project, when you know the least. Save the “Yes” for later or late in the project, when you have a better understanding of whether you can afford to add scope. Say no at precisely the point in the relationship where everyone is expecting ‘yes’.

That’s hard. That’s also a crucial way to build trust with deadline-driven stakeholders.

Deadlines aren’t agile (and that’s OK)

How many times have you heard in the course of a software development project:

I need this by <date>?
If we don’t deliver <x> by <date>, we’re going to lose internal political capital?
When can you get this to me by? I need it soon so <VP> will greenlight our next project.

This is a common way to manage. It’s ingrained in management, and it makes sense — internal management is often driven by deadlines. The trade show deadline, the Q4 marketing push deadline. The release going out so <business unit> can meet their deadlines.

Would it surprise you to learn that agile methodologies eschew this worldview for delivering something on a predictable schedule. It may only be a piece of what you want, but it’ll be delivered at a regular cadence. The idea of deadlines goes away for “are we on the right path generally”?

If this is a hard pill to swallow, “going agile” may not be for you. Especially Scrum.

And you know what? That’s OK. Your organization doesn’t have to be fully bought in gain some benefit from adopting some agile practices — but I wouldn’t generally recommend trying to adopt scrum if your environment is deadline driven. Your team can get better, your team can deliver faster without adopting Scrum; but it all depends on your team, your culture, and your particular context.

Have a new project coming up soon? Building a new team? Hit reply and let me know, I’d love to talk to you about your culture, constraints, and context. Every software team can be more productive, even if scrum isn’t the method they use.

This post originally appeared in my newsletter.