• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
The Standalone Programmer: Best Project Management Tips
Introduction
I have read many books on successful projects, project management, development life cycles, qualitycode, etc. One of the pit falls I have discovered with many (if not all) of these books is that theymostly focus on team development. Most stress the need for quality assurance people, at least 2developers, project leads, etc. Unfortunately, this is not always realistic and can seem overwhelmingwhen a single developer is faced with large projects. I have been the only programmer at myemployer for about 3 years now. I am fortunate that my boss is an ex-programmer and has a goodeye for architectural details and big pictures. However, all of the architecture, design, development,debugging, testing and refining work falls to me. I do not have a staff to assist with thedevelopment, QA or testing so for just about every aspect of development my company needs, I'mon my own. Many of the projects I have worked on have been very small and accomplished in just acouple of weeks, but others have spanned 3 years and are continuing. To combat this problem I have been endeavoring to train myself on the best practices and solutions to my problem. Many of theconcepts outlined in the various books can be easily applied to one-man-shows, but others cannot.As a result I have searched for alternate solutions to the various problems I have encountered. Mostif not all of the solutions I have come up with are not original and many of you will already knowwhat I know and much more. I decided to write this article in the hopes that it would help someother developers AND that I could obtain feedback from the CP audience on best practices andtechniques for success. I have broken this article into 2 primary sections. The first deals with myobservations and techniques regarding the non-technical aspects of my job. The second deals withthe technical aspects.
Disclaimer 
Before I begin I just want to say that I am no expert and the contents of this article are myobservations and techniques. You may have better techniques or think that mine are terrible. Iwould love to hear from you. I am interested in improving my abilities and skills and I am notegotistical about my views in this regard. So, if you have a comment, positive or negative, pleaseleave me feedback and explain what you think. In fact, if there seems to be consensus on better ways of doing things then I will probably update this article to include those better techniques.
Preview 
As stated before, I have divided this article into two sections. Before I get into the details I am goingto list the various bullet points here.
NON TECHNICAL
1Set personal goals2
Read, Read, Read
3Come out of the closet 4Meetings are not all bad, just mostly bad 5After hours is off limits6Set reasonable expectations7I'm not a programmer, I'm an architect 
 
TECHNICAL
1Plan, then code2
The right tool for the right job
3Fix bugs early4Develop good coding habits5Know thy enemy6Documentation is your friend 
7Form over function1
 
Non-Technical 
Set Personal Goals
This has been the single most important activity I have undertaken. Setting and then workingtowards my goals has helped me to find direction in my career as well as keeping me focused on the job. Some of my goals are short term and can be achieved in under a month. Others are more longterm and may require more than a year to achieve. I write these goals in a word document andreview them often. Some of the goals I have set for myself are listed below.1.Read at least 1 programming book each month.2.Read at least 1 non programming books each month.3.Learn at least 1 new language this year.4.Take the final test for my MCSD this year.5.Develop and release at least one shareware application this year.6.Write at least 1 article for CP every 3 months.7.Write up the documentation framework for the XXX framework this month.8.Increase my salary 25% within 2 years.My goals are intended to improve my skills as a programmer and developer, but also to improve myviability when seeking a new job. One of the things I have learned about goals is that any real goalmust have a deadline attached to it. You will notice that each of the goals I listed is singular innature and has a set deadline. The deadline is very important because it guides me and helps memanage my time better. By knowing what I want to achieve and having a deadline for thatachievement I am not setting myself up for failure, I am creating a healthy environment in which to build my career.I don't always meet my goals but when I don't I review them to understand why I did not meet them.Sometimes the reasons are beyond my control and I simply readjust the goal to a more reasonableone. Sometimes, however, the reason I did not meet my goal is because it was too ambitious to bemet. If this is the case I want to fully understand what part of the goal is too ambitious. If thedeadline is the problem, then I simply adjust the deadline. If the problem is that the goal itself wasover-my-head then I create new goals which are the steps I need to take to achieve the original goal.Setting goals for myself has not been easy. I have had to force myself to follow my own goals and Ioften find that I drift from the goals for all kinds of reasons. The most important aspect of goals isnot to set myself up for failure. My goals are often challenging to achieve and require that I sacrificesome other aspect of my life. Limiting my other sacrifices to things I can live without is the key tosuccess.
Read, Read, Read
Most successful software developers I have spoken with here on CP and elsewhere would agree withthis statement I think. Keeping up-to-date and learning new languages, etc is extremely important tolong term success. No matter how good I am there is always someone better. This is OK, especiallywhen those who are better than me write books or articles and I can learn from them.In my early years of programming I did not read many books at all. I tried to spend all of my timewriting code and learning by reading other peoples code. This worked up to a point, but failedmiserably as soon as I was faced with a problem that was beyond anything I had already written or seen written. It took me a while to learn that reading was just as important as the coding itself.My next mistake was to focus only on reading programming/coding books. This was better than notreading at all but still didn't help me solve some of the more complicated problems. What wasneeded was for me to begin reading more general technical books. Books on design patterns, fuzzylogic, AI, etc. Most of these books don't contain much (if any) source code at all. What these booksdid was to broaden my exposure and help me to find better solutions to problems.2
 
Reading coding as well as more broad technical books has made quite a difference in my abilities.However, even this broader scope still leaves some gaps in my abilities. I have learned that evenmore mundane topics such as User interface design, usability, databases, etc are necessary as well.With a complete range of technical books and articles I have been able to broaden my horizons andgreatly increase my ability as well as my ability to get a job. Currently I read books on projectmanagement, team growing, design patterns, C++, AI, UI design, usability, writing solid code, andthe list goes on.One other area of reading that I have not begun to dive into yet is non-technical, non-programming books. Books on sales and marketing, branding, etc. I see the potential for these books to help mein marketing and selling my shareware products as well as helping me to understand the needs andrequirements of the sales and marketing people I must work with.Reading does not have to be books. It can be magazine articles, MSDN, CP or any other source of knowledge you can find. At my previous employer I had a budget for books and freely purchased books as often as I liked. My current employer does not have such a budget so my book buying has been greatly limited. I have been learning to leverage the free and less expensive resources availablefrom the internet and magazines.
Come out of the Closet
When I first began my career as a programmer I enjoyed the endless hours of coding and wouldoften not come out of my office except for lunch and bathroom breaks. For me, this was a badhabit. It lead to various problems, not the least of which was a disconnect with the rest of the office. Now you may be thinking "what does this have to do with programming?". Well, for me it had a lotto do with programming. First, it made me appear reclusive and stand-offish (which was basicallytrue.) Second, it prevented me from stepping back from the computer and trying to grasp the problem out of the context of code. The first issue made it more difficult for end-users and my peersto discuss issues with me. Also, it gave the impression to my peers and end-users that I though of myself as an "elite". This was not true, but lead to many interpersonal problems which had a directimpact on the quality of the applications and modules I delivered. The second issue related to thiswas just as severe. Failing to step away from the computer and think of the problem instead of thesolution is dangerous. Often by stepping away from the computer and working on the problem a better solution can be achieved.The typical business office is filled with people of various skills and with various job descriptions.Even if the programs you are developing are not targeting the type of people in your office, a lot can be learned by observing how other people interact with their computers, andif you are targeting your office staff this issue is even more important. Ultimately, most softwaredeveloped is not targeted at just the one who wrote it. By staying alert and interacting with end-users you can gain valuable insight into how software is used by the "Rest of the world".If you work out of your house or in an office by yourself, this still applies. It just requires a littlemore travel on your part.
Meetings are not all bad, just mostly bad
I dread meetings. I don't like attending them and I don't like having to be involved when I have toattend. However, my approach to meetings has changed quite a bit in the past few years. I used toattend them with the intention of not saying a word and slipping out of them at the earliest possiblemoment. I have learned that not all meetings are bad. Some are even useful. The key question thatI ask myself when attending a meeting is "What can I gain from this meeting to improve myskills?".That is the only question I need to ask because if I improve my skills it will have a positive impacton the project I am working on as well. Now you may be wondering what kind of skills you canimprove from a meeting.3
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...