VDubinator Coder

Who owns the code you write? Who's responsible for when the software ships? Who owns the success of the company? Who owns what you work on? Who owns your decisions? If someone comes up to you with a different priority than you were told at Sprint Planning, what should you do? The answer to some of those may be very obvious. The answer to others may not be what we'd initially think it is. In all these questions and related questions, I'd argue that the answer is "me." I have at least some ownership for my code, when the software ships, the success of the company, what I work on, what I don't work on, and what decisions I make. Let me take a few minutes and share why I think this way. I recently was in a meeting where we talk about our process at work and discuss what's going well and what's not going well. The goal is to build on the good and correct the bad. The main topic of discussion that day was in regards to some recent decisions that seem to

As many of you are probably aware, there's been quite the discussion around a certain memo shared by an employee of Google. This has caused quite a stir in the tech community. Some of it has been constructive and some of it has been divisive and contentious. I think there are a number of lessons we can take from all that's occurred. Some of the lessons I'd like to discuss briefly are about being wrong and even failing. Maybe you've heard the phrase, "Success consists of going from failure to failure without a loss of enthusiasm." (Winston Churchill) Or maybe you've heard this one, "I have not failed. I've just found 10,000 ways that won't work." (Thomas A. Edison) Or maybe this one, "failure is the key to success; each mistake teaches us something." (Morihei Ueshiba) These phrases, and many others like them, have come from people that we might call "successful." In fact, we might look at them and think they never fai

It's been a while since I've provided an update on the small group I helped create at work. To be honest, not much has changed. I share articles at least weekly and we sometimes have discussions about them. It's not a business-critical channel, so it's on the back-burner for most participants. I still have hopes of developing it into a medium for developing leaders within the company and providing those potential leaders with the resources they need to grow, but that's the end-game and I'm at level one with it right now. One thing we have decided to do is to meet quarterly (which means once every PI  for us) and have some in-person discussion or training. The first of such meetings will happen in a few weeks. I'm excited to see the participation but also nervous about it. I think we could have some great discussions and I hope something great comes of it. I hope it has a positive impact on the business and on those in attendance, but I shouldn't get my

Today in our team retrospective, one of our team's summer interns mentioned that the team seems to struggle with making decisions. This sparked a healthy discussion on why it seems that way and what, if anything, can be done about it. As I thought about that question, some tips about meetings came to my mind that I wanted to offer to this intern and to the others on my team. At first I just thought I had one or two short thoughts to share, but the list quickly got bigger, so I decided to write a blog post about it. These are things I've observed in my professional career so far. Some of these I've learned along the way, others I've adopted from articles or books I've read. Hopefully these thoughts are useful to you as well. Don't Attend Meetings You're Not Needed In The first suggestion that came to my mind is to not attend meetings you're not needed in. If you have a meeting on your calendar and you're not sure exactly how you'll contribute