HACK, HAX, Internal Innovation

Running a hackathon is easy with teams that are passionate about products and committed to software development.  I posted on Stuzo Insights Blog about starting up HAX I at Stuzo.    

Not in the Stuzo blog

All of the years building software I am still passionate, still love what I do, and excited everyday with the possibilities of what can be built.  Running a hackathon serves a personal purpose as well, to discover all the passion from the people around me.  Like any great team it takes the energy of the team to want to improve  and discover new ideas.   The hackathon might not always produce products but it always starts those conversations and with a good team lifts the energy for everyone. 

  

Everyone Wants A Platform

It's no surprise I am a platform thinking person.  My experiences have been shaped by great mentors at RedHat, JBoss, and Bluestone. My college business scaled because I built a system for building personalized merchandise.   I posted "Everyone Wants A Platform" on the Stuzo blog to talk more about platforms specific to the business.

Not in the Stuzo blog
My strengths have never been to focus on the word platform but rather understand what we are building and why.  Getting to a platform is not a first objective, it has always been to first solve customer problems.   Building the platform always provided me two things (a) automating repetition  and (b) focus on building new things.

A Day in NYC: #AWSSummit and FB Mobile DevCon

I spent last Thursday (April 18th) attending the morning keynote at AWS Summit and then the afternoon hands on session at Facebook Mobile DevCon.   Posted about the experience on the Stuzo blog. 

Not in the Stuzo Blog. 
The night before I was at the Philly Java Users Conference with Sacha Labourey from CloudBees hearing him talk about Platform As A Service.  From my view the PaaS really extends AWS, getting to the point of continuous delivery and further removing obstacles for building software. 

Thirty Days Ago

I want to talk about my first thirty days at Stuzo, but first I think it is a good idea to do a retrospective on my time at MeetMe formerly QuePasa through the MyYearbook acquisition. I am very appreciative for the opportunity to have worked with a talented group of individuals and a management team that was able to grow from 10m to 46M in sales.

After learning more about the organization, and beginning my work there, I was able to focus on three attributes of building out an engineering team.

1. Passion - surround yourself with really passionate people. Find passionate, smart people who are willing to challenge each other. Love being around those folks! When my team looked back over time they would say, “ I would probably not have been hired if I interviewed today.”  My goal was to continually add smarter people. This works because the new folks constantly push others and that continued passion becomes viral. When I left, we regularly had an annual developer retreat, internal hackathons and folks that contributed back to the local community.

2. Commitment - to getting things done. In my first thirty days, I remember launching a solid social application for music / playlists using iMeem API (Matt K always did a great job building user interfaces). The MySpace /iMeem mess aside, I was blown away that we could launch this app, watch it take off with great visibility into the core metrics, and then instantly get mass user feedback.   After my first year, I looked back and realized that even though I worked at some great companies, I have never delivered that many services and applications so quickly and at scale. Fast forward four years, and year over year I was continually impressed. In just over the past year we merged (and stayed operationally focused), rebranded (and grew), launched in twelve languages (web and mobile), delivered many new features and releases for the iPhone and Android platforms. The team always had and still has the commitment to get things done.

3. Respect - for each other. When working in the same location and spending hours together, if you don't get along or respect each other there is not much room to hide. You will go through your day pretty disgusted. This is not a place where folks are going to stay. When you see that level of frustration, you must bring your team together to keep the organization working productively.  Respect helps people to have intelligent disagreements and continue make progress.   We had that respect as a group and coming in everyday was something I enjoyed. 

What could have I been better at?

1. Push changes to our process earlier. We moved recently into using KanBan but I did not experiment enough. We had a well defined process from day one and it worked but could have pushed harder.

2. Contributed earlier into the local technology community and make it more part of the way we were. It's not core to the business and not top priority but it does help with recruiting and retention, the key part to scaling an organization.

3. Removed myself from day to day management and at times focus strategically. I really did (and think the team often appreciated it) give a lot of myself.  This meant I spent less time being able to contribute to thinking strategically. I enjoy the creative and learning experiences you get from thinking deeper about the business model.

Retrospective over, looking forward while having enjoyed a great ride.

Gerrit Replication to Bitbucket or Bitbucket and Pull Requests

In the past I opted for larger development teams to use Gerrit as the code review tool.  Gerrit being a solid tool with low frills can be setup to manage reviews and define your process.   Gerrit replication while meant to provide scale through read only repositories, can also be used to sit in between review repository and deployment repository.   We are evaluating for use where Gerrit is for review and BitBucket is for deployment and browsing.  Modifying the diagram at Gerrit Quick Intro to illustrate a model we are considering describes the split between review and deployment.

I know there is Stash for better management and it looks good but Jira + Confluence + BitBucket + ...  keeps adding up.    Also we could stay the route with pull requests though in a previous life with even a small team pushing lots of code with branches the pull request interfaces were cumbersome.

I am still leaning towards the usage of Gerrit and taking advantage of the other great features in bitbucket likes its long list of services and direct support Jira and Jenkins.   However my friend  Brian suggests I take another dip back into pull request land.

What to do?

Yehuda Katz presents EmeberJS in Philadelphia

Thanks to Yehuda Katz for his talk on ember+ES6 for us non PhillyETE attending folks.

Here are my quick notes but definitely suggest catching him live or searching youtube to see him present.

Ember
- provides organization for your application
- fundamentally uses HTML, does not define its own way
- allows you to extend HTML
- focus on URL because it provides context, if your web app does not keep the URL as context it's not a web app.

Then he did a walk through of sample application, rapid paced intro but covered the highlights.

A good question from the crowd about what happens to all these server side frameworks (specific question targeted at Ruby). Yehuda's response for me was dead on, the front end is where things are going but not everyone is seeing it yet.  Leaving server side frameworks scratching their heads to define how they will better support this growing architecture.

My public response was that we agree and have already started the switch. As we continue to see this increased switch from web to mobile, building APIs and separating out the UI work has made life easier.  Everything as an endpoint has been a promise for a very long time and with the [Internet of things] happening all around us it is becoming a reality.

For myself transitioning between MeetMe where we got ahead of the mobile curve (2011 TC MyYearbook mobile growth) and at Stuzo where we are helping customers through the transition using frameworks like backbone, ember or angular seems to make sense for building responsive UI and mobile applications. We are building expertise on Angular as a team but I expect quite a bit of jockeying between these frameworks as they build their rockstar communities.

Thanks again to Yehuda Katz for sharing knowledge and talking passionately about his thoughts.

Geeks in the woods.

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.

2. Hack-a-thon.
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!