A decade and a half with open source

Over the last 15 years I've been trying to move away from relying on 3rd parties for critical services I use. It started out as a way to learn what standards existed and how they worked in practice. It's one thing to intellectually know what's there, but a whole other thing to use what's there in your everyday life.

In 1999 I started with my own web server, rather than relying on a 3rd party host (like Geocities). I bought a decent desktop computer and installed Slackware and Apache httpd. This has been crucial in my career growth as it allowed me to learn new web technologies as they've come out.

In the early 2000's I decided to run my own mail server. I tried out several and finally landed on qmail. It worked well on Slackware and it supports SMTP Auth. I added IMAP support using Courier IMAP. But I've since switched to Dovecot. qmail also supports integration with SpamAssassin for SPAM detection and filtering. 

In the mid/late 2000's I heard about a new web based mail client called RoundCube. It supported drag and drop like a native email client and I was hooked because it allowed me to remotely access my email with a feature rich client similar to what I had been using via native clients. In the last several years it's added support for plugins which have brought CardDav and CalDav integration.

In 2007 I built my own RSS aggregator (which I have since open sourced) as a way to learn Ruby on Rails. This has been the single greatest learning tool for me. Every time I want to learn a new language or platform I write a client for my aggregator. Google's decommissioning of it's rss client had zero affect on me :)

About four years ago I decided to move from running my services on a standalone desktop box to running them on a server in my own cloud. The big reason is that I needed a server that I could tinker on that won't affect my email, calendar, contact, and file access. So I built my own server and installed XenServer. This has allowed me spin-up and play while also keeping my critical services running rock solid.

About 3 or 4 years ago I ran across Owncloud. I was looking for an alternative to Dropbox because I wasn't happy with Dropbox's model of having to use their software to access my files. Owncloud was revolutionary in allowing me to stop relying on 3rd party services for access to my critical data. After installing Owncloud I controlled my calendar, contacts, and files.

Sometime in the last 3 years I stumbled across GitLab, an open source alternative to Github.  I write a lot of software at home but much of it is very specific to things I want to do and aren't really interesting from an open-source perspective. GitLab allows me to work on private projects and access my source code using a remote git server. When something becomes useful to more than just myself I open source it. 

Do network stations not care about being relevant

I'm a cable cutter. Not literally. I mean I don't go around the house looking for cables to cut, but I did drop cable T.V. a little more than 6.5 years ago. Not because I think TV is evil, and not because I wanted to be able to say I don't have cable (some people seem to be proud of that). But simply because I was bored of programmed television.

I found myself flipping through channels searching for something interesting to watch and never finding anything I was in the mood for. Or, even worse, finding something in the guide but having to sit through 15 minutes or 30 minutes of another show waiting for the show I wanted to come on.

At the time I was working on the video team at MSNBC working on streaming MSNBC content on the web and mobile devices. My wife and I were also starting to become more and more invested in the convenience of Netflix. Who wants to wait a day for a DVD when you can stream something immediately.

Netflix changed our viewing habits. For the first year or so Netflix streaming for us was about streaming full length movies. Basically an alternative to going out to the movies or to renting a DVD. But eventually we started using Netflix to primarily watching TV shows. I don't think I realized at the time but what I love about Netflix and other video streaming services like Amazon Instant Video is that I'm in control. I decide when and how much I want to watch.

Streaming video on-demand is about being in control of the content. Some days I may not have any time to watch anything, other days I may have enough time to watch a show or two, and sometimes (pre-kid) we'd spend an entire Saturday just relaxing and marathon watching a series.

On-demand video also makes me feel like I have more context between episodes. I'm actually more invested in the characters because I'm choosing to spend more time with them rather then being told when to spend that time (with a scheduled show that may or may not be convenient to my schedule).

All of this is to say that I think current TV programming is only good for live events. Programmed television was made for watching late night TV, Sports, the State of the Union, the debates, or even news. But the days of programmed television for a drame, sitcom, or any other series are over.

So why are the networks only streaming to current cable/satellite customers? It would seem to me that there'd be a whole market of folks just like me who'd be willing to pay $15 a month for on-demand access to network television shows (Hulu anyone?). It seems like the only way for places like NBC, CBS, and etc to complete in the new world order is for them to own their streams and to make them available à la carte.

Do network stations not care about being relevant? 

Learning to Lead: Accountability

In my previous post in the Learning to Lead series I talked about leaders needing to be motivators. In this post I'd like to talk about accountability.

Responsibility vs Accountability

As a leader you're often going to be the situation of being accountable while ultimately not responsible for a creating the solution. This is particularly true for managers where they're accountable for the delivery of a project or feature but not responsible for the implementation.

The danger of being accountable for something but not responsible is that you'll either end up micro-managing or under-managing those responsible for solving the problem. There's a really fine line between micro-management and under-management. One helpful phrase I've heard and used in my career is trust but verify. This means that you'll have to delegate to others and trust them relative to their experience and skill-set but verify that they're on the right track.

There are several helpful tools that can be used to practice trust but verify.

• Project burn-down reports
• Agile stories and tasks
• Architectural design documentation
• Daily scrum
• Demo day

Solving the correct problem

Being accountable means ensuring the team is solving the correct problem. This is easier in an agile environment as it's the product managers role in sprint planning to be the voice of the customer. But that doesn't ensure that during a sprint the team isn't randomized by outside work or out of band requests.

Accountability means being able to prioritize and make hard decisions on what the right thing to work on is. Often this means coordinating with both product, management, and other senior leadership to weigh the pro's and con's of new work that comes in.

One easy way to make accountability part of your teams culture is to practice it during your daily scrum. It's up to the engineering lead and other leaders to make sure that as people go through what they're working on today at stand-up that it's the most important work that needs to be completed. If someone says they're about to start something that's lower priority than some other work the team should be calling out the discrepancy and holding each other accountable to working on the correct stories/bugs.

Raising the red flag early

Another area of accountability that I'd like to call out is being willing to raise red flags early enough for them to be acted upon. In the technology industry we make a lot of decisions and set schedules based off of estimates. Once a project is set in motion it's often uncomfortable or unpopular to raise a red flag. As a leader though, you're accountable for the overall health of the project. If your estimates are incorrect or based on incomplete data it's important to raise the red flag as the project is ultimately unhealthy.

When raising this flag the accountable party should be able to explain why the flag is being raised, as well as what it would take to remove the red flag.

Learning to Lead: Motivating People To Solve a Problem

In my previous post in the Learning to Lead series I talked about how being able to facilitate a conversation is an important leadership quality. In this post I'd like to talk about motivation and how the ability to motivate sets great leaders apart from the rest of the pack.

Many people's first reaction to motivation is to think about compensation. While compensation is an important motivator, it's not the ultimate motivator. If you haven't already, go watch the surprising truth about what motivates us. It debunks the myth that money is the ultimate motivator and is a great introduction to the type of things that will motivate once money isn't a worry any more.

I truly believe that the ability to motivate is one of the things that truly sets great leaders apart. Being a good motivator is not about being a cheerleader or always being positive and perky. While those things are occasionally required, motivation is about so much more than your attitude or presentation. Motivation is about being able to call others to action. In the tech industry this is especially important because lack of motivation has a direct correlation to loss of productivity, slipped schedules, and quality code (i.e. buggy and/or unmaintainable).

In my experience as both a software development engineer and as an engineering manager, there are three key areas to focus on when trying to motivate individuals or a team.

Impact

Engineers should understand the impact of what they're working on. This comes in the form of understanding the short term, mid-term, and long term benefits to their customers and their team. They should have enough information to understand why their work is important and to empathize with those that need it to be completed. Most engineers thrive on knowing that their work is being used by other people. It's much the same as an musician being motivated by knowing that others are listening to their songs. Or an author being motivated by knowing that someone is lost in their narrative.

Interesting

This may sound obvious but the work that's being done should be interesting. If your engineers feel that what they're doing is busy work, repetitive, or monotonous they're not going to be motivated to complete it. In this case you need to learn to correlate the current work they're doing with something that is of interest to them. Often I've seen lack of interest when a team is in bug fixing mode or just about to ship a product. In this case it's important to emphasize how what they're working on now enables them to work on the next big thing.

Another way to help make the work interesting is to find a tie between it and their career development. Maybe it gives them exposure to a broader set of skills or technologies. Maybe it allows them to check a box on their career goals or will help prepare them for being promoted to the next level.

Relate

The engineer needs to personally relate to the problem in some way. The best way I've found to help engineers relate is by dogfooding their own software. Using their software everyday in their personal lives will help them see what others are experiencing. It will help them want to fix the pain points that otherwise wouldn't be important to them.

Learning to Lead: facilitating conversation

In my previous post in the Learning to Lead series I talked about how earned trust is the cornerstone to leadership. In this post I'd like to look at another aspect of a good leader; facilitating conversation. Being able to facilitate a conversation may not be at the forefront of the qualities you attribute to good leadership, but I think it should be. Being able to facilitate a conversation shows a level of maturity that's needed in order to lead people successfully.

Ensuring the purpose is known 

Every conversation has a purpose and I'm still surprised at how often I've seen two people arguing with each other simply on the basis of not having a shared understanding on what the purpose of the conversation is. A good conversation facilitator will be able to articulate in a meaningful way the purpose of the conversation. Often this can be accomplished by stating what the desire outcome is right at the beginning. For example, "Today we're here to talk about FOO and make a decision about BAR with regards to FOO."

Getting people to participate

One of the keys to being a good conversation facilitator is getting people to participate in the conversation. This can often be difficult for a variety of reasons like people being uncomfortable talking in large groups, not wanting to speak up, having a lack of confidence, being intimidated by their peers, and etc. A good leader is able to encourage participation in the conversation without it being awkward.

Some tips for conversation facilitation:

• Ask open ended questions. This discourages one word responses and encourages meaningful conversation.
• Don't be afraid to let the room be silent. Often people trying to facilitate conversation will talk and talk and talk so as to avoid silence. Not everyone is an off the cuff thinker. Silence allows people to process what they've just heard and formulate a response. The key is figuring out when it's been silent long enough the the conversation needs help.
• Recap. This is useful at the beginning of the conversation as well as the end. At the beginning of the conversation it's often helpful to recap what the goals of the conversation are. For example, "when we finish today we should have a plan of record for...". At the end of the conversation a recap is useful to make sure everyone heard the same thing.
• If you know someone is passionate about a particular topic but not eager to put forth their opinion, you can try to gently guide them into the conversation. This can be as simple as saying "Tom, you and I were talking about something similar the other day which makes me believe this is something of interest to you. I'd love to hear your opinion on ..."
• Be direct and ask someone else to respond to a particular comment or statement. This can be especially useful when someone is steam rolling the conversation. For example, "Harriet, what are your thoughts on what Bill just said? Do you agree or disagree that..."

Avoiding derailment

Tangents are unavoidable, especially if you've got any "talkers" in the group. But tangents don't have to derail the conversation. A good facilitator is able to keep the conversation on topic. One common reason a conversation gets derailed is if someone else has an agenda that's not part of the purpose of the conversation. A good facilitator is not afraid to steer the conversation back on topic. This can often be accomplished by saying "Jess, that's a great point but I'm not sure that this is the correct venue for it. Let's set aside some time specifically to talk about that so we can use this time to talk about ..."

Another way conversations can get derailed is if you've got someone that rambles. What I've often found is best is to tackle a rambler head on. You can do this by jumping in and saying "That's a great point Sue, I'm curious to hear what other people think about the topic as well." Occasionally you have to be blunt and say something like "Greg, the latter part of what you're saying isn't really pertinent to the conversation at hand, let's stick to this topic now and we can get back to the latter part of what you're saying at another time."

Learning to Lead: It Starts With Trust

In my previous post on being a Senior Software Engineer I talked about one of the characteristics that defines the role is being able to get people to want to follow you. At it's heart the problem is one of trust. People don't want to follow someone they don't trust. What does it take to gain trust? Fully answering that question would probably take a novel. But at a high level I believe there are five key aspects to earning the trust of others.

Honesty

Any conversation about trust needs to start with honesty. At it's core honesty is about NOT deceiving others. As a software engineer that means you're able to:

• Say I don't know when you don't have the answer.
• Remove personal bias when evaluating a solution. When you can't remove the bias, it means communicating that bias clearly.
• Give credit where it is due (i.e. don't take credit for others achievements).
• Publicly recognize the achievements of your team.
• Provide clear, constructive criticism when someone is not doing something well.

Integrity

Being a leader means having a known set of guiding principles that you hold yourself and others to. The key is that you hold yourself to them FIRST. It's also important that the value of these principles is understood by others. It helps if others agree with these principles, but even if they don't knowing that you're holding yourself to your own standard helps earns trust.

Respect

The key to gaining the respect of your peers is to start with respecting them. In the technology industry this means valuing others skills and abilities. Not just the skills and abilities that you find value in, but also the skills and abilities that THEY find value in. Respect involves holding others achievements in high esteem.

Transparency

In my opinion transparency as a leader in the technology industry is not about making sure everyone knows everything you know. That can actually be detrimental to the team. It can add unneeded stress on those that don't have the context or the maturity to deal with the information.

Instead transparency as a leader is about making your motivations known. Help people to understand why. Why you're asking them to do something, Why something is the correct priority. Why somethings not the right direction for the team or project.

Fallibility

The last key aspect to earning trust is being able to admit when you're wrong. Everyone is human and humans make mistakes. Being able to admit when you're wrong sets the tone that it's okay to acknowledge your humanity. Once you're able to admit you're wrong you can start to correct the problem.

Senior Software Engineer

One thing I've noticed throughout my career that's been pretty consistent is the desire of software engineers to be given the title Senior Software Engineer. I've seen many people claim the title without truly understanding what it means or what the role entails.

The Misnomer

Often I've seen people given the title or claim the title based on the number of years of experience they have or based on the fact that they have more technical chops than their peers. Being a senior software engineer doesn't have anything to do with years of experience, but instead is about maturity as an engineer. While the two may be correlated (highly so in many cases) there is not a causation relationship. I've seen just as many tenured developers who were no more senior than their counterparts fresh out of college. It's also not only about your technical ability (while that is a large part).

If years of experience don't define a senior engineer and being the most technical person doesn't then what does? In my opinion a senior engineer is someone who manifests most, if not all, of the following characteristics.

Language/Platform Agnostic

A senior software engineer may have language or platform preferences but they're able to deliver on any platform. This is because they understand system metaphors, abstractions, and compositions well enough to know how to learn what they don't know quickly. They identify the correct metaphors, abstractions, and compositions needed to be successful and realize that the syntax and libraries are just implementation details.  

Able to identify and articulate trade-offs

Building software is always about trade-offs. They are able to take schedule and scope into account when building a solution. They understand and are able to clearly articulate risks. For example, a senior engineer knows that with a fixed schedule scope must be variable. They're able to identify and clearly articulate what the proper scope is and what features are at risk.

They're about shipping software

First and foremost, a senior software engineer is able to deliver software. They deliver software in large volumes. This is largely to do with their ability to understand and quickly get through boilerplate code in order to focus on the real problems. They understand that unshipped software isn't making the business better.

Able to get people to want to follow them

Solving complex and ambiguous problems is a requirement of being a senior software engineer. But being able to solve those problems isn't sufficient for the title. A senior software engineer is able to successfully lead a team. They're able to motivate people to solve a problem, hold people accountable to solving the right problem, and get down to the level of other less experienced developers in order to stretch them and help them achieve goals that are beyond their current abilities. 

Able to simplify a complex problem

Senior software engineers are able to see through complex problems and break them down into smaller, easier to solve, problems.

Understand the correct amount of engineering required to solve the problem

Senior engineers don't over engineer solutions and likewise they don't under engineer solutions. They understand that software is meant to solve a particular set of problems while needing to stay maintainable in order to increase the lifespan and usefulness of the product. They recognize that the elegant solution is not always the correct solution. They also have the ability to take a complex problem and identify the potentially fragile portions of a solution and design around them without over generalizing a solution or making the solution less useful in solving the problem at hand.

They recognize that everything doesn't have to be "built here"

This one is pretty straight forward but difficult in practice. Senior engineers recognize when a particular problem is not part of the groups core competencies and look for external solutions. While a particular problem may be interesting, unique, or fun a senior software engineer is able to recognize when solving that problem in house doesn't add any business value or add burdensome tech debt.