Apostrophe was born out of a complaint. Content management systems were (and one might argue, are) causing too much friction: not so much for the developers, who spent a majority of their time within a given CMS’s framework and therefore could thoroughly understand the content creation process, but rather, these systems were creating friction for the end user, who would--despite their comfort level with the web--require a significant amount of training to publish content to their new website. Friction for clients is a bad a thing, and the team at P’unk Ave figured that something needed to change. That’s where Apostrophe was born.
It’s important to understand the motivation for Apostrophe because that motivation is what drove the design of Apostrophe’s interface and processes. Importantly, Apostrophe is about reducing friction and letting people dive right into doing what they need to do. For the most part, creating content in Apostrophe happens through a simple layer of buttons that float on top of your web page’s content. Take this screenshot as an example:
The first screenshot shows what a visitor to the website would see, while the second one shows what an editor sees when logged in. When the editor clicks the edit button, a simple rich text editor appears and content can be created, edited or modified rather simply. The whole goal of Apostrophe is summarized the phrase “It’s just that easy.” As a front-end developer who is, admittedly, new to Apostrophe, I’ve learned the freedom of not creating hacks to get my users’ content on the screen, the freedom from confusing backends and, despite my love of writing, freedom from composing lengthy training documents. At the end of an Apostrophe training, I do feel extremely confident enough to say, “It’s just that easy.”
Interestingly enough, there’s a fairly deep similarity between the guiding philosophy of Apostrophe and the way that we learn and teach things here at P’unk Ave. If Apostrophe is all about getting the content creators into creating content, it’s fair to surmise that the learning culture is all about getting the developers into developing. This happens at almost every level, but I can think of two specific examples that highlight what I like to think of the P’unk learning curve. Last month, I shared with you about how P’unk is all about autonomy, and I mentioned some of my earliest work here was done in what felt like a radically autonomous environment. Suffice to say, the trend continued. Within my first two months, I have been handed the keys to a few not-entirely-small projects where I was expected to assume control and develop full websites for clients. The expectations were high, maybe highest from my self, but that freedom coupled with expectation created the perfect conditions under which I could learn. And I’ve learned quite a few things: LESS, JSON, Backbone.js, some Symfony framework, just to name a few. Another instance of what I’m calling P’unk’s learning curve is happening as we’re beginning to build the next version of Apostrophe. We’re reimagining the entire framework, from the code to the interface. This means that we’re having to learn a lot of new things along the way. But like an apprentice figuring out Apostrophe by doing it, we’re learning those new tools as we’re building and dreaming. It’s how the P’unk learning curve perpetuates itself: we’re all always learning and growing. It’s part of what keeps us alive and healthy. And learning in an authentic context is just as important for seasoned developers as it is for a noob like myself.
As a recovering teacher, I could have easily spouted off the fact that learning in an authentic context is important. That’s why I had my high school seniors practice writing and public speaking by having a job interview with the principle. The sweat on their faces (and believe me, those kids were sweating it) was proof to me that people learn best when put into real situations. And now, as an intentional learner myself, I’m rediscovering that message in a whole new light. I myself learn best in an authentic context where there’s something real at stake, something to be lost should my efforts at learning not produce the knowledge and skills needed for a real project. I think there’s a substantial reason for learning in an authentic way, the way I’ve been learning on the P’unk learning curve. When you’re in a learning situation in which the bar has been set too low (in a personal “project” for instance), the tendency is to not push yourself towards perfection. This may not always be true, but I think it tends to be the case for me. When there is enough external pressure, however, that pressure (whether it’s the pressure of delivering a client project or the pressure of simply impressing someone I admire) augments whatever natural motivation that I have for the task at hand. It’s the difference between batting practice and facing an inside fastball during the first inning.
Letting new developers (or new team members for that matter) work under real constraints for real clients forces them to learn quickly and authentically. And the latter is probably of inestimable value because the things we learn by doing and failing become part of our tacit knowledge and skills. We don’t need to look them up or reexamine old work because those skills become a part of our intellectual muscle. And stronger developers (and designers and managers and writers for that matter) allow us to spend time pushing the boundaries of our abilities. Because we’re stronger, because we’ve learned in authentic situations, we can innovate, which constantly arises as one of our chief internal values. The P’unk learning curve (and its analogous relationship with our product Apostrophe) is just another way that we’re building a consistent culture, a culture that points towards and ultimately builds itself upon our shared values.