When conducting interviews, I often get questions about our workspace and engineering environment. What IDEs do you use? What programming languages are most common? What kind of tools do you have for testing? What does the workspace look like?
Google is a company that is constantly pushing to improve itself. Just like software development itself, most environment improvements happen via a bottom-up approach. All engineers are responsible for fine-tuning, experimenting with, and improving our process, with a goal of eliminating barriers to creating products that amaze.
Office space and engineering equipment can have a considerable impact on productivity. I’ll focus on these areas of our work environment in this first article of a series on the topic.
Google is a highly collaborative workplace, so the open floor plan suits our engineering process. Project teams composed of Software Engineers (SWEs), Software Engineers in Test (SETs), and Test Engineers (TEs) all sit near each other or in large rooms together. The test-focused engineers are involved in every step of the development process, so it’s critical for them to sit with the product developers. This keeps the lines of communication open.
The office space is far from rigid, and teams often rearrange desks to suit their preferences. The facilities team recently finished renovating a new floor in the New York City office, and after a day of engineering debates on optimal arrangements and white board diagrams, the floor was completely transformed.
Besides the main office areas, there are lounge areas to which Googlers go for a change of scenery or a little peace and quiet. If you are trying to avoid becoming a casualty of The Great Foam Dart War, lounges are a great place to hide.
Working with remote teams
Google’s worldwide headquarters is in Mountain View, CA, but it’s a very global company, and our project teams are often distributed across multiple sites. To help keep teams well connected, most of our conference rooms have video conferencing equipment. We make frequent use of this equipment for team meetings, presentations, and quick chats.
What’s at your desk?
All engineers get high-end machines and have easy access to data center machines for running large tasks. A new member on my team recently mentioned that his Google machine has 16 times the memory of the machine at his previous company.
Most Google code runs on Linux, so the majority of development is done on Linux workstations. However, those that work on client code for Windows, OS X, or mobile, develop on relevant OSes. For displays, each engineer has a choice of either two 24 inch monitors or one 30 inch monitor. We also get our choice of laptop, picking from various models of Chromebook, MacBook, or Linux. These come in handy when going to meetings, lounges, or working remotely.
We are interested to hear your thoughts on this topic. Do you prefer an open-office layout, cubicles, or private offices? Should test teams be embedded with development teams, or should they operate separately? Do the benefits of offering engineers high-end equipment outweigh the costs?
(Continue to part 2)
I’m thinking of writing a new book, but I need a bit of peer pressure from you – so make me write the book and get a free copy.Update on 20 Jan 7AM GMT: 53.4% book offers taken
I’ve worked with several teams last year that had reasonably good tech practices, but things coming into their work stream were not defined well, not split well, not valuable enough in isolation, and generally not the kind of user stories that give people the big benefits that they expect. Applying a few small changes to the way they manage user stories made a huge impact on the actual outcomes of their software delivery. This got me thinking that perhaps this is a wider problem and other teams could benefit from the ideas we applied. So I’m thinking about writing a book about that. I want to write about how to define better stories, how to spot and fix common issues, how to split them so that they are valuable but small, how to deal with difficult stuff like cross-cutting concerns, long-term effects and “non-functional” requirements, and above all, how to get the promise of agile and iterative delivery by ensuring that the right stuff gets discussed and agreed between delivery team members and stakeholders.
Before I jump into a few months of writing, I’d like to know if I’m right or wrong thinking that other people out there have the same issues. This is where you come in! So here’s the deal: if the situation I’ve described sounds familiar, and improving user stories would potentially make a big impact on what you deliver, pre-register for the book and if 5K people do that in January I’ll write it, and you get a free (ebook) copy.
The working title is “50 Quick Ideas to Improve your User Stories” – check out the 50 quick ideas twitter stream for a sample. I’m planning to turn those one-liners into a book similar to Impact Mapping, both in terms of visuals and writing style, packed full of practical advice to try and lots of references for further research.Sign Up Now
I’ll use LeanPub to gauge interest and publish the book drafts as I’m working on it. So if this is interesting, head over to LeanPub and sign up for the book. I’ll keep the price free until the end of January or until 5K people sign up. If we reach that number, my New Year’s resolution will be to make another great book! If you know anyone else who could benefit from the book, please share this page with them.
I’m on vacation, and this post is auto-generated. See, you can trust automation sometimes…
Another year gone by, and another few dozen posts. Here are the top viewed posts of the last year (note – not all of these were written last year – this is just what people read the most last year).
In order of views:
- Titles for Testers
- Dichotomy for Dummies
- Debugging for Testers
- Coding, Testing, and the A Word
- Exploring Testing and Programming
- Why Information is Important
- Tear Down the Wall
Thanks to everyone who reads, comments, or reacts on Twitter to my rants and ramblings. Plenty of big announcements coming up, as well as more thoughts on what I see happening with testing in the future.
Happy New Year.(potentially) related posts: