We recently held our second annual internal developer conference, Node 2.0 -- subtitled "Geeks in the Woods" in honor of the idyllic setting deep in the Poconos. While the first day and a half was more like "Geeks in the Dark," with only backup generators, glow sticks and flashlights to help us find our way through Irene’s aftermath, ultimately the event went off with only slight modifications to the agenda and provided a lot of value to the team. I have to admit that in our darkest hours, I was ready to call it and get back to civilization, but Gavin kept pulling us to continue – and right then, dramatically, the lights came back on!
Why do we hold this event?
Mostly to escape the one-hour time limit we generally maintain for office meetings. With so much going through our development pipeline at all times, it can be extremely difficult to find an extended period in which to work with the team as a whole, get everyone sharing ideas, and explore what we need to focus on to keep the team growing. So last year, Gavin spun up the idea for a developer retreat, and we jumped at the opportunity. Year One was Atlantic City -- when AC lost power! Year Two: Woodloch in the Poconos, barely post-hurricane but still mid-outages.
What do we do?
As this is only our second year, we’re still experimenting and trying to optimize the schedule. This year, the consensus was that we packed a bit too much into the three days, as we tackled four distinct areas:
1. Learn a new language.
On the first day, we brought in an instructor to teach the whole team a new language we don't use day to day. We believe that more focus on polyglot is valuable to the team and pushes folks to learn new ways of doing things, and more importantly, new ways of thinking about problems.
Can't talk about what we did, other than wow! I don't think this is something you can do very often, but it’s amazing how productive our team can be on such a short time frame. The pace was intense, but the way this event brought different folks together to solve problems encouraged a ton of knowledge-sharing, in many cases between people that rarely if ever collaborate in the course of normal work. This is definitely on the table for next year’s Node, and we have some new ideas for pre-planning that will make us even more productive in 2012.
3. Group Sessions.
One of the returning favorites from Node 1.0. Last year, we split into groups to come up with problems to solve and propose how to solve them. This year, we went a different route: each group built a pitch for a new product, planned their technical approach, estimated a project timeline, and presented their proposal to the whole team (including our CEO). Some good stuff I won’t reveal here!
4. Developer Talks.
Several developers prepared talks on a variety of subjects, from deep dives into recently completed APIs to more philosophical discussions of engineering approach. Even one of our partners found their way out to the mountains to talk about their company over lunch. The highlight for me was a session on test-driven development led by one of our DBAs, an accomplished speaker, which provided some great ideas we’ll be implementing moving forward. Overall, though, we learned that the hands-on sessions brought more value than just talking.
Do you talk about the business or just tech?
I gave a talk about leadership or management. Gavin explained how a focus on performance would lead to tangible benefits for the company. Jeremy reviewed product history and how it impacts our development process today. And Geoff gave insight into the business: where we’re headed and how. These are usually bookends to the day, and they serve to give context to the rest of the agenda.
How do we bring this to the office?
While we can’t always spare the time to hold similar events in the office, we do encourage the team to talk at local events, hold internal lunches to learn new things, and occasionally bring in external speakers to keep the knowledge flowing. More and more, we’re working as a team and not just a collection of individuals, and it’s been a beautiful evolution to watch.
So now I’m looking forward to Node 3.0: The Apocalypse Comes. Any feedback internally and externally on ideas for the event would be welcome!
Sunday, January 30, 2011
I was recently asked to be part of a technical advisory board for CloudBees. The group included some great folks Eduardo Pelegri-Llopart, JJ Allaire, and James Gosling. Thank you Sacha and Bob for allowing me to participate with such a group. Besides meeting with the team and getting an overview of the plans I also had some time to play with both Dev@ and Run@.
Dev@ = Jenkins/Hudson/Nectar
Jenkins, recently renamed from Hudson, is the de facto CI system in the market. CloudBees provides a supported version called Nectar offered for on premise or as a service. I have been using it for years to help implement development process. Currently we use it on a daily basis to build for more platforms than I can mention - java being only a very small part of it. Today I wanted to start a build of one of my open source projects, one I have not touched in a 'VERY' long time. This project is currently hosted on sourceforge - https://sourceforge.net/projects/blue/.
After setting up my CloudBees account I added a Job and figured I would use it to generate my docs. Well it took me three times to get it right. The first time I did not set my ANT version properly, the second time I named my target wrong but then wala a working Jenkins Job in the cloud generating my documentation for Blue. I just wish I had this running when I was building Blue a few years back instead of constantly developing on my box and having to build ant tasks to push files to different places. Using Jenkins in the cloud (Nectar) could not be any easier and it would be great to see lots of open source projects participate. (CloudBees Todo: Allow making docs and distribution files publicly available).
While Run@ will be usable from dev through production I can quickly see how it simplifies life by reducing management of the development and testing environments. One of the challenges in building out a development process is physically connecting the systems together to create the outputs you are looking for.
A development organization can have 10's or 100's of developers implementing an equal amount of services with concurrent projects all needing to get out the door. This can be overwhelming to think about. I see Run@ and the concept of PAAS (platform as a service) as a building block for managing large development organizations and process.
Thanks again to the team.
Ryan - Great seeing you again, it has been a long time.
KK, Vivek, Harpeet - Amazing what you guys are doing both technically and fighting the fight to keep the community moving forward.
Spike - Glad to see you as part of the team bringing together the vision for PAAS.