How do you answer the question, “what do I need to learn to be a good programmer?” I have written posts trying to answer that question, typically focusing on the languages that you should learn or the algorithms and other techniques you need to know. What about the rest of a programmer’s life? This is a less serious look at the life of a programmer. So, what does a programmer really need to know?
1.Caffeine – You need to find your preferred caffeine delivery system. Mine is black coffee, early and often. Others may prefer diet soda throughout the day. There are always the classics as well, Mountain Dew and Jolt.
2.Logic – As a programmer, you deal with logic constantly. Your true mettle will be defined by how you deal with the insanity (real or perceived) of the customer. The customer could be your project manager, the business analyst or the users. For any given project, you can count on someone sounding completely insane.
3.Hours – Expect to be working a lot of them. Programming is one of those jobs that refuses to follow the 9 to 5 path. As you get closer to your deadline, the hours you work will increase quickly. Just hope that you can work from home sometimes. Also, weekends and time off are for management, and you need to be available at all times.
4.Corporate Leash – You may not have any power to make decisions, but that does not mean the company cannot give you a leash. The ability of constant communication is too much for companies to pass on so you will likely get a crackberry, a pager (people still use them), or some other company provided cell phone. No, your leash will not be an iPhone, this is not meant for fun this is business.
5.Blame – As a programmer, you are the low man (or woman) on the totem poll. Just remember that shit rolls downhill, the buck stops with you and if there is a defect it is obviously the programmer’s fault.
6.Sleep – More importantly it is the lack of sleep that you need to be concerned with. As your hours increase, you will find there is less time to sleep. You will have to call into a conference call at 7AM with your offshore team, or support a 5AM deployment on Saturday.
7.Skills – Your skills typically do not matter in the corporate environment. There are plenty of programmers that do not have jobs and could fill your position. Your expertise in the business domain is not important because there are business analysts that are supposed to be the experts in the business. You are replaceable, you are just a part in the corporate machine.
8.Odors – As the hours get longer and management reads something about the productivity of team rooms, the odors start to get worse. We are not talking about someone heating up their lunch. We are talking about the stereotypical, unkempt programmer sitting in a room full of other unkempt programmers. After some time, the room starts to smell like a camel, and it is not pretty.
9.24/7 support – Yes, you will be pulled into support at various times, even for something like a customer service site. The application may not be life threatening or revenue threatening, it is just job threatening. So, your corporate leash will ring at the worst possible moment and you will have to get on a conference call with 10 people who have no idea how to fix the problem but need to be involved from the management perspective and one other person that might be able to help you.
10.Stress – Project failure is never an option. You cannot miss the deadline even though it was not the deadline you proposed. No, you cannot remove features from the application in order to make the deadline either. You need to deliver the entire application by the deadline, or the entire team could be fired. Nothing like a little pressure with your morning coffee.
11.Non technical managers – These people are considered the bane of most programmer’s existence. They need to manage a group of programmers, but they do not understand what they do for a living besides “they write code”. They typically overpromise, underdeliver and treat their programmers like cattle or “resources”.
12.Political battles – This is one of those things that programmers are rarely directly involved in. However, your project and even the whole team could become the casualty of some political war. You have no power to prevent any of it, but you are definitely involved. Keep listening to the rumors so that you have some warning that something bad could happen.
Obviously, these ideas will not happen everywhere and are much more of a worst-case scenario. If you see several of these things at your current employer or even a prospective employer, you may want to run the other way. Given that you already carry a cell phone anyway, don’t worry about the corporate leash, they will just want your current cell phone number.
I've seen this in the past in a few places. Once where I worked with a chef trying to automate his ordering process. He was sure that he could input recipes, make guesses about usage, and then inventory constantly, adjusting his predictions and a well designed inventory system would calculate purchase orders for him. I don't know if his predictions were poor, or if the logic wasn't correct, but he didn't ever seem to have as good a hand on his inventory as he needed. I used that as a basis for a liquor inventory system when I was bartending, but took the "recommendations" from the system and adjusted them based on intuition. That seemed to work out much better.
