VDubinator Coder

Last year, MasterControl hired some consultants to help us transition to the Scaled Agile Framework (SAFe) . One thing they talked about has been on my mind recently. They taught us to allow the process to break. If something isn't done correctly, allow the error to occur and be highlighted in the system. This counsel isn't meant to shame anyone. The purpose behind it is to highlight the areas of the process that need some more work or focus. If we try to hide the errors or cover up things that aren't going well, we'll just end up creating more work for ourselves and slowing down the system instead of speeding it up. For me, this is difficult to do. In certain situations this can be apparent and it can be easy to follow; however, in a lot more situations, it's not quite as apparent and I normally don't think about it like I should. Let me give an example. There are a lot of times that the Product Owner will come to a team with an item to consider working o

I recently started a new, just-for-fun project. I've always heard of the benefits of having these little side projects but I rarely do anything with them because of how busy my life is right now. Since starting this project, though, I've noticed a few benefits of having a side project that's pertinent to the things I work on at work. Just recently, ThoughtWorks released the latest version of their Technology Radar . Like many others, I enjoy reviewing their radar and seeing some of the current trends in the software landscape. One of the items that caught my attention was  Lightweight Architecture Decision Records . In their description of it, they link to an article describing it and a tool that can be used to generate the records they're referring to. I liked the sound of it and I wanted to try it out. It sounded like my work could benefit from this technique. However, at work we follow a similar approach to the ThoughtWorks technology radar. We like to evaluate

Every year MasterControl holds a summit called the Master's Summit . This is a time for current and prospective users of MasterControl to see the latest features in the software, network with other MasterControl users and professionals in their field, learn how to better use MasterControl in their company, and listen to some of the best minds in the industry. As an employee, I enjoy going to meet users of the software I write and gaining a better understanding of how people use our software. It's always an illuminating and enjoyable experience. This year we even did a hack-a-thon and implemented four features that customers requested. This year, I was helping out with what we call, "test drives." This is where we set up 20 or so laptops with MasterControl installed and running with access to everything and let customers take them for a spin. Customers can come and go as they please and look at any feature they want to in MasterControl. This is nice for customer

Recently I've been reading The Happiness Advantage  and it's been very interesting. I've always believed our brains our powerful and that happiness is good for us, but this book is really illuminating on just how powerful our minds can be and just how impactful happiness can be in our lives. In the book, the author references a wide number of studies that show just how important our perception is and just how large of an impact happiness can have not only on our perception of the world, but also on our actual performance in whatever task we undertake. In this article, I'd like to briefly discuss one quality that can help give us small moments of positivity or happiness throughout our day: Gratitude. Now, I know what you're thinking. This is just a Thanksgiving post. And you're definitely right. Even still, I do think gratitude is important any time of the year and in just about any circumstance and isn't just exclusive to the end of November. So, why be

Ownership The topic of ownership has been on my mind recently. It's not a new topic. I've written about it before as well as many others such as James Shore , Martin Fowler , and Pierre Raynaud-Richard , to name a few. Most of the time, when talking to software engineers about ownership, the focus is on code ownership. While that should be a big focus, I think the issue of ownership does extend beyond that. Not only does ownership affect how we think about the code we work with, it also affects how we think about everything at our job. So, what is it about Ownership that's sparked so many people to write about it? Why has it been on my mind of late? How can ownership help you in your career? What does that word mean? I took a moment to Google that word and found one definition that really made the meaning of ownership clear in the sense that we use it in business: An attitude of accepting responsibility for something and taking control of how it develops I think t

Have you ever been frustrated with how something is at work? Have you ever found yourself feeling powerless to improve or change a certain part of your job? Have you ever wondered why things are done the way they are? Have you ever wanted to have an impact on how things are done at your job? These are some of things I've been thinking about recently. Last year the company I work for transitioned from a semi-agile process to using the Scaled Agile Framework (SAFe). Overall, it's been a huge success for the department and for the company. The fact that we even considered changing things up speaks volumes to the type of people that lead this company. The way we've been able to transition with relative ease has been outstanding to be a part of. Even with the surprisingly smooth transition, there were still bumps and there are still things to complain about. While these items bother different people to different degrees, there are some that seem to get frustrated about the c

This is and entry in a series about  Starting Out In Development . The goal of this series is to provide brief introductions to critical tools, concepts, and skills you'll need as a developer. By now you should be familiar with what version control is. If you're unsure, check out  my article  introducing it. Now that you know what version control is in general, it's time to get familiar with some of its specific implementations. In this article, we'll discuss Git, it's take on version control, and how to use it. Git: What is it? Git is a software implementation of version control. It was created in 2005 by the famous Linus Torvalds (the creator of Linux). It's currently maintained by Junio Hamano and is updated regularly. There are a number of popular tools that help manage Git repositories. Among these tools are TortoiseGit, SourceTree, and others. In this article, I won't be using any of these tools. We'll be running commands via th

This is and entry in a series about  Starting Out In Development . The goal of this series is to provide brief introductions to critical tools, concepts, and skills you'll need as a developer. By now you should be familiar with what version control is. If you're unsure, check out my article introducing it. Now that you know what version control is in general, it's time to get familiar with some of its specific implementations. In this article, we'll discuss Subversion, it's take on version control, and how to use it. Subversion: What is it? Subversion  (often abbreviated as SVN) is a software implementation of version control. It was created by CollabNet and is now a major Apache project. It's been around since the year 2000 and is fairly actively developed and updated. There are also many tools that can make using SVN a bit easier and more convenient. Among the most popular of those tools is TortoiseSVN . I'll be using that later in the

If you know me personally, there's probably no doubt that I have a few quirks or things that I do that may seem odd. One of those things is that I tend to keep up with my LinkedIn notifications. Most people I talk with tend to log into LinkedIn only once in a great while. For some reason, I'm not that way. I tend to log in at least weekly to clear out notifications and respond to recruiters (usually with the canned, "Hi Bob, thanks for reaching out. I’m not currently interested, but let’s keep in touch"). As a Software Engineer, I generally have a few recruiters a week messaging me. As I've looked over each of these messages, I feel like I've seen some good recruiting messages and some poor ones. Unfortunately I don't think I've seen any great messages. In this article, I want to share some thoughts on what I would like to see in a recruiter's message to me if they were really serious about me joining their team. It's more than technology.

I've recently had a few discussions with coworkers about the Online Master's of Computer Science program that's offered by Georgia Tech. It's a pretty revolutionary program that puts a top-10 graduate degree within the grasp of many, many more people than previously possible. There are many articles and blog posts written about it. PBS even highlighted it in a recent episode. There have been some people that have written about their experience in the program and even created a flowchart to help you decide if it's for you or not. I wanted to take a moment and capture my experience and answer some common questions I get about the program. Backstory First, let me start by telling you my story. This section should help you understand some of my reasoning behind selecting the OMSCS Program. Honestly, you can skip this section if you'd like and jump straight to the FAQ at the end. I grew up in a somewhat non-traditional home. I had a dad and a mom but my dad

Recently, I read an article called " Great Development Teams Have a Culture of Discipline ." The article got me thinking a bit about discipline and work especially as a Software Engineer. It even got me Googling quotes about discipline. I'll share just a few here: I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times. - Bruce Lee Confidence comes from discipline and training. - Robert Kiyosaki Discipline is the bridge between goals and accomplishment. - Jim Rohn Discipline is rarely enjoyable, but almost always profitable. - Darrin Patrick There are many, many other similar quotes about discipline and many of them are very good. Looking at these quotes and considering the points made in the article, I started to wonder how well I was doing with discipline. Would I consider myself a disciplined individual? A disciplined employee? A disciplined Software Engineer? That last question got me thinking,