With the rush to the Cloud, many tools have let their on-premises options fall by the wayside. This can be really frustrating for software development teams who need to have the applications they use run on their own servers.

Maybe you’re subject to regulations determining how you use and store sensitive data. Or you’ve become frustrated by the ever-changing rules around data privacy, like with Safe Harbour and Privacy Shield. Perhaps your team has concerns about the political or legal factors that might affect your risk over time. Or you simply want to know where your data is and control your working environment. No matter what drives your need, best-in-class on-premises tools are essential.

This is why we built Manuscript with the exact same powerful features and world-class support whether it runs in the Cloud or on-premises.

Recently, we launched Manuscript, built on the FogBugz engine that has pioneered project management over the last 17 years, and based on the insights gained from the thousands of software development teams that have used the platform.

The result is a project management tool purpose-built for making software. It’s deeply opinionated about how to help a team make great software and includes all the essentials you’d expect, like task management, prioritization, scheduling, sprints, story points, and all that good stuff. But then we saw a chance to do something really new, based on a few simple ideas:

We’ve been inspired by how Slack has done a great job of reducing email sent within teams (including ours!) and wanted to bring that same seamless experience to capturing bug reports or even answering customer questions. So Manuscript triages emails that come in from customers or even through your web contact form and files them right alongside automated bug reports and your team’s own tasks. This makes them easy to track in one place, so you don’t lose important decisions because they’re buried in email.

Manuscript has cases, not issues. Cases work better than the issues or tickets you might be used to in other systems — you aren’t forced to fill out a bunch of mandatory fields, and every case is assigned to just one person. That means you always know who’s accountable and no decision or task ever falls through the cracks because everybody thought it was somebody else’s problem. Even better: in Manuscript, search really works. Cases are easily searchable by anything you can remember about them, even if it’s just “I know I saw this thing last week and it was assigned to Bob”, Manuscript can help you find what you’re looking for.

Let’s face it, a lot of project management tools are trying to up-sell you on their chat platform or their productivity suite. Manuscript works with the tools your team already likes, and these integrations are free, customizable and open source, instead of being complicated, expensive and out of date. Since Manuscript has a great API, as well as example integrations that are easily remixable on Glitch, it’s simple to connect it to any proprietary tools you’re using, too.

And we don’t nickel and dime you on the stuff that you need — so features like a support helpdesk, document collaboration, crash reporting as well as so-called ‘Enterprise’ functionality like Single Sign-on with SAML 2.0 are all in the box.

Sign up for Manuscript for free to try it out, then get in touch for more details.

Announcing Manuscript On-Premises

Aphorist Mason Cooley once said that art begins in imitation and ends in innovation. Interestingly enough, that quote sort of applies to getting started with Glitch! If you see a project that you like, you can remix it, put a twist on it, and make it your own! Here are a few unique ways that artists are using Glitch as a digital canvas to design their own works of art.

One of the most common ways people see art is by going to a museum. Designer Mark Uraine expanded that simple concept and built a virtual gallery space with an exhibit dedicated to pioneering digital designer Muriel Cooper. Mark used a blog post he wrote on Muriel to create text and image panels within a VR environment.

As Mark mentions in his post, “Today we are rewarded by her efforts in every app we swipe, every typographical layout we scan on the web, and in every interaction that immerses us in the digital world.” I think Muriel would be very proud of this!

A big challenge for designers and artists is not only finding a way to show off their work, but to keep it updated as well. Luckily, Glitch makes it extremely easy to create a portfolio website with multiple pages and images. No more dealing with clunky site builders with finicky controls — just update your site right in our code editor and all your changes are automatically live! Take a look at how conceptual artist Karolina Dworska uses Glitch to make a simple portfolio with information on her work. Well done Karolina!

Jo Baer’s “Primary Light Group, Red, Green, Blue” is a prime example of minimalist art. The three canvases each contain a black outer border and a different colored inner border, and this Glitch project reinterprets the exhibit directly within a web browser. Check out the README for this project for a detailed explanation of not only how this was made with HTML and CSS, but the thought process from the artist behind its genesis.

We talked about using Glitch as a digital canvas for your own creations, and we’ve found a few great examples of how others have made art using our platform.

Graphics editor Rich Harris designed a lovely rendering of Maura Dooley’s poem “Still Life with Sea Pinks and High Tide.” As you scroll down the page to read the piece, gentle ocean waves rise and the horizon disappears. The visual rendering really adds another dimension to the poem! What poems or other pieces of art would you make using Glitch?

These are just a few ways Glitch can be used to put pixel to screen and express yourself. If any of these projects have inspired you, take a look at our Art newsletter! It contains more examples of artsy projects on Glitch, as well as a spotlight on creator Hector Urtubia.

Create Without Limits: Art Apps on Glitch

Vox Media has grown in the last dozen years from a small network of blogs to become a massive digital media company with hundreds of employees across eight different content verticals. Whether it’s technology, shopping, or sports, Vox Media’s content spans a wide range of topics, and the best way to cover them all is by hiring top talent to make it happen.

We talked recently about how we approach job listing at Fog Creek, so we reached out to Ashley Twaddell, Director of Team Operations & Experience for Vox Media’s Product team, to talk about inclusive language, recruiting efforts, and tools to help companies establish their own processes around creating effective job listings.

Why is having a conversation about job listings important?

That’s a great question. There are a few reasons. One is simply that it’s in a business’s best interest to actually consider that a job description is an extension of the employer brand, and that’s a powerful tool to market yourself for the talent that you want. It’s important to strike the right tone about what an employer is looking for in candidates, and it’s also about what company values an employer is looking for. A job description is the first thing that a candidate probably sees about the company aside from any other content or product usage that it has, so even if a person doesn’t actually apply for the position, a well-written description can influence that candidate’s opinion of the company, and you get the voice of the company to shine through versus an individual hiring manager’s.

More importantly though, we say here at Vox Media that language actually matters. You don’t want a job listing to make the candidates that you’re trying to attract back away. If you’re focused on attracting a large and diverse pool of candidates, you don’t want that job description to sound exclusionary in any way. If you’re an employer or company that doesn’t understand the benefits of hiring a diverse workforce, both from a moral and a business standpoint, there’s plenty of free resources and reading that you can do to get started.

You joined the Vox Product team back in 2015 as a product team coordinator. What was the state of job listings like?

We probably had around 500 or 600 full-time employees at the company, and the most notable change we had made in terms of hiring was switching to Greenhouse as our internal candidate tracking application system.

At that point, in terms of the job descriptions themselves, we had one or two template phrases that we would encourage folks to use. Those were generally about what Vox Media is as a whole, what the company does, and then also some blurbs about what working for Vox Media meant, specifically Vox product. There was also a description about our team, and that pointed you to a page where you could see our team blog and our code of conduct. But everything else was all over the place, and at that point, not really tested for inclusion.

We relied heavily on our leadership team to do a lot of the hiring for Vox Product, and honestly, we were really fortunate to have really thoughtful and educated leaders like our former VP of engineering, Michael Lovitt. He really supported and encouraged best practices around this. When you’re growing quickly and you don’t have a system in place with dedicated resourcing to check in on these things, ultimately you won’t be as successful as you hoped.

When I joined the company as a product team coordinator, I routinely checked on our job descriptions and ran them through online editing tools to check for gendered language and the overall tone and shape of our job descriptions. I would do that in coordination with our People and Culture team.

Was there anything in particular that prompted that move to review the language?

Definitely. In my job description, it was actually listed as one of the first things that I would be responsible for, in addition to a slew of other hiring responsibilities! But honestly, I think that in terms of what actually prompted the move…it was our staff, which is something that I’m really proud to say. So much of our inclusive culture is due to the incredibly thoughtful people we have been able to hire from the beginning, in addition to leadership that’s open and willing to take action on any of the recommendations that our staff would provide.

We have a company diversity leadership group in addition to our own Vox Product diversity group. At that point, the group was comprised of leaders across all the different divisions of Vox Media, and a lot of the initial resourcing came from the contributions of the members of that group, some of which were Vox Product staff and leadership. We recognized as a product team and as a company that building a system for inclusive hiring, starting with the job description, is more than important — it’s the right thing to do. We just had to figure out how to put the practices in place to make sure it was happening at scale.

The general conversation around job listings and inclusive language feels fairly new…like it’s something that’s just started to become more important within the past five to ten years. What sort of steps did you take when it came to the language that Vox Product used with job listings?

As a team, and as a company, we recognized this was a larger conversation, and that we needed to make improvements to show that it was work that needed to be done and was necessary to change things. A lot of our leadership worked on this versus falling onto our staff itself to create the changes, which I think is important to acknowledge. It demonstrates that as a company, we made it a real priority.

Beyond that, we did our research to see what best practices already existed in terms of what language to add and what language to avoid. We also focused on some of the internal process changes that would need to happen in terms of who is seeing job descriptions, who’s writing them, who’s posting them, and figuring out what resources we might need to ensure that hiring managers would implement these changes as they wrote and posted job listings.

Were there any specific phrases or words that were changed? You mentioned before that you ran the language through certain online tools to check for inclusive language.

I think generally we were looking to make our listings as a whole just more inviting and exciting. We worked to remove a lot of gendered language and emotional language. We avoided using any gender specific pronouns or terms that sound too aggressive or too feminine. We also asked our teams to avoid listing years of experience or any unnecessary educational requirements. We largely want our hiring managers, when they’re writing the descriptions, to focus on the skills and qualities a person could bring to our team. We take a step back and look at what we call our “scorecard attributes” to build out a list of skills that are truly necessary for the job versus a huge laundry list of nice-to-haves or irrelevant skills for the job.

So if there are nice-to-haves, we ask our hiring managers to state them as such. Are they skills that someone would have to learn through an educational experience, or are they on-the-job skills that you can learn? They aren’t formal requirements, and we ask our hiring managers to list them separately.

What’s been the outcome of these job listing changes as it relates to recruiting?

The biggest impact that I have seen over the last few years is that it has helped with our company’s reputation for being an inclusive employer; one that actually values having a diverse workforce. We are, after all, a company that prides itself on voices, and as a product team in particular, we’re looking to extend that into how we build thoughtful and inclusive products. So we certainly see an increase in the number of applications that we’re getting. We’re also able to use EEOC data to track within our job listings the identities candidates report them themselves, and we’re able to analyze and make changes to move one way or another. But overall, we’re seeing a general change in the reputation of the company and how people perceive us.

Based on the knowledge that you have now, is there anything that you would have done differently with respect to changing Vox Product’s job listings?

That’s a good question. I certainly wish we could have gotten to where we are now a lot faster! But it just shows we’re two years later down the road, and there’s still even more work to be done. We wish that we could make those strides a lot faster, obviously.

I think training would have been the most effective thing. For a while, I was coaching managers individually because I had to support them with not only job descriptions, but the whole hiring process: how to use Greenhouse, how to build out an interview kit, how to think about scorecards…that whole ordeal. I was supporting them one-on-one, and that obviously wasn’t scalable. It’s one thing to have documentation that guides you through how to write the steps of an inclusive job description, but ultimately, it’s better if the hiring managers actually understand why, and that they can identify the traps they might get into before they even sit down to write a job description. Taking the time to put together training would have made much more of an impact in the long run.

What resources or tools would you recommend for companies who want to ensure that their job listings are using inclusive language?

That’s a great question. From an editing standpoint, there are really great, free tools like Textio, Gender Decoder for Job Ads, and Joblint. Those tools help with making quick language checks before a job listing is posted. I really encourage employers to make sure they have taken the time to read and understand the larger conversation that’s at play here and make sure their hiring managers are well versed in the facts, too.

There’s so much great reading and resources out there. Hire More Women in Tech is a great resource to start. There are great voices also, especially in the tech space. Erin Kissane and Brittany Laughlin are two women that share wonderful insights and tools around this type of work.

Ultimately, I think just taking action to ensure that there’s a process that serves both as an educational tool and as a writing tool is a huge first step. Beyond that, make it a company priority to be accountable for the results of an effective job listing. It’s not only better. It’s actually necessary.

Creating inclusive job listings to attract future employees is a crucial part of any company’s growth and success. Move your career forward and come work with us at Fog Creek!

How Vox Media’s Product team creates inclusive job listings

Last week, we shared how companies use Glitch to help developers learn the latest technologies. These were all great self-directed examples, but what if you needed to provide more hands-on instruction? Let’s take a look at how other companies and organizations are using Glitch in a number of different learning environments.

Glitch makes a perfect environment for teaching workshops! Streaming music giant Spotify has created an app on Glitch that teaches developers about utilizing the Spotify API. Along with a slide deck detailing the basics of Spotify’s API, Students will work their way through the challenges, and by the end, they’ll have their own Node app! Once they have gotten familiar with how Spotify’s API works, they can check out other Spotify apps on Glitch and get creative with remixing something for their very own!

Samsung’s Internet Developer Relations Team uses Glitch to run workshops at tech conferences and meetups such as JS Monthly and Mozilla Festival. Students start with a simple template and end up with a working project by the end of the workshop. We love how they utilize Glitch’s ability to remix apps to enable students to work with code much safer and faster. The team even documented their setup for workshops on Medium so anyone can use the framework to create workshops of their own!

Glitch is the perfect tool for coding tutorials! Instead of creating a complicated local dev environment, Glitch provides everything you need right in your web browser. Envato Tuts+, one of the most well-known tutorial sites for self-directed learning, has a great tutorial on building a multiplayer pirate shooter game.

The tutorial begins with a starter kit — a simple Glitch app — and shows you how to add a library, accept connections on the server, handle sync orders between a client and server, and more. The tutorial also includes code blocks explaining each step, and it’s a great way to illustrate how to build a complete app on Glitch. View the complete example below!

If the Internet of Things interests your students, you can get really crafty and teach them to create a custom Alexa skill using this tutorial from the team at Hackaday. Remix an Alexa skill app on Glitch, register it with Amazon, and use the skill right away. You can even go a step further and publish the skill for anyone to use!

(BTW, see how we embedded two projects in this section? You can embed Glitch projects into any documentation you publish on the Web. Here’s how Wistia uses it to demonstrate their JavaScript Player API.)

FreeCodeCamp’s mission is about helping teach people the ins and outs of programming with the backing of a supportive community of millions of coders. They use Glitch for all their back-end coding challenges, with topics like responsive web design, data visualization, and APIs and microservices. By starting with a partially complete app template, students remix the examples to complete the challenges. FreeCodeCamp then uses a batch of their own Glitch projects to check if the submitted solutions are correct.

As you can see, Glitch is a really powerful and versatile tool for teaching, and students can use it on their own or in a number of different ways depending on their learning style. And if they get stuck on something, they can just raise their hand and the community will be there to help!

Teaching Coding with Glitch

Time Tracking is an essential part of Agile software development. To make resource planning effective, you need to track the time you spend on tasks so that developers, technical management and product managers gain insight into project progress and how much work remains outstanding.

Time tracking is built right into Manuscript, and enables you to not only record time spent on each case, but from that logged time you can keep timesheets useful for keeping clients and customers informed, as well as generate reports and visualizations that show how individuals and teams spend their time. Like ‘Hours spent per person, per project’, or burndown charts, showing hours remaining to complete a project displayed over time.

It also provides the raw data, along with estimates, that powers our unique Smart Scheduling feature, which uses AI to calculate ship date probabilities and predict software schedules.

We provide the facility to log time automatically. To make it easy to track your time, Manuscript uses your working schedule (which can be set at Time Tracking > My Working Schedule) to stop the clock automatically whenever you go home and start it again automatically when you come back in the morning. It also stops the clock during lunch breaks and when you’re on vacation, etc. That way you only need to change the “working on” case when you switch from one case to another. You can specify a site-wide working schedule, along with individual team members’ working schedules when they differ.

And now any case that has an estimate will show a start/stop work button directly in the case itself. This makes it even easier to record what it is that you’re working on, and provide accurate time information. This benefits everything you use time tracking for, from better probabilities of project completion, to more accurate reports that keep management informed and eases project planning.

Learn more about managing projects with Manuscript.

The Time Has Come to Push the Button

Some might say Fog Creek wrote the book on technical recruiting because, well, our founder Joel Spolsky, wrote the book on technical recruiting. About 10 years ago, “Smart and Gets Things Done” went out into the world. Today, it’s still one of the most trusted guides for organizations looking to attract and hire great technical staff. But, a lot has changed in those 10 years about the tech industry and how we need to recruit people today.

Here at Fog Creek Software, we’ve spent a lot of time reflecting on the most common hiring practices. What we realized is that while many of these methods were once considered effective, they actually perpetuated the biggest representation problems in the industry. For instance, we were huge proponents of hiring interns — but we only recruited students from the most prestigious universities (with the most well-known Computer Science programs). When interns proved to be highly skilled, we offered them full-time jobs before they could hit the open market. We were hiring great developers, but they were also primarily white men.

We tried a few things to change this, including our partnership with the Flatiron School. We recognized that there are many paths to a career as a developer, and we hoped that this initiative would communicate that to non-traditional candidates. But one initiative was never going to be enough, we were committed to the hard work of implementing recruiting practices that correct the representation problem that runs rampant in the industry today.

So we did even more homework. And we all agreed that the next step was to rewrite our job listings so that they more accurately reflect the supportive culture and values we have at Fog Creek.

We were especially interested in improving the “candidate experience” section of each of our job listings. We tried to be as clear as possible about what the actual requirements were, and which skills were more in the “nice to have” category. Doing this enabled us to avoid using terms like “Junior” in our job titles, which are the types of words or phrases that typically suggest a company is only looking for a young, recent grad.

We also decided that living up to our commitment of transparency meant we needed to disclose salary ranges for every open position. Fog Creek was already in the midst of re-implementing an open salary policy internally, so this change was fairly simple to make to our job listings as well.

But transparency also meant that we needed to be as honest as possible about the downsides of working at Fog Creek. Yes, the downsides.

We were particularly inspired by this job listing for the Recurse Center. Not only does it include an informative description in an easy-to-read format, they even listed the pros and cons of the position! Calling out the downsides of a position is gutsy, but it’s required if you really want to be transparent and it has worked well for us.

Take the DevOps position we were looking to fill, for example. We knew that our legacy infrastructure would present a unique challenge, and we wanted to be open with candidates about it. In a not-so-surprising turn of events, the pros and cons brainstorming exercise actually led us to realize that what we really needed on the team was a DBA! It’s in this spirit of thoughtful evaluation that we continue to write honest job listings about every open position at Fog Creek.

As difficult as recruiting can be for employers, the experience can be even tougher on candidates. Far too many companies expect candidates to make time for day-long interviews, without giving them the information they need in advance.

For someone who’s juggling coursework, managing care-taking responsibilities, or you know, wants to have a well-rounded life, this can be particularly frustrating.

That’s why we also expanded the “What to expect when you apply” section, which details the potential time commitment and process for prospective candidates. Additionally, we added FAQs about our amazing benefits and how they actually play out on a day-to-day basis. In addition to the responsibilities themselves, we think these are significant factors when candidates are deciding whether or not they should apply for a role.

After all this work on the job listings, the next step was to post it in places the right candidates would see and, then hopefully, apply. Some boards we love are Tech Ladies, a supportive community over 20,000 strong, and Blacks In Technology, a professional platform for PoC in tech. We’ve also put more effort into reaching non-traditional candidates through our connections at established coding schools and, of course, Twitter.

This is just a start to improving our processes and there’s still a lot of work to do. It’s also too early to tell the exact impact these changes have made, but anecdotally at least, so far they’ve been well received.

Doing a Better Job of Job Listings

A free, 24-page zine that will help you to learn some of the key concepts needed to create web apps using Node.js, including:

Find out how Cassidy Williams, Steve Klabnik and Saron Yitbarek got into coding.

Expert advice for new developers from experienced programmers.

Making Web Apps with Node

Whether you’ve been programming for decades or are just starting, everyone who codes is constantly in the process of learning new things. It can be frustrating to know just where to begin, but we’re here to help. Actually, the whole community is here to help you. We built Glitch to be a fun and friendly way to build the app of your dreams, and we are seeing a number of crafty developers and global tech companies use Glitch to teach you everything from building a simple website to creating an immersive VR experience.

Earlier this year, we rolled out our free React Starter Kit, and this week, we launched our Website Starter Kit. These are two great ways to learn coding using Glitch, so let’s take a look at how you can use Glitch to teach others!

WebVR is a JavaScript API that lets you bring virtual reality experiences to the Web. These WebVR experiences also work on VR headsets like Oculus Rift or Google Daydream! If you’re interested in learning more about it, take a look at A-Frame School. This interactive course is presented as an in-browser slideshow (that also works on mobile devices!), and guides you step-by-step through setting up Glitch as your development environment, introducing you to the basic elements and features, and provides you with several lessons and examples. Each of these lessons can be remixed on Glitch, so you can really get hands-on experience with the code.

Already have a little experience with HTML, CSS, and JavaScript? Take the next step and make your own interactive web app using choo! This great onboarding example in the Choo Handbook gives you great instructions and code examples on getting started using choo on Glitch by building a fun animals app. By the time you’re finished, you’ll learn the basics on creating templates, modularizing your code, and other helpful concepts which will help you build any app you can imagine.

When there’s already a ton of documentation around a particular language or framework, sometimes a simple blog entry is best. It’s also a great way to highlight new projects or features, which is what Algolia has done with their Glitch app We Rate Tweets.

Instead of walking users through building the app themselves, Algolia wrote a blog post which shows off their new app, tells people how to use it, and gives you instructions to remix it to have your own copy to use. All you need is a Twitter account and an Algolia account to get started!

Glitch is super approachable for beginners, but it’s also powerful enough to be used by some of the biggest companies on the Web. We talked about how A-Frame uses Glitch for their interactive slideshow, and Mozilla also uses Glitch to teach developers as well! Mozilla’s post on creating multi-user experiences with A-Frame shows you how to create shared, persistent and interconnected 3D virtual spaces using WebRTC. If you want to make your own slash commands for Slack, Airtable provides you with detailed instructions on using Glitch and the Airtable API to make that happen. Samsung explores how to use web components to build visualizations and configure a midi controller — perfect for anyone looking to become a VJ and show off some cool effects. Lastly, Google will teach you how to get started using Workbox for NPM, a way to improve load performance for your website and make it work offline.

We’ve shown you a lot of examples of what companies are doing with Glitch, but lots of developers out there are using Glitch in amazing ways. The team at Trove has several starter kits to show you how to create your own Twitter bots. Remix any of their bots, add your own personality, and give it a try! Live out your horror fantasies and make a dark and stormy night come alive using this fun tutorial from software developer and educator Kelly Lougheed. It uses regular HTML and CSS animations for everything! And this article from Red Hat’s developer evangelist Nicolas Grenié really embodies the spirit of what we want to accomplish with Glitch — getting better at programming by helping others. Teaching really does help you gain a better understanding!

These are just a few examples of how Glitch is used to teach developers across the Internet. The sky’s the limit when it comes to what you can learn, and we’re here to help you succeed. Don’t worry, you’ve got this!

Each One, Teach One: Using Glitch for Learning

The new Fog Creek Software office is meant for our staff to do their best work and feel comfortable and creative while doing it. With high ceilings, an open floor plan, and a killer view of the Financial District and Bowling Green Park, the new space is not only inspiring and beautiful, but as a nod to our history, it’s also experimental. To understand this better, let’s take a trip down memory lane.

We moved into our first real office, dubbed the “Bionic Office”, at 535 8th Avenue in New York City back in 2003. Our co-founder Joel Spolsky worked with architect Roy Leone to design a space where Fog Creek workers could thrive and work alongside their co-workers while still maintaining privacy.

One of the primary features of this space was ensuring that our developers had private offices with closing doors. According to Joel, these offices were key to improving programmer productivity, were absolutely required, and not up for negotiation.

Having an office space that worked for employees was so important to Joel that he took a hands-on role in the office’s overall creation, having a say in office elements like power, wiring, and the common areas to create the ultimate software development environment.

Fog Creek continued growing over the years after that, eventually taking over the entire floor of the original office. But after five years, it was time to find a bigger space. After a grueling search, we found our next office home nearly all the way downtown at 55 Broadway. The new space was such a hit that we were even covered in 

A lot of changes happened during the years at 55 Broadway, but we also kept a few ideas from our original space. Joel still had a hands-on role in both layout and construction, we retained private offices for our developers, and we provided a space large enough for our daily team lunches. To get the best sense of how much detail went into this space, watch the video below and see how it all came together.

One of the biggest changes at Fog Creek was that the number of our remote workers increased to make up two-thirds of our workforce. Also, two of the most successful projects we’ve worked on — Trello and Stack Overflow — grew large enough to become independent companies.

“As they grew and we grew, it got a little cozy,” says Anil Dash, CEO of Fog Creek.

“It was just time for us to stand on our own again. As we refocused on our products, we really thought about what a great headquarters would look like now for a company that is so focused on being great for remote people too.”

We moved office spaces in 2017, but we didn’t go far — our new headquarters at 75 Broad Street is just a half mile away and has picturesque views of Bowling Green Park and The New York Stock Exchange from our lovely 19th floor private terrace.

So what’s different about this new space?

“The old space was built when the entire company was based in headquarters,” Anil mentions. “That was sort of a different era. And similarly, back then our founders would talk a lot about programmers and coders and what they needed, which is an office with a door that closes. That’s still part of our ethos, but half the company are not coders.”

With our developers, sales team, and C-level executives working from the same space, taking different work styles into consideration is important. Some of these tasks require intense concentration, while others are more conversational and collaborative with your co-workers. To that end, there are some ideas we kept from previous office spaces.

“I think there was a very strong expectation among the members of our technical staff that coders would have an office with a door that closes. That was always a very big part of our public face of what Fog Creek is to the world. And the research is pretty clear that it is a massive booster of productivity for people in those kinds of technical roles. So we didn’t want to compromise on that at all.”

But the new office also includes a variety of work spaces that accommodate different work modes. Anil mentioned personal offices for standalone work, but they also work well for collaborative work like pair programming. There are workstations for independent or individual co-working, and phone booths for external communication such as sales calls or podcast appearances. There’s also our conference room — known as the “quiet car” — which can be used across a number of different work modes. And true to the nature of our office being flexible and experimental, we are already re-configuring some of these spaces based on how we use them.

“I think we have made [the office] a much more malleable space. We have a lot more plans to sort of shift things around, even so far as being able to entertain here. We’d never really designed our old place to be able to have guests and have people hold events and all that sort of stuff. And all of that is on the road map for us now.”

“I think just at a high level, work space really matters. It’s a fundamental part of how you take care of your people, and we have always been leaders on that. When the bar is set that high, you really have to get it right. And so we have always taken this really, really seriously. And at the same time, we have a lot of fun with it.”

And speaking of fun, we can’t forget about our lovely terrace. Once it’s up and running later in the year, we expect it to be a wonderful place for collaborative work. It will also be the centerpiece of our office as we host events, visitors, and other guests.

“There are a lot of companies in New York that have a lot of great ideas, and we are hoping to be able to invite them over, get to know each other, and figure out what we can learn from each other …and also just be good neighbors,” says Anil.

As the company has grown and changed over the years, so has our office space. Joel’s grand visions for what a work environment should do for employees have been part of Fog Creek from the very beginning, and we have tried to honor that legacy. We also have plenty of plans for the future, and look forward to continuing our tradition of incubating new teams and ideas from within our company and beyond.

“I think the fact that there’s so much personality and history in everything we do is really motivating. It’s become a very great space.”

Beyond Open Offices: The New Fog Creek Headquarters

Anil Dash is CEO of Glitch, and the host of Function, a podcast exploring how technology shapes culture and society. 

He also serves on the boards of Stack Overflow and the Data & Society Research Institute, and was formerly a contributing editor of WIRED. He’s been blogging since 1999 and won’t stop telling people about that one time he was on the Desus and Mero late-night show.

Maurice Cherry is Glitch's creative strategist.

Incidents

The Workers Who Keep the Web Safe in an Unsafe World

Animal Crossing Helped Me Get Back to Real Life

New Rules of the Classroom: Remote Teaching in the Age of Covid-19

Better Tech: Why We Need Calm Technology Now More Than Ever

Function with Anil Dash

Open World is a fiction anthology podcast about how science and technology serve as a backdrop for imagining a better future, helping us envision the positive influence that science and tech can play in a real future. 

Open World is produced by Keisha "TK" Dutes and hosted by critically-acclaimed podcaster Rose Eveleth, for Glitch. By speaking to the pressing concerns of our times through love, friendship, community, compassion, and sustainability, the host will help listeners imagine new ways forward into a future that is less scary and more positive, and something we can start working on constructively.  

Open World launches weekly episodes in Spring 2020. Want to contact the show? Email youropenworld@glitch.com.

Open World

Shift Shift Forward is a podcast that showcases everything that makes Glitch the best place to create on the web. We’ll talk to some of our top creators, explore cool apps, and even hear from the people who work at Glitch!

Shift Shift Forward

Celebrating the makers, creators and coders who shine.

Recent Posts