Thursday, December 22, 2011 #

Advice for Young Developers: Learn to Make Your Own Decisions

Everyone has an opinion. When you embark upon your first real job as a programmer you will find this out very quickly. I have found that software developers can be some of the most opinionated and dogmatic people you will ever meet. This certainly is not a bad thing. However, young programmers will need to cultivate the ability to make their own minds up when it comes to how to write software.

There are those who start out in a corporate environment where the styles and conventions used have already been established. There is not much you can do usually in this situation, at least not right away. I am speaking to those who may have a say in how things are built. Such a position usually requires that you do research on the best way to solve certain problems. You research design patterns, OO principles, etc. Everyone has an opinion on what the best way is this can cause confusion. The remedy is to simply make up your own mind. 

Whose side are you on, anyway?

It may be helpful to look at some examples of what I mean.

No view left code-behind – The MVVM debate

I have been using WPF and the MVVM pattern. There is the great debate as to whether there should be code in the View’s code-behind file. Many will dogmatically say no. Some will say yes. Others will say sometimes. Which side are you on? That is a decision that you have to make. As for me, I’m on the sometimes side. It’s important to me to remain balanced. An example is animations. To me, it’s seems silly to be so dogmatic that you create more unnecessary complexity just to keep code out of the code behind. In the code behind I can do this to fade in an element over 400ms:

someElement.BeginAnimation(opacityProperty, new DoubleAnimation(0,1, new Duration(TimeSpan.FromMilliseconds(400))));

Or I could implement a complex solution such as this. Neither is wrong in the right situation. A choice has to be made. I simply prefer the first choice in most scenarios.

Inter-face off – Too many interfaces?

Another example is the use of interfaces. I have heard countless times that proper OO design means always coding to an interface. Then you can switch out implementations without changing the client code. This is certainly a noble ideal. I started writing everything like this at first. Now I don’t create an interface for every single class that I need to use. Why? Because I read the other side of the story. The summary of the previous post is that it is pointless and a form of premature optimization (the author uses the term “speculative generality”) to create interfaces when you know that they will only have one implementation. Why create an ICustomer interface when you know that only the Customer class will implement it? The proper way to do it is to actively refactor your code. When you see two or more classes that use the same or similar methods and properties, then refactor to include the appropriate interface. Only create interfaces when there is a demonstrated need. Again this is an issue where you have to choose what you think is the best solution.

Yeah, but what does this mean to me?

Opinions are everywhere. It’s easy to get lost in them. Just remember these important points and you will be fine:

1. Don’t take your code too seriously. Chances are, your code is not as good as you think it is. There is always a better way to do it and you rarely do it right the first time. So don’t obsess over the “right” way to do something. It doesn’t exist. And don’t be afraid to refactor when you do find a better solution.

2. Context is everything. Most solutions do not work in all situations. One of the most difficult parts of software development is learning the right thing to do in certain contexts. Just because you can do an Abstract Factory, doesn’t mean you should. You don’t have to avoid code-behind files like the plague. Don’t overuse them either. Everything is relative.

3. Remember why you’re there. You’re main purpose of being a software developer is to bring value to the business. That means not wasting the company’s time and money implementing unnecessarily complex solutions over simpler ones that work fine just because so-and-so said you should. Is he going to personally come and inspect your code? I doubt it. The business will be grateful for well-designed solutions that don’t take forever to build, and it’s the business’ opinion that you should care about.

It doesn't matter what decision you make, only that you make an educated one. Listen to both sides of every story and then listen to your gut.

Posted On Thursday, December 22, 2011 9:25 PM | Comments (11)

Copyright © jboyer

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski