Come steal several easy but effective workplace ideas from GitHub: a software company that defines success as a union of employee happiness and sustainable profits.
GitHub is an extremely unique software development organization, both in how it has evolved, how it functions, what it builds, and what it aspires to do for humankind at work. Learn how employee happiness and profits can and have gone hand in hand, and how the seeds of that are sown by having Hubot the robot do the dirty work, and having that dirty work done hundreds of times per day.
I'll share some of the most useful culture secrets of work at GitHub, including live demonstrations of some of our open source and not-yet-open-sourced internal tools, continuous development practices, and skill-improvement vectors such as the successful rotating King of Developers role.
All of the culture, process, daily work, and policies will be framed in the perspective of how they can be replicated at your place of employment for greater job satisfaction and more-successful-than-ever outcomes for your employer.
We'll conclude with a brief ask-me-anything segment, with past experiences having touched on hiring, vacation, project direction, the explicit absence of managers, and employee trust.
Matthew McCullough works for GitHub, Inc. and trains audiences around the world on the most effective use of the Git version control system and GitHub collaboration platform. In supplement to travel-based teaching, he writes books and records videos for O'Reilly and Manning on the topics of delivering technical presentations, the use of modern build and continuous integration tools, and version control industry best practices.
Do you have a product manager? Maybe it's time to stop. Come explore the idea that we should do away with "Product Manager" as a defined role, and ask developers to be the masters of their own domain.
By now, we are all comfortable with the orthodoxy: the product owner discerns the needs of the customer and feeds them to developers in the form a prioritized backlog. Developers pull work from that backlog, always confident that they're working on the highest-priority feature at the moment, and never having to worry about how those priorities are allocated. This system is simple, efficient, and has helped many teams function better than they used to. It's also time for the system to die.
A few revolutionary companies are experimenting with the idea that developers should be in charge not only of when they build new features, but _what_ features to build. Rather than mere code technicians following the will of a product and marketplace expert, developers themselves become experts in their product domain, building the tools users need—by conceiving of those tools themselves. Dispensing with the product owner creates an entirely new organizational tenor: one in which everyone is encouraged to master the business's domain, to organize their work in autonomous ways, and to take ownership of the purpose for which the organization exists.
Once you realise the true enemy of software development is complexity, not waterfalls, you can start rethinking how we write our software. Come learn why modern languages like Scala and Clojure lead to fundamentally better software systems than any of yesterday's tricks.
Have you noticed that in spite of all our oft repeated Best Practices, those bugs don't seem to stop coming back no matter how many tests we write, that pile of technical debt still seems to keep growing no matter how much we refactor, and we keep missing those deadlines no matter how we organise our scrum board?
Perhaps it's time to stop listening to those who shout the loudest and start applying actual reason to the problem for a change. The programming paradigms that served us so well through the 80s and 90s are no longer adequate for developing software in the modern world. Building systems the way we're used to building them always seems to end in the inevitable death march towards exponential complexity.
But once you start asking the right question—"what's causing all this complexity?"—the answers turn out to be obvious. Debugging is only hard when you can't reason about your code. Concurrency is only hard when you can't predict the state of your code. Reusability is only hard when your components aren't naturally composable.
These problems are what the modern generation of functional programming languages—Scala, Erlang, Clojure—have been designed from the ground up to overcome. This is what the really smart people in our field have been up to lately, and it's really time you put down those Post-Its and come let me show you why it's a really, really big deal.
Bodil is a compulsive conference speaker in the fields of functional programming and internets technologies, and is a co-organiser of three annual developer conferences in her home town of Oslo, Norway, mostly because she’s still learning how to stop. She is a prolific contributor to the Free Software community, primarily as a Clojure developer, and has recently taken up designing new programming languages as a hobby. In her spare time, she works as a web developer for Comoyo, which is like Hulu for non-Americans.