REVERT TO CONSOLE

I haven’t posted in about 8 years or something like that. Besides being lazy and uninspired, I really haven’t learned anything new or exciting in the past 2 years. I have nothing to share that would be beneficial to all of you.

However, some of you may benefit from what I have learned NOT to do over the past 2 years. I have learned plenty of “DO NOT’s” over time, but the last 2 years, especially the last 7 months has been the grand festival of “DO NOT’s”.

1. Do not let an “expert” with unsubstantiated credentials tell you how to do your job. Better yet, avoid working with an “expert” whenever possible. These “experts” like to talk down to you and blame you for everything that goes wrong. They never admit to contributing to the problem. They also insist that his/her approach is the best, even if God (or other supreme being) were to tell him/her that it’s wrong. An “expert” will try to control you and the project at any cost. An “expert” will no doubt run the project into the ground or into a persistent vegetative state. If you find yourself working with an “expert”, take precautionary measures and have an escape plan.

2. Do not let users perform their daily job duties with an application that is not fully developed or production ready, especially if it’s not even beta ready. Don’t let users rely on an application that is undergoing constant development and hasn’t even been tested. Users will no doubt work their dirty little hands into your project and get you to make changes at the drop of the hat, because their jobs depend on it! Don’t expect a manager to help you out in this situation. If things have reached this point, no manager can simply stop this evil cycle. Now you have a situation where there is a direct impact on the success of the company. Because the application is not even fully developed or tested, there will already be bugs galore. The users relying on your application will find even more bugs that stop them in their tracks. Everything becomes a critical defect. Trust me, if you get into this situation, you will want to die, because you are already dying a slow and painful death.

3. Do not develop in an environment that has absolutely no process. You don’t need to be process gung-ho and implementing CMMi level 5, but you should have some basic sort of SDLC process in place. A development group without processes usually fails to have standards as well. The “as long as it works” mantra comes into play.

In this situation, you will end up with horrible spaghetti code where developers are doing whatever the hell they want. You will have no ability to monitor code quality. You might end up with code that looks like it was written by someone who is half-way through their first programming course (CSCI 101). Hey, they just learned how to write arrays, and want to show off that skill, as much as they can. Your “code review” will take place when you have to take over their project, at which point you’ll ask yourself, “What kind of dumbass could possibly write this &*@%!@#!!!????” Of course by then the bad code has permeated its way into the deep inner bowels of the application, like a virus, making it nearly impossible to correct without throwing it all away and rewriting from scratch. It’s sort of like when Windows gets jacked-up every year or so and your best solution is to “format C:” and start over.

In addition, the extent of your QA will probably be limited to the success of your compiler and a few keystrokes and mouse clicks.

no process = bad applications (hopefully most of you know that already)

4. Do not get involved in a project where a phone call, simple face-to-face conversation, or a note on your desk from a user is all that is required for you to make a change. This is closely related to #3, but it’s worth emphasizing a bit. You need to have a way to document change requests and prioritize those requests, even if it a simple excel spreadsheet on a shared network drive. This is just one more way that you can be trampled to death by users. Not to mention the fact that you are developer and you have no business answering the phone or communicating with a user directly. That’s what BA’s are for. You lack the people skills required to interact directly with users and you should be damn proud of that. Additionally, there is great satisfaction to be had when you can make users punch themselves in the face. By that I mean something like this:

User: “What is this thing doing? That’s not the way it’s suppose to work!”
You: “Yes it is.”
User: “No, it’s not.”
You: “Yes it is, you requested it, see?”
User: “Ah DAMMIT!” (punches self in face)

5. Do not succumb to the “at least we still have jobs” outlook on your career. Yes, the economy sucks right now and layoffs suck. I hate seeing people bringing in boxes to pack up their stuff, especially when they have done a great job at the company for 10, 15, 20 years or more. That’s like saying, “Thanks for all your great years of service, now be a team player and piss off, yeah?” There are other things employers will do to cut costs though. They might squash benefits, slash salaries, and eliminate incentives. This is especially likely to happen if the executives made stupid decisions (likely in any case) that ran the company into the ground. You don’t have to pay for their mistakes. This industry is still viable. You can find good opportunities elsewhere. Don’t be afraid to explore and don’t feel bad for leaving. If you really believe in the company and feel that you want to help “get through this tough time together”, then stay and try to maintain a positive attitude. But remember, you don’t owe the company anything.

That’s it for now. Maybe you learned something, maybe not. You may have only learned that I am just an ass, if you didn’t know that already. Either way, I hope it wasn’t a boring read. I’d better get back to “work.”