October 5th, 2009
To solve certain problems you have to think outside of the box. I use to hear this phrase a lot. I always had a hard time trying figure this one out. If I am in the box, how can I think outside of it?
I found it easier to think about it another way. Most problems you encounter have numerous solutions. A given problem is like looking at an object outside of your window. You are seeing an obscured and sometime partial image of the real thing. Walking outside for a closer can give you a different perspective on what you are looking at. A different outlook can aid in solving many brain stumpers. You should give it a try sometimes.
Tags: Thought
Posted in Programming | 1 Comment »
September 20th, 2009
Normally, I think this isn’t the best idea. Putting effort towards a solved solution seems like a waste of time. Why go with the crowd? Development should be fun. Below are a few reasons why some deviate from the path.
Complexity can be a reason to do this. When you are trying to write code there are probably at least dozen libraries that you can use to solve your problem. Any library can have the functionality you need an a lot more. As a developer I have asked myself the question, why learn this API? I can write a solution on my own before I finish learning this API. I think some of us lived through this once or twice. A great thing about development is this, you can write just about anything. However, it’s going to cost you.
Speaking of cost, cost can be another reason to restart an effort. For example, Microsoft’s Visual Studio has a few hundred dollar price tag. I can easily see someone saying, “That costs too much. I will write [fill in the blank] on my own.” Great packages have come from this line of thinking. The word Linux comes to mind.
Finally, the need to reinvent. I know, I am really ground breaking with this one. But sometimes, people feel they have to re-due what has been done. It’s not logical at all, but it happens. A non-logical epiphany inspires a new logical approach. Now that is irony.
Tags: Reinvent
Posted in Programming | No Comments »
July 1st, 2009
Before you write a single line of code, have a design or plan. Plans come in all shapes and forms. You could have a formal design document, a UML diagram drawn on a cocktail napkin, or an idea you thought about for a few hours. Regardless of the level of polish, you need a plan.
Be flexible and not rigid. You may have spent ten days designing a complex and elegant solution that will not work. Why continue and try to implement this? You are wasting time and energy. This is why you must be flexible. If your plan isn’t going to work you should readjust your plan. Also, allow yourself to be flexible. You will always learn something new, and realize, “uh, that really is not going to work is it.” Go with this realization and adjust.
I saved the topic of execution for last, because it’s the most important of the three. If you have a good plan, execute it. I have seen beautiful design that are poorly executed or not executed at all. Execution is more important when you are on a team. Everyone on the team should play his/her role and not go lone wolf. Not executing the plan on a team is more devistating then coding alone.
Tags: Execute, Flexible, Plan
Posted in Programming | 1 Comment »
June 20th, 2009
There is a saying in software development, you write it first and then you optimize as needed. This is a very general rule and works much of the time. However, when you need your solutions to scale from day one, you can throw this rule out the window. Well, you aren’t really throwing the rule out, you are modifying it. The new rule is to write it optimally first when the solution needs to scale.
Going to the supermarket is a solution the needs to scale from day one. Let say we have two scenarios: you need to pick up two items and you need to pick up twenty items. I see two real approaches to the problem. The first would be to go to the store every time, and the second is to go only once. Going once is more optimal and it scales. Think of how much time and resources I burn up going to the store each time. You can argue that going to the store twenty times is not that bad, but what about 100 times. My point should be apparent now. Going to the store one time for every one item is inefficient
Let’s replace the supermarket drive with a database call. When you need to retrieve thousands of records, going to the database for each record can be costly. This is a common pitfall in development, the solution to retrieve information one item at a time is probably plaguing your world as we speak. You ever wonder why things take so long, the code in use may suffer from inefficient retrieval.
Tags: Inefficient, Scaling
Posted in Programming | 8 Comments »
June 1st, 2009
This is not true 100% of the time, but the majority of the time this is correct. There have been times, I “fixed” a problem. Only to realize I didn’t fix anything. However, I did break working code. After you have done this a few times, you will learn.
In an attempt to reduplicate the problem, here are a few questions that may help. How did this happen? What are the steps taken that caused this problem? What has changed that I don’t know about? When was the last time this worked? Answers to these questions will uncover the steps that lead to the problem.
The process of fixing bugs is not magic. Chances are something was overlooked or a scenario was not accounted for. Again, not magic. Get into the habit of trying to reduplicate the issue. Once you can reduplicate a problem, it’s usually pretty straightforward to resolve.
Tags: Bugs
Posted in Programming | No Comments »
May 22nd, 2009
Testers make your job easier so don’t give them a hard time. You would think most developers realize this, but most don’t. I have seen countless times where developers believe a tester is out to get them.
I know some are thinking how does a tester help me. I write code and a tester will try to break that code. Let me let you in on something, you want a tester to find your bugs before it goes into production. Dealing with production bugs are stressful. Personally I like when something is found in a test cycle. That is one less issue to pop up when I am focused on some other project. Trust me, this will happen.
Tags: Testing
Posted in Programming | 1 Comment »
May 22nd, 2009
C# is the language that is keeping the lights on right now. I had a conversation with a fellow programmer about refactoring and optimizing code. C# is compiled by a very refined compiler. I am hugely generalizing the process here, but the compiler can determine your intent and provide output based on that. This means you could write a method ten different ways and still produce the same output from the compiler. What does this mean? Let’s say I originally wrote a method and was happy, then I learn about generics. I rewrite the method to use generics. Rinse and repeat and eight times later, the compiler still produces the same output. Maybe my code is more readable after the ten refactors, or maybe not.
I wanted to illustrate the unecessary effort we sometimes fall victim to. A more wholestic approach would be this. Compose a solution to a problem, run your solution under some sort of load test, and analyze the results. Your analysis should show the inefficiencies. Then you target those areas for improvement.
Tags: Refactoring
Posted in Programming | No Comments »
Read The Comments
May 22nd, 2009There comes a time in a developer’s life where we have seen bad code. This happens relatively fast in your development. You pick up a new language, write some code, and comeback to it in a few months. You will be horrified at what you produced. Next time don’t beat yourself up about it. You are a better developer for recognizing your previous lack of skill. Because of this, you have improved.
Next you have a situation where a developer can become jagged when it comes to documentation. You pickup a nightmare… tons of code and horrible documentation. You read the comments and look at the code and think, “This doesn’t do that!” Even though it seems like a waste of time to read it, you are learning valuable lessons.
Don’t be this guy. Working with this guy is horrible. It’s even worse working after this guy. You and your coworkers come up with new words for the amount of pain this guy created. You want to be famous not infamous as a programmer.
After reading you know some of the deficiencies of the system. You gain valuable insights of some of the potential problems you will encounter. If you find that a developers’ comments are vague or inaccurate, you may want to check that area first when encountering problems.
I have a story to share. I was sitting in a code review recently. Someone asked me a question about a line of code, and I logically analyzed it right then and there. After I confirmed my code was correct, I gave a 30 sec blurb on why it was correct… and then I read the comment right above the line of code. I could have saved myself a minute by reading the comment first. I really blame the other person for not reading the comment first. Just kidding, but seriously if he read the comment it would have saved us both time.
Tags: Comments, Documentation
Posted in Programming | No Comments »