Wannabe Coders
As many of you know, I've been working with CMS for three or more years now. What you may not know is that before that I had over twelve years of experience as a professional programmer working in Unix and (ugh) Windows in C and C++. I primarily worked in the oil and gas industry writing and working on CAEX (Computer Aided Exploration) software. I feel that this puts me in the 'not a noob' category, and possibly in the 'expert' category when it comes to software development. It also gives me the right to complain about some things.
Over the past three years I've had the <cough>opportunity</cough> to work woth some people that needed or wanted tweaks to my various projects (CMSMS Modules), or didn't think that that project worked properly. So they set about modifying their copy of the code, and got something working for them. Many kudos to them.
Also, in the early days I quicky realized that I couldn't maintain and enhance all of my code by myself over the long term. So I actievely sought help from the public. I posted requests for help on the CMS Made Simple forum numerous times. A few people showed interest and I granted them permission to commit changes to the subversion repository. I soon learned that that was a mistake.
It seems most of these people are not programmers. They are people that learned coding as a 'side thing', and somehow got a job doing it. Or, they picked up programming because they had to, not because they wanted to. They are, for lack of a better term 'Wannabes'.
There are a lot of differences between "Real Programmers" and "Wannabes". Real programmers think about the small picture items (data security, data types, casting, number to string conversion, data transfer issues, logic, workflow and readability) and the bigger picture items (code re-use, user-friendliness, stability, longevity, and design issues) simultaneously. Real programmers think in logical steps, and can analyze a problem and break it down into smaller steps, and usually into a relatively clean algorithm. Wannabe's just can't. Real programmers can identify alot of the problems that they will face, or demands that will be required in a project and work them into their solution before they even type a line of code, so that the code will hopefully stand the test of time and multiple users. Wannabe's have tunnel vision and just want to implement the solution they have in mind because it'll work for this single project they have. Additionally, real programmers know that most programming languages are alike, though they each have their own capabilities, purposes, strengths, and weaknesses. As well, they know that programming is programming, and if you understand the basics of structural and object oriented programming you can learn any programming language. Wannabe's by and large just don't understand that concept. To summarize, Real programmers understand that software development is a profession that requires skill and knowledge, just like engineering, accounting or medicine. Wannabe's think that it is easy, and anybody can build a functional, stable, secure, and re-usable application for whatever purpose, in merely a few hours. This isn't true.
But I digress. By granting permission to some of these people to commit code changes to my projects, In most cases, I actually caused myself more headache and time than I would have by doing it myself. Usually, I trusted the work of that other person, and did some of my own changes to the project at the same time. Then subsequently released a new version of the project for public consumption.
It never took long before the emails and instant messages started pouring in (why so few people can use the bug tracking system I don't know, I guess it's an IQ thing). There was a problem with that portion of the project that the other person had implemented (sometimes there were problems with my stuff too, but usually minor in comparison.... I didn't say I was perfect at everything). Because my name was associated with the project, I got the emails saying 'I really need help now!! my site is messed up', etc. and unfortunately that volunteer was always unavailable to handle the cleanup jobs. So I got stuck with many late nights, diagnosing, then fixing the code, walking the users through repairs, and releasing new versions of the software.
It only took me a few (say four or five) instances of this, before I decided to create a new internal policy. That policy would be; Anybody that wanted to contribute code to my projects would have to do their development work against the current SVN version (our source code repository), provide me with a patch, inform me what revision of the software their patch was against, and give me details as to what it does and how it works. I didn't think that this was too much to ask, so I started telling people about this policy.
Aparrently, I was wrong. I soon started getting questions like 'What is SVN?' or 'How do I create a patch?', or my personal favorite: 'Why can't you take my copy of the files and just put it in?'. I'm not going to bother answering these questions here, but hence to say, I just ignored most of these people. A few even got irate because I ignored them. My oppinion was (and still is) If you can't bother to google a few simple things, and answer questions for yourself, then why should I answer them for you. However, I was now back to a situation where I had no help with my development, or maintenance.
A scarce few people did submit patches to the proper place, but never in the proper way. Some of the patches were fair, and though I didn't use their patch, I implemented the same or similar technology. But most of the patches were either too old when they were submitted, were irrelevant, or too confusing to make heads or tails out of. These also got ignored.
I have many different projects, like over 40 or 50, and I'm always working on something or another. Therefore, I don't look at the bug tracking systems for my numerous projects each day, It'd be lucky if I visited them every month. I rely on people submitting sufficient relevant, and correct information so that I can take advantage of it when I get to it. If I can't use their patch easily, and quickly when I do get to it.... then it costs too much time to try to implement it just to look at what they're trying to do.
Soon I started getting more requests to join my projects. Aparrently people can't read the various sticky posts involved with this software to realize the way I wanted to handle this. I ignored those requests because I would get straight back into the 'What is SVN?' and 'How do I create a patch questions'. However, even with ignoring them I kept getting repeated emails. Gach, people never learn.
So now I am at the point where I don't ask for help on my projects, and don't accept offers to help from others. It just takes too much of my time to teach them how I want things, to teach them how to program, and to take responsibility for somebody elses work. I can usually implement whatever they want in a quicker amount of time than teaching them how to use svn, how to create a patch, how to fix their items, looking over their code, and then testing it and documenting it myself.
I guess there are two morals to this story. Firstly, you have to be extremely selective about the people that you let assist you, when you do give them the access, and Secondly, this is one of the drawbacks of working in an open source environment. The help you do get often takes more of your resources than doing it yourself.
I'm not saying I'm a better programmer than everybody else in the world. There are a limited few people that I will grant access to my projects without even questioning (well, they probably have permission to grant themselves access, but if they didn't I'd give it to them). These are people that make their livings doing software development, they know what they are doing, and are at an experience level on par, or even greater than my own. We frequently learn new techniques and methods from each other.
I'm also certain that I'll find more professional web developers out there. People that have the skills to do the job, and to do it well.... or the ability to quickly learn what they don't know. These are people that won't ask 'what is SVN' or 'how do I create a patch' because they'll know those questions are easily answerable on google if they don't have that knowledge already. These will be people that will at least try to follow the guidelines and examples that have been provided in the existing code, and try to duplicate that as much as possible.... and ask intelligent questions if they need to. These people I am excited to hear from.
Wannabe's though, need not apply. Who gets to decide who is a "Wannabe"? I do.
