VDubinator Coder

I've been thinking a bit recently about getting things done and what holds up back. I've noticed some people seeming to take a long time to commit code to a repository or be hesitant about diving into something. I've been contemplating that and what might be causing the hesitancy. I've been there before. I've been worried about breaking things or worried I might not do well if I accept a certain item at work. As I've thought about it and my own personal journey to overcome it, I think I have one piece of advice for my former self and those in similar situations: don't let perfectionism hold you back. The Problem with Perfectionism There's a certain part in everyone that wants to make sure they don't look like a fool. This is a natural, defensive response to protect you form pain. It's there for good reason! But sometimes it goes to an extreme. Sometimes this part of you tells you that you can only do something if you're perfect at it

One question I unsurprisingly get when others learn I'm working towards a master's degree in Computer Science is, "what do you plan on doing with it?" There are many variations of this question such as, "will that open any doors for you?" I think at the heart of all these questions is "why?" Why would a reasonably successful software engineer get a master's degree? They obviously don't need it since they're successful already. Why get another degree. Honestly, that's a tough question. I'm not sure I have a "good" answer for it. I'm not sure I fully understand why I'm getting a master's degree either. I know that growing up I always wanted to earn one. My dad got an MBA and there's something about the "master" thing that just seemed cool to my young mind. But why me? Why now? Why now is a pretty easy question to answer. It's easier to do school earlier in life than later. It's more

For any reader of my blog, you may have noticed that my content isn't fantastic. In my opinion, it's mediocre at best. As I go through my life, I get ideas on what to blog about. Sometimes those ideas are easy to formulate into posts and sometimes they're not. Sometimes I have a lot to say and sometimes I don't. Regardless of how passionate I am about the topic I'm choosing to blog about, there's one thing that keeps my posts in check and limits the time I get to spend on them: time. As a full-time software engineer, part time Master's degree candidate, full-time husband and father, and active member of The Church of Jesus Christ of Latter-day Saints, I have a lot going on in my life. I simply don't have the time to dedicate to blogging that I hope to have in the future. Believe me, I want to make these posts perfect, I want to spend time researching, drafting, revising, and polishing each post, but I simply don't have the time at this stage in my

I was recently invited to participate in a focus group to help brainstorm ideas for a billboard the company I work for is planning running. It was a cool experience. I didn't know much before going into the meeting and I was worried they'd be expecting those they invited to come up with the golden idea for the billboard. Thankfully it wasn't that way. It went a lot better. The meeting was held early on a Monday morning. I was unusually late to work but still there before the meeting started. As is standard, we got started a few minutes late anyway as we waited for a few others to trickle in. Those in the room were mainly in technical roles within the company as the billboard is to draw more technical talent to the company. There were a few software engineers of varying experience, some quality assurance engineers, a development and QA manager, a recruiter, and two people from marketing. The recruiter was the one running the meeting and she started off quickly stating ever

While I was working towards my undergrad at Utah State, I had the opportunity to do tech support at a local web hosting company. While I was there, I acquired and honed basic troubleshooting skills that have helped me be a better software engineer not only when debugging problems, but also when designing software. This is my attempt at sharing these skills with you. Know Your System The first item that will help you improve your troubleshooting skills is to know your system. While working tech support for a web hosting company, I found that the more I knew about our internal systems as well as the internet in general, the easier it was for me to assist our clients with the issues they encountered. When I had an understanding of how a request goes from the client's machine, to our servers, and back again, it helped me in identifying possible failure points based on the issues the client described. The same was true when I gained an understanding of how web servers served files

This week was a bit of a slower week. A number of people that usually participate in the channel were out of town. Even still, we had some decent thoughts on these two articles: Every Day We Must Sweep and  From Engineer to Manager: keeping your technical skills . I'd like to share one observation I made: Be Vulnerable Often times as leaders we think we need to appear invincible. For some reason we think in order to lead, we can't show weaknesses. While that may be a good mindset to have towards an opposing force in war, it doesn't work well towards those you lead. If you want those you lead to follow you, you need to be vulnerable at times. You need to show them your weaknesses and how you overcame them or how you're overcoming them. This doesn't mean you need to be publicizing your weaknesses, but it could mean recognizing them when they come up naturally or sharing stories about them while mentoring and coaching those you lead. Why Be Vulnerable?

It's been a few weeks since I started posting questions along with software leadership articles and I think I've learned a few things along the way. What follows is a brief list of things I've noticed: People respond more to simpler and shorter questions. Citing quotes from the article often doesn't illicit any more response than just a question without a quote. It's okay to ask questions you already think you know the answer to. Internalizing the content and applying it to the situation at work often sparks more discussion So far I've posted questions and refrained from offering my point of view. This has had mediocre success. I'm going to start posting my thoughts to at least one question going forward to see if that prompts more discussion. There has been one other person who has shared an article in that channel in Slack which hopefully means that at least one other person finds the channel valuable and they're comfortable enough sharing thoug

In the world of big software projects, frameworks are common place. Frameworks attempt to make common activities easier to do. They promote code reuse and try to reduce the time it takes to write software. But what are you giving up when electing to use a framework? Let's take a look at a few of the disadvantages of using a framework and some things to consider when choosing a framework. Downfalls Architecture In creating a framework, there are necessary architectural decisions to make in regards to how the framework will operate and how it will interact with other frameworks and libraries that may be used in conjunction with it. Because the framework is designed to solve specific problems, it may limit the architectural patterns you'll be able to use if you elect to use the given framework. Design Patterns Similar to architectural limitations, the framework designers also chose a certain set of design patterns to implement. In so doing, this will occasionally limit t