dustyLogic

Welcome to 2010 !

New Year’s Resolutions are a great idea…in theory. In practice however, we set ourselves to fail fast by trying to be too ambitious and too vague to know where to start. In addition, the methodology which we use to accomplish those goals is not the right one. We try to predict and plan too much up front and this is why most of us fail to keep them. If you’re an IT person then you probably heard about the Watefall model, if not, take few minutes to read this or watch this two minute video and don’t forget to come back to this blog post.

Oh great, you’re back…or you never left. So, imagine that your resolutions are software projects. Because everyone has been doing so for years, we don’t question the New Year’s Resolution methodology and we should because it is very Waterfallish. At the beginning of every January, we try to decide what are and how we will achieve our resolutions. With 12 months ahead of us, we are just setting ourselves up to fail and if even feels like lying, doesn’t it? We can try hard, but we can’t possibly predict what will happen over the course of this year. For that very reason, we need to change our thinking and apply a different methodology. While the resolutions remain the same, we need to define them better and come up with a more flexible approach to meet our goals. Such methodology already exists in the IT world. I bet you that at this point you know where this is going. That’s right, Agile, baby! Now let’s try to apply it to non-software projects, more specifically to your New Year’s Resolutions. The main rules of Agile are not plan too far ahead and to make few smaller steps while re-evaluating the situation after every step.

First thing first. Make yourself a cup of coffee, sit down in your favorite chair with a pen and some paper and write down what you would like to achieve this year. This is an important step, so take your time to think. Be realistic, but at the same time try to push the boundaries a bit. This list will be your so called product backlog. Now reorganize it by order of descending priority, then take the first item from the top and break it down into details. Enumerate your requirements, things you’ll need, people you will have to contact, etc. Order those detailed items by ascending chronological order and put an estimate next to each item. (You can do the same thing to the second item as well, but don’t go too far down the list. Chances are things will change before you even get started working on those item.)  This is an important step. What we did here, is we took a goal and we broke it down into smaller more achievable goals, which will allow us to monitor progress and adapt to the unforeseen if needed.

The objective of your mission is to arrive to the destination while having the flexibility of taking different paths along the way. People and events will get in your way. Don’t try to plan for it, rather expect it to happen at some point. Remain positive. Distractions are not necessarily a bad thing, you can learn from them and make adjustments as you go.

Here is where I hand you the ball and run with it. Even if you haven’t been exposed to Agile methodology before, you might not work out perfectly the first time, but keep trying. Once you get into it, you will definitely appreciate the outcome.

Quick tips to help you in your motivation department:

• Make yourself an inspiration board. It’s a great way to keep yourself motivated to stick to the plan. Gather pictures, quotes, whatever reminds you of your goal and pin them somewhere where you can see them everyday.

• Make public commitments. Let your co-workers, friends and family know about the goals you are trying to achieve. This will give you an additional boost to reach your goals. Last year I wanted to stop my coffee drinking habit. Don’t ask why. ….OK, ask why. Because I realized that too much coffee was making me irritable towards the end of the day. I asked few co-workers to spit in my cup if they see me drinking coffee. After I made it public, my additional  motivation was to not give then the satisfaction to do so. (While I’m a it, thanks Dave Mosher for inspecting my cup on a daily basis, it helped ) Moral of the story is, involve others, everyone needs cheer leaders.
• Join a club to surround yourself with people with similar interests. If you like photography, join your local photography club, or join a forum on the Internet. There are plenty of people out there, to share your ideas with.

Start right here right now. Use the comment box below to share your New Year’s resolutions.

When it comes to career choices, many IT professionals chose to just go with the flow due to so many options out there. We need to choose a programing language, operating system, industry, etc to specialize in. No wonder some just get discouraged while trying to make their next career move. After all it’s our future we’re talking about and we can’t go back in time if we make the wrong choice. Wouldn’t it be nice if someone could just show you how to be in control of your IT career by teaching you where to invest your time to become the most valuable professional in any company? …now there’s a book for that.

I’ve recently read “The Passionate Programmer” by Chad Fowler (@chadfowler). What a great book. So many valuable tips and so entertaining to read. It’s a comforting feeling when you can related to what you’re reading. In his book, Chad writes about how to stay passionate and what actions to take to have a successful career as Software Developer. Following, are some points that I’ve either already put into practice or found interesting. I hope this will be enough to persuade you to read his book:

• Dig deeper. Don’t just use your tools, understand them. If you use ssh everyday to accomplish one specific task, take few minutes to read the ssh man page. See what else ssh has to offer. How about regex? Do you understand how to use it, or you just keep trying until you get what you want out of it? Same goes for your favorite IDE. You will be way more productive if you know your tools.
• Practice, practice, practice. Programming is a creative process. Any creative profession requires long hours of practice. I like photography, so I’ll use that as an example. I often take my camera out just to take some practice shots. I almost never leave home without a camera, but I don’t post photos from every photo I take because a lot of them suck really bad. Which to the viewer could mean that I suck as a photographer (I hope it’s not the case). Musicians, athletes, designers, painters, writers, they all spend time practicing. So why would that be different for a programmer? If the only time you write code is at work, then you are practicing on the job. A great way to practice your programming skills is to work on some personal projects. If you have hard time coming up with an idea for a side project, you can instead do some coding exercises which can be found on sites like CodeKata.
• Finish things. Before you move on to your next task, finish what you’ve started. I personally hate not being able to say “I did it. It’s done.”, after I’ve invested my time into something. Saying “Done” or writing a check mark next to an item on your todo list feels good, doesn’t it?
• Deadlines are your friend. Without having a time window for your task, you will probably spend way more time on it then you should. Sense of urgency can make you more productive.
• Make a hit list. If you acknowledge that you’re procrastinating, then write a hit list. Enumerate tasks, then pick one per day and do it. Make sure the tasks are small enough so you actually have time to do them. After that, that’s it, you got no excuses.
• Be positive. This one made my life so much easier and much more enjoyable, so many times. Stay positive, keep your mind on the present time. That way you will enjoy small victories instead of always focusing on the big goal.
• Stay away from whiners. Also called chronic complainers, and they can stealthy bring you down before you even realize what hit you. Try to stay away from work conversations about promotions, office politics or gossips. Here’s a tips on how to handle chronic complainers.
• Make boring exciting again. From time to time we all have some boring tasks on our plates, so we might as well accept it. Whenever you’re working on a dull task, try to go the extra mile and do a bit more then the minimum required, this should make it at least a lit more interesting as it will make you think.
• Don’t be a yes-man. “Yes” is a positive word, but the ramifications of what you could be committing to by saying it, could potentially be negative. Don’t be afraid to say “No” when your gut tells you so. That way you will avoid unnecessary disappointments.
• Stay cool. Usually, when the feeling of being overwhelmed kicks in when we start to panic. Try to stay calm when fixing a last minute bug. Also remember that everyone makes mistakes, and we all forget. Even if it currently feels like it, chances are that the mistake you just made will never have any impact on your career.
• Own it. Try to be independent and have ownership in your current projects. It will automatically make you more passionate about your work. Propose solutions to your leader or manager. Talk to them about the ideas you have, the additional functionality or performance improvements.
• You are what you explain. I can relate to this one big time. English is my third language. There was a time when my vocabulary was rather limited and I had hard time selling the great ideas I had, during conversations with the director of IT department. I found that if I took the time to write a clear and concise email instead of struggling to explain it to him while standing in the door frame to his office, the chances of him getting excited about it and giving me a “go ahead”, were much grater. Point is, you might have an idea, but if you can’t sell it, then the idea will remain just being an idea. Communication is a skill that can be learned. Personally, I found that a good way to improve communication skills is by writing. Focus on writing clear and concise sentences and eventually you will start talking the same way.
• Speak their language. This is an extension of the above point, but with regards to “translating” what you do, so that non-IT people can understand the benefits of your work. Say, you wrote an app which once a day goes over the records of all accounts and verifies if a credit card is about to expire. So what? How does that benefit the company or department or your client? You can say that instead of the database admin emailing results of a query to the secretary every morning, he will have an extra 30min a day to work on something else. Learn the business language of your industry. Good way to practice is while you work on a task, take a minute to think about how you would explain the business benefits of what you’re working on.
• Share your work. Contribute to an open source project or start a new one. This is a great way to practice your programming skills, learn from other contributors and make new connections. By doing so, you will demonstrate that you’re passionate and got a nice set of skills to potentially lead a project.
• Be a good listener. No matter what’s their title, everyone appreciates a good listener. People like to talk about their achievements and their passions. Appreciate the fact that they want to share something with you, learn from their experiences and feed of their positive vibe.
• Focus on the process. Everyone probably heard this many times before, how maintenance cost is the biggest chunk of total cost of a project, but never tried to do anything about it. Be nice to your code and it will return the favor. Good process will lead to good code. Bad legacy code will enforce bad process. Take the available time to get it done right. Don’t burn time gold-plating, but make sure you’re satisfied with what you’re committing. Before you write a single line of code, run your architectural design by co-workers. There are (hopefully) more brains then just yours in your team, so rely on them and implement changes suggested in code reviews. Oh, and ideally…TDD everything. TDD positively affects the way you write your code, and makes both production code and test code more maintainable.
• Seek feedback. This was always a natural thing for me to do. At any job I had, I was always curious about how am I doing from the manager’s, director’s or president’s point of view. Do they think I’m good at what I do? Do they even notice the effort I’m putting in? Do they wish I was better at something they could benefit from the most? Think of people you would like to get feedback from. Then ask those people to honestly answer few questions about yourself and your performance. Do it in writing, so that they can do it whenever they find time for it, this might also yield to more honest answers.
• Be agile. Agile works well for software projects, but it’s applications are not necessary limited to software. Apply agile approach when planning your career. It’s a fast changing industry, and no one can predict which way it’s going. By being agile with your career, you will be able to better adapt to changes as they come.

Those are just few tips that will help you drive your career as software developer to the destination of your choice. If you do want to be in full control of where you going, then pick up Chad Fowler’s book.