Tech

How does the team contribute to Developer Happiness at OSU?

by at

This post is the first in a series as discussed here: Developer Happiness at OSU

Most times here at OSU, being in a team is like being born; you don’t get to choose your family. Having said that, let’s talk in bullet points about development teams at OSU.

  • Managers are the ones who are most responsible for their team’s composition. Firing is a non-option, so let us talk about the process you have the most control over: hiring. How do I make this absolutely clear? Hire well and hire the people who can work well with your existing team. Our team’s philosophy has been “Hire for mindset, not for skillset.” We define mindset as having an open and honest attitude, questioning-to-understand (as opposed to questioning to demean,) and always, always, always willing to learn. Warning signs are there in almost every interview; make sure that some members of your team (if not all of them) are along in the interview.
  • Hiring for longevity: I have been in hiring committees at OSU where the committee members were leery of hiring someone (who would have been great for the team) because “they won’t stay long at this job.” Well, personally I might be more interested in people who have an ambitious mindset and are entrepreneurial in their outlook. If they do jump for a more interesting opportunity (as opposed to OSU driving them away,) at least we had them for the time we did. Sustainability of an app or piece of software should not be related to the longevity of the people that work on it.
  • How about developers who are a team of one?: I worked in a position like this for a number of years at OSU. The main takeaway I had from my experience is this: You might be the only developer, but you are still part of a team that should necessarily exist. That team is the person that you report to, the people that bring work to you (business analysts, researchers, etc.) and the people that host/support the software that you have developed. Every person interacts differently with the members of this “team,” so I can’t presume to tell you how to change. However, the realization that a team still exists was one that changed my sullen woe-is-me-I-am-alone attitude to one of hey-I-can-talk-to-these-people.
  • Teams that are just so, and there seems to be no relief on the horizon: You know these teams.
    • The vibe is all messed up.
    • It seems like everyone hates their jobs (not necessarily hating everyone else.)
    • The intertubes from everyone’s laptops are jammed with resumes flying to job applications at other places.
    • The manager rules the team with an iron fist of authority.
    • Legacy applications (what we call toxic assets) are overflowing from the portfolio.
    • People are overruling the prioritization process to get in their own pet development projects.
    • Development seems like an afterthought in the overall IT structure.
  • Oof, I am getting the hives just writing all of the above. What does one do in such situations?   The developers will probably follow some variation of exit or voice [1] (sometimes both.) But it is the manager of the team who has the most latitude to do anything, so this is directed to the manager: You may think that there is not much you can do about the portfolio or the fact that your team seems like the step-child of IT upper management. But you cannot make excuses that no ideas exist. There are literally books written on the subject about how you can make life for your team better. Do your homework and see where you can make difference, however small.
  • Side rant: What is up with OSU developers reinventing the wheel? Who decides that rewriting your own database connection libraries in PHP is a fine way to pass time? We have encountered applications where budding geniuses decided to toss aside (or were plain ignorant of) years of open-source, time-tested libraries to connect to MySQL, in order to roll their own. Have fun supporting that after said genius leaves!
  • Shenanigans: Well, allow them, I suppose. 8 hours of productive work per day is an unsustainable target; make sure it is appropriately interspersed with whatever the heck the team wants to do.

1. Exit, Voice and Loyalty is an awesome book written by Albert Hirschmann. Here is a post about him and his life’s work: Exit, Voice and Albert O Hirschmann.

Developer Happiness at OSU

by at

Developer happiness is a term that has gained traction over the last couple of years in the programming world. It seems like the Rails community (and 37signals) started using the term when justifying the decisions made in the Rails application framework. I could be wrong about the origins, but that particular community has definitely taken the term to heart. I like the basic idea of this term as expressed in this blog post by Chris Bell. Here is the main quote:

I believe that developer happiness is driven by the following factors:

  • The team around them
  • The freedom they are given to experiment with new technologies
  • Their working environment
  • The equipment they’re given
  • Good tools
  • The work they are doing

I am going to spend some time on blog posts that dissect this from an OSU perspective.

Edit: First post is here – How does the team contribute to Developer Happiness at OSU?

Resiliency, anti-fragility, code and Devops

by at

BusinessWeek had an article (via GigaOm) a couple of days ago which talked about continuous code deployment with reference to a 15-minute outage that Gmail suffered. The premise was that with the advent of continuous deployment in software products, we should get ready for similar small (ish) outages from all our favorite websites. I really liked the three categories of reasons that rationalize continuous deployment, but what caught my eye were a couple of concepts being used in these rationales.

  • The rise of the DevOps movement: While the definition of DevOps is sort-of clear, it has different flavors within various groups. In some groups, devops is seen as the absorption of operations tasks by software engineers. In a small app dev shop, this might not be possible for all the developers to do, but they could all be skilled at operations tasks in varying levels. In our group, we are lucky that we have devs who are skilled at operations tasks from the metal-up. So OS-level changes are not an issue for us. However, outside of the virtual machine, other tasks such as firewall, load-balancers, content-filters, switches, routers, etc. are still in the domain of the operations team. For any successful continuous deployment to occur, there has to be excellent communications between the two teams. In my mind, however, the devops movement is an indication that (for a rising number of emplyment scenarios) app devs can no longer be niche in their skills.
  • The  ‘antifragile’ concept: Resilience of systems and processes is discussed in Nassim Nicholas Taleb’s latest book ‘Antifragile‘. It refers to the way some entities allow themselves to be broken periodically, but then rise back stronger. Taleb is a great thinker and his unique take on these ideas are quite valuable.
  • Developer happiness: Several times, the article touches on the concept of ‘developer happiness.’ That is an area where I believe a lot can be done to enhance a team’s productivity.

Tethering my tablet to my phone

by at

Used to be that wireless tethering with my carrier was free. Since I purchased my new phone (Samsung Galaxy S3) however, that avenue has been strangled. So when I used my tablet (Asus Nexus 7 – WiFi only) I had to be within range of a convenient WiFi connection. Well, no more of that!

It takes two bits of software. PDANet for Tablets installed on my Nexus 7 and FoxFi installed on my Galaxy S3. Using the Bluetooth protocol, one can surf the web on the Nexus 7 at decent speeds using the S3’s 4G connection. Take that, unnamed carrier!