October 01, 2017

Opening Thoughts

On Friday 9/29/14 I attended Rocky Mountain Ruby in Denver, CO. It was my first tech conference, so I didn’t really know what to expect. I decided to share my experiences as a first-time attendee in case any other first-timers want to know what to expect at their first conference. This is not mean to be a review of the conference, but a journal of my thoughts and experiences on the conference as it relates to my particular situation.

About that situation: As a new developer who works at a music school, I am painfully aware of the fact that I have no mentor and next to no tech community. There are no other developers at my company, and the hours of my job keep me from attending the local meet-ups apart from an informal monthly Ruby programmers’ lunch. At this conference, I was hoping to meet some people and gain some insight that would help me on my own journey. I spent some time talking to the others at my table before the presentations started, and they were welcoming and interested in my project. In fact, those I talked to seemed more interested in hearing about my project than in talking about their own. It meant a lot to me to be taken seriously at a table full of experienced coders.

The theme of the conference was Trust. Most of the presentations centered around leading or working in teams. This meant I was feeling the deficiencies of my lone-dev situation pretty much all day. The thought that gradually formed in my head over the course of the day was, Tech is about people.

The Speakers

Sarah Mei took the podium first to talk about the limitations of viewing software development as engineering, pointing out that today’s software is not like a building that you erect and leave behind, but rather a dwelling that you live in for an extended period of time. The focus should be on making your codebase livable rather than presentable. I was excited when Sarah quoted Conway's Law, "Organizations which design systems are constrained to produce systems which are copies of the communication structure of these organizations." My app is mostly about communication within an organization, so Conway's law has been pinned to the top of my project task list since I discovered it last year. I always love when someone with experience refers to something I've found to be important. It makes me feel like I'm on the right track.

Amy Chen gave an intro to Kubernetes and using containers to trust that your app will run correctly, and recover gracefully, wherever it is deployed. I mentally filed this under "future" – I'm currently deploying with Heroku to free up my attention for other tasks, but Kubernetes looks useful for the day when the cost of deployment on Heroku exceeds the value of the time I save by using it.

Carrie Simon talked about the great work being done by Defy Ventures, a group that teaches coding and entrepreneurial skills to prisoners. Graduates of their program have a 95% employment rate after release and a 3% recidivism rate (compared to the 70%+ national rate). People I spoke to after the conference were excited about the work being done by this organization. Defy is currently expanding into Colorado, so hopefully the interest generated at this conference gets them off to a good start. Click here to see if Defy is active in your state, or click here to donate.

April Wensel co-presented along with conference organizer Jeff Casimir about compassion among the members of a team. The insight from her presentation that stuck with me is that when a developer blows up at their team, it’s usually because they are passionate about some aspect of the project, to the point where in their mind its importance surpasses that of courtesy, compassion, or any other interpersonal aspects of the project. This type of unacceptable behavior springs from good motives and thus can be redirected to positive expression, unlike unacceptable behavior that springs from bad motives (such as racism or sexism).

After lunch Anjuan Simmons took the attendees through the values of the Agile Manifesto. For each one, he identified a leadership behavior that embodies that value to the benefit of the team. This presentation was one of the more implementable ones for my situation, because the behaviors discussed reached beyond tech teams to include customers, users, and the code itself. My situation doesn't allow for Agile practices, like a scrum or pair programming, but I have always tried to apply Agile principles to my project, and I think Anjuan's behaviors will help me do a better job of that.

Adam Cuppy discussed feedback cycles and their role in reducing uncertainty. My takeaways: The more uncertainty that surrounds a project, the shorter the feedback cycle should be; and if a feedback cycle does not reduce the level of uncertainty surrounding the project’s direction or outcome, it should be eliminated. What struck me most, though, was comparison of two types of leaders: Those who are hard to please but easy to disappoint, and those who are the opposite. Moving from the first type of leadership to the second changes the values of a team, emphasizing intentions, growth, and contribution over results, compliance, and loyalty. This is by far a better environment to grow in, and as a new developer I want to remember this when I'm an old developer.

Elaine Marino of Equili talked about the diversity issues in tech and some of their causes. She made the point that all human beings, despite our best intentions, are biased in favor of those similar to ourselves, and we see own needs more clearly than those of others. Thus, diversity issues arise naturally unless companies make a conscious effort to serve the needs of employees from varying groups. To state that a little differently, tech companies have diversity problems in part because their working conditions and benefits are structured for the employees they have, rather than the diverse group of employees they want. One example given was that free soda, massages, and game rooms are likely to attract different employees than parental benefits would.

Vaidehi Joshi explained Graph Theory to the group, from its origins in a small Russian town to its many applications, including both Computer Science and Kevin Bacon. Vaidehi started off talking about how the inventor of Graph Theory abstracted real-world situations into an algorithm that reflected a physical reality, then moved into applications that are less objective and more opinionated, such as Google's PageRank and the various algorithms used to create a social media feed. These algorithms affect the information that we see on a daily basis, and thus subject to questions of trust and fairness. The point here is that as developers, we like to think that our algorithms are objective, but many times this is not the case. We need to be aware of the moral implications of the tools that we create.

Brittany Storoz ranted articulately about the poor state of error messages in most programming languages and frameworks. This talk hit home for me, since I’ve already gotten used to Rails’ combination of unintuitive top-line messages combined with gigantic stack traces, which baffled me a year ago. I must do better. I will do better.

Ben Orenstein presented on the benefits of type systems in general and Elm in particular. His persuasiveness made me wonder, if static type systems are so obviously great, why are so many beloved languages dynamically typed (including Ruby)? Many old languages like C are statically typed, as are most new languages I hear about, so what happened in between to propel language design in the opposite direction? This is the topic that will send me to Google for more research.

Closing Thoughts

It was striking that none of these presentations were about Ruby. Maybe it's because Ruby is a fairly mature language, but I would have thought recent additions to Rails and some of the proposed changes to Ruby core would have merited discussion. At the end of the conference, organizer Jeff Casimir said he's coming to believe that language-centric conferences are nearly obsolete, since most projects use multiple languages. I appreciate this point of view, but, well, I came to learn about Ruby, and in this I was disappointed. Ruby was barely mentioned, except for its flaws. Are rubyists bored with talking about Ruby?

Much of what I learned from attending will not be applicable to my current situation, but there’s a bright side to that. I don’t have preconceptions from tech teams I’ve been on in the past, since I haven't been on any. I’ve now been forewarned of some of the difficult situations that arise on tech teams, so in the future I’ll be able to anticipate, minimize, and handle issues when they arise. My conception of how a team should operate will be based on what I learned here.

I went into this conference unsure what to expect, and left unsure what to think. The lessons I learned were valuable, but from my perspective they presumed years of experience in a tech team. There was much talk about how to create an environment for junior developers to grow in, but very little in the presentations that was aimed at junior devs themselves. The talks gave me many goals for the future, but few action steps for the present. The other attendees I spoke to seemed much more energized by what they heard, though, so I think I was the outlier in the audience.

After the presentations, we adjourned to a restaurant across the street for some social time. I met a few people who, like those I met in the morning, seemed eager to hear about my project. These people included a member of an interesting startup and a Github employee, and again it was incredibly validating for them to take an interest in me and my work. For all the talk of toxicity and exclusion in this industry, the developers I've met here and elsewhere have been fantastic people (disclaimer: I am a straight white man; your experience may vary).

So what did I learn? Tech is about people. Mostly good, kind, reasonable, and interesting people in my experience so far. But even good, kind, and reasonable people need the right environment and relationships to flourish and maintain their best qualities. The quality of your code is a direct result of the quality of your team. What's the quality of my team when it's just me? Apparently, that will depend on my environment and my relationships with the customer, who in this case is all of my non-technical coworkers. I didn't learn much about Ruby, but maybe I learned that my knowledge of Ruby is not the biggest factor in how this project turns out. As one of the presenters said, "I've never seen a project fail for technical reasons."