Here’s a summary of key insights from SXSW Interactive 2011.
15 Slides, 3 Writers
At 15 Slides, 3 Writers, we learned about three different writers’ techniques on the same
fifteen twelve topics. A few key insights:
- All of the writers favored very simple text editors, such as BBEdit. They didn’t want the distractions of a more complex editor.
- There was a common theme around writing first thing in the morning.
- If they get stuck, they change context, either by: going away and coming back to it later, going back and working on grammer and structure issues in the earlier part of the writing, or changing colors on the screen to create a new visual context.
- They proof in a different context: either they print it out, or they publish to the web and read it there, where it just looks different as compared to their editor.
- The 4 Hour Body was the result of more than 10 years of data gathering, and 3 years of intensive experimentation.
- The Extremes Inform the Mean, not Vice-Versa: Example given was a design firm working on garden shears: didn’t want to know about the mean user. They wanted to know about the extremes: the parapalegic who was gardening. the elderly user. If they could design for the extreme, the middle will be taken care of.
- Make it a game (Drucker and five sessions). People who do something 5 times will keep doing it.
Rig the first 5 sessions so you’ll keep doing: go to gym for 15 minutes, not 3 hours.
- The best protocol doesn’t matter if you abandon it.
- Q: From your new book, what could you apply back to the 4 Hour Work Week?
A: Richard Branson was asked what thing to do to be more productive, and he said “work out”
There is a lot to provide that exercise has a big positive impact on learning, cognitive ability, and productivity. Use exercise/recreation to bracket your day: before and after.
- Some fantastic doctors out there. But… C=MD. As long as you pass your tests, you get an MD. There is always someone who is the worst in their class. The average healthcare visit is 11 minutes. Many times a doctor doesn’t or can’t spend the time to work with you.
Hey! This was my talk. Here are a few sources for more information:
- Visual notes from the live session
- Powerpoint is Still King
- Building a Base of Support
- Finding the Time to Innovate
- The Good, The Bad, The Forgotten: Lessons Learned Presenting at SXSW
Chris Poole, founder of 4chan, gave a keynote address. Key insights:
- In comparison to Mark Zuckerberg, who believes authenticity can only come through identity, Poole believes people need the ability to be anonymous to be authentic. Trying to explain to this someone, I came up with the following analogy: We do and say certain things at work, and do and say certain things with our friends, and we don’t always want the two to cross. So it does make sense that different identities with different groups allows us to more fully behave the way we want to behave in that group, as opposed to constantly filtering our behavior.
- People focus on scaling as an architecture problem. The real problem is not scaling, it’s building a community worth scaling. 4chan was not an overnight success. it’s been a slow steady build over 8 years. there was no hockey stick. The core community forms over time. With Poole’s new site, Canvas, there is concern about the culture growing: if they let 10,000 people into the site tomorrow, it would destroy the fragile culture that is developing.
- Some way for the quiet many to participate makes a big difference in the life of the community: In canvas, like all other communities, a small percentage of users create all the content. They wanted to create a new middle ground – so they made virtual stickers which could be dragged and put onto other posts. Now you didn’t need to be an artist to create visual content. 100,000 stickers placed in a few weeks.
- Historically self-publishing has been looked down upon by traditional press. But in the comic industry, it’s the complete opposite. You have to be self-published, to prove you are committed, you have an audience. That will start to happen in the traditional publishing.
- All three authors on the panel extensively used social media, especially Twitter, but also Facebook, to represent themselves professionally, stay abreast of editors and keep track of editor/author relationships, and of course key in touch with readers.
- The marketing/publishing people are obsessed with how many hits my blog gets, what are the search terms, how many followers and friends do I have. [I saw this echoed at other writer’s conferences as well.]
- I took my self-published book, which was $15 for the printed book, and did a $2.99 book on Kindle. It was slow for a while, but sales have taken off, and they’ve even driven up the sales of the printed copy.
- My main motivation is to have as many people read my stuff as possible. I don’t care how it happens, I just want it to happen.
- You always have to do the marketing yourself, even if it’s a traditional publisher. You have to market the book, and you always have. Now it’s just easier to do. Once upon a time you had to get in the car and drive to every bookstore in the country. Now you can get a national or international following through online tools.
This talk by Thomas Myer was a lot of fun. The premise was that if you can develop a product you can sell and make $100 per month, then you can repeat that process ten times, and start to build up an income stream. Full session notes. A few highlights:
- Wrote eight books. Not a lot of money, but checks still do trickle in. No need to provide tech support, which is nice.
- Wrote backup software, which was a plugin for a platform of some type. Turned out to be tricky and require a lot of tech support calls. But then it turned out that much of the same code could be leveraged horizontally, so that he could release backup software for a different platform. Gave him more product reach.
- Wrote a few iPhone apps. Very simple apps to solve very specific problems: e.g. writers encounter writer’s block or need ideas, and the app is an idea generator. The UI design is extremely simplistic, but that doesn’t matter: solving the customer’s need is what matters.
- Examples of assorted information and teaching businesses: produce a video on how to do X, then sell access to the video online.
- Donations doesn’t seem to be viable. Needs to be an actual payment for a product.
Gamestorming is a technique to facilitate an ideation meeting that is a cross between too much chaos and too much structure. It uses game techniques to make it fun while still oriented towards a goal. Full session notes. Probably the best thing to do is to buy the book Gamestorming, which I plan to do.
Here are excerpts from two presenters at Cloud Camp.
My long time buddy Gene Kim, founder and former CTO of Tripwire, spoke about devops.
- Now more than ever, we need great IT operations. Organizations are held up by the ability to get features released, get things through operations. It’s not just an operations problem, it’s a development problem and a business problem.
- They benchmarked 1,300 organizations – to link controls and performance. High performance organizations exist and they are 4-5 times more productive than ordinary organizations.
- High performers find and fix security break fast
- Unplanned work comes at the expense of planned work
- Traditional organizations have a Vicious Downward Spiral:
- Too many fragile applications (prone to failure) -> Too much time spent firefighting and in unplanned work -> Planned project work cannot complete
- Downtime causes frustrated customers to leave, while features fall further and further behind -> Market share goes down
- More urgent, date-driven projects put into the queue -> Even more fragile code put into production
- More releases have turbulent installs -> Release cycles lengthen to amortize cost of deployments -> Bigger deployment are more likely to fail, and more difficult to diagnose
- Zone #1 for improvements:
- Decrease cycle time of releases
- Create determinism in the release process
- Move packaging responsibility to development
- Release early and often
- Decrease release cycle time (example: Reduced deployment time from 6 hours to 45 minutes)
- Never fix forward, instead “roll back”, escalating any deviation from plan to Dev
- Verify for all handoffs (e.g. correctness, accuracy, timeliness, etc.)
Earnest Mueller from National Instruments also spoke on devops. I found his very explicit details of how their web development/operations team works to be fascinating. A few highlights:
- The Process:
- All systems work used the “developer” tools and systems [Revision control: Perforce / Bug Tracking: HP / Specs and reviews: Atlassian Confluence Wiki / Task tracking and burndown: JIRA/Greenhopper]
- All members collaborate on all aspects of the product. This was the key to making it work – using all the same tools. We could prioritize better, because it was all in one system.
- There can be a fear that the systems tasks would always get pushed out. This seemed to be mistaken impression. When presented alongside requirements in the same requirements tool, decision makers seemed to understand the need for systems work.
- System Automation
- We built our own: PIE, the “Programmable Infrastructure Environment”
- Looked at Chef/Puppet, and others. What we needed wasn’t quite any of those.
- XML System model defines systems, services, code installs, runtime interaction, variable substitutions
- PIE autobuilds the system from the model: provisioning, software installs, monitoring integration
- Zookeeper as a runtime registry for systems info and eventing
- Allows us to start/stop/control/install/autoscale on bunches of dynamic environments
- We have our dev environment, test environment, production environment – multiplied across our many products. We could deploy a new environment in a couple of hours.
- Overcoming the thought that it was impossible: Can i do infrastructure tasks using agile? with sprints? By actually trying it, it turns out to be possible. Write our own software provisioning sounds hard, maybe we can’t do it. but when you try it, you can.
- Building trust between dev and ops: Working together in one team and using the same tools really helps. You get transparency. You can’t build the sense of trust when you don’t know what each other are working on.
- Explaining core web development/performance/availability/management needs to desktop developers. Needed to write “why you should log” paper to explain core concepts