This post is by Craig Kerstiens from Heroku
Click here to view on the original site: Original Post
Great coders know their technology intimately. And they know how to choose it. Truly awesome application developers know more. They know the human side of technology. They know technique. They focus on their method—their practice.
In 2000 Heroku co-founder and CTO Adam Wiggins saw this more clearly than ever before. He read The Pragmatic Programmer by Andy Hunt and Dave Thomas. The book, as Adam explains in this thought-provoking (and method-shifting) Waza talk, showed him that his work could not only be about technology. It HAD to be about technique.
Heroku Co-founder, CTO and general badass, Adam Wiggins
Adam discusses techniques—historical ones such as agile development and the power of rapid and flexible response to change; frameworks which helped drive speed by allowing developers to focus on the specifics of their application without having to reinvent basic wheels of, say, state management and request handling; the cloud which removed a huge burden of selecting, purchasing and maintaining hardware; and Software as a Service (SaaS), which, in addition to providing incredible benefit to end-users has created a development culture of continual, rapid improvement.
Technique means a lot. How we think about and describe what we do means a great deal too. Adam makes a strong point when he compares thinking and describing ourselves as programmers vs. application developers. Application developers, Adam says, think more broadly. They think about the end-to-end process of developing and deploying an application.
By taking ownership of thinking across the full spectrum from idea to delivery, application developers play a far more strategic role in their app—and their company’s—growth and success. Developers who think and work like this are truly “the new kingmakers” and a “powerful force to be reckoned with.”
Adam shares newer, even more powerful techniques that will help a developer who wants to think more broadly, act more strategically, and increase efficiency in her or his organization. Adam also discusses a number of these in The Twelve-Factor App:
Deploying from Day One and Continuous Development/Deployment
Having one (version controlled) codebase that is deployed in various states of completion across several instances from a live production app/site to development environments of different employees’ machines means we can all move faster and we can all stay in tune with one another. It means we can be deploying from day one and we can rapidly improve our products via continuous development and deployment.
Development and Production Parity: Keeping development, staging, and production as similar as possible
Historically, there have been substantial gaps between development (a developer making live edits to a local deploy of the app) and production (a running deploy of the app accessed by end users). These gaps, as Adam discussed at Waza and at The Twelve-Factor App manifest in three areas:
- The time gap: A developer may work on code that takes days, weeks, or even months to go into production.
- The personnel gap: Developers write code, ops engineers deploy it.
- The tools gap: Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses Apache, MySQL, and Linux.
Staying Close to Production
As we've come to appreciate agile development techniques and put such a sharp focus on shipping features, minimizing each of these gaps allows developers to:
- Make the time gap small: a developer may write code and have it deployed hours or even just minutes later.
- Make the personnel gap small: developers who wrote code are closely involved in deploying it and watching its behavior in production.
- Make the tools gap small: keep development and production as similar as possible.
We have come along way since The Pragmatic Programer. But it remains highly influential and set much of the tone for the many pragmatic developments in technique and practice that have come to the fore in recent years. You could say that Adam reading The Pragmatic Programmer back in 2000 is one of the reasons we invite developers to come together for Waza, which happens tomorrow. And one of the reasons we share the talks freely online for those who cannot make it. Waza is all about technique, about personal improvement for developers, about, as the subtitle of The Pragmatic Programmer says, the journey from journeyman to master.