and it’s your first job. Here’s what they didn’t teach you in college.
Nobody knows what they are doing
The theme of this entire web site, and not by accident. Your manager and his manager and his manager and so-on have no-clue what they want or how to get it. They will give you a set of specs that–from all outside appearances–seem set in stone. But no sooner than you deliver a program built to spec than they will argue it wasn’t what they really wanted. They are relying on you to make them see what they want, and the cost is the sacrifice of a lot of code and hard work. “Oh, but I need to change the quantities on the original purchase order” is the kind of remark you’re going to hear long after you have designed–and had them approve–an architecture that makes line-item quantities immutable. Get used to it, because the bottom line is that 50% of your job will be about showing them what they didn’t want, after all.
Agile techniques and Unit Testing were adopted to impress you, not to actually benefit from them
The only reason an IT department has for adopting any of these methodologies is to impress recruits. None of them survive the environment of IT. They will be paid lip-service and given token respect.
Agile and Test Driven Development don’t really deliver, anyway
Sure, your favorite programming blog says they’re critical for quality assurance and maintainable code. I call bullshit. These techniques might work at the companies managed by the guys who write books about Agile techniques and TDD, but they don’t really work anywhere else. The reason is because all of these methodologies are name-branded, shrink-wrapped cribs of the way one particular manager is good at doing his job. Their personalities, instincts and taste mesh well with what they invented for themselves, and now they want you to think it’s the way everybody ought to do it.
It would be more appropriate if they just came out and said “every project manager should be a clone of me,” but that doesn’t sell very many books and conference tickets.
What happens in the real world is that good managers cherry-pick brand, off-brand and homebrew methodologies to factor into their own style. A few ideas from AgileTM here, a few Unit Tests(R) there, a dab of Design Patterns(Pat. Pend) there, mixed up like chocolate chips, nuts and marshmallow into a batch of Rocky Road ice cream.
Then there are the individual developers, whose competencies and skills will look like a scatter-plot. Some will require spoon-feeding and use up all of the QA time, and others will look like they’re doing nothing but surf Reddit all day yet commit more bug-free code in a week than you will produce in a year. To the former, expect them to be all over Unit Testing and Agile like white on rice. To the later, expect them to roll their eyes at the same.
If they don’t use source control and bug tracking, hand in your two weeks notice
If this is your first job then you definitely aren’t being paid enough for that shit.
You will live and die by these two tools, because:
- someone in your department will fuck up, and
- it will be your job to fix it.
Source control gives you the means to undo a major fuck-up, and bug tracking is the tool you will need to juggle all the fuck-ups that will happen concurrently.
The seller of a popular bug tracking system (and the one I use, incidentally) suggests that you should try to inject these into an organization grass-roots style by adopting them yourself, just for yourself, and letting them sell themselves to the rest of the company. But viral marketing isn’t your job, and these two tools are so basic that they are signal factors: if the organization doesn’t already have them then there’s something wrong with the organization. It would be like going to work for a company that doesn’t have bathrooms or a coffee maker; you shouldn’t be thinking about bringing your own, you should be thinking about finding another job.
If you can work uninterrupted, you’re lucky
IT departments are slaves to the whims of business, but remember that this is what pays the bills. If an opportunity comes to sell in a new market and it means handling ANSI X12 EDI over a VAN with a 50-page spec per message type, then it’s probably going to interrupt whatever you were doing at the time. As you’re in the middle of doing that, an existing business partner dumps a new requirement on you to handle two new message types with an October 1st deadline, wrecking that lovely schedule you drew up. Tough beans. Get them done and move-on. Yes, multitasking makes you stupid and the task-switching gobbles up hours of your time. The boss also knows this and is tired of hearing it.
If you were working for a software development firm where the software is the business, then such a muddle would kill the company. But you’re in IT. You are not working at Microsoft. “I said Sizzler, not Google,” and you’re probably working for a company that makes its money by filling tractor-trailers, or putting bums in seats, or shoveling french-fries into fat people, or whatever. If this is so then the efficiency of the company’s programmers will be a low priority.
If you have a dedicated QA staff, you’re lucky
QA managers, testers, unit test developers, etc. are not seen until a department grows to 20 or 30 programmers. If your department is smaller than that and you still have any of those, then you’re lucky. Otherwise your QA will literally be the field itself.
If your users are all in a different building, you’re lucky. If they have been trained to take screenshots and email them to your bug-tracking system, you’re lucky.
But if the company’s attitude is that it’s okay to burst into your cubicle whenever they feel like it, then you need to disabuse them of that notion as fast as you can. Post a sign outside your cubicle that says “SEND EMAIL TO FOGBUGZ” or similar.
The company started by hiring freelancers, and they were morons
Before the company was big enough to have full-time programmers on staff and a real IT department, they hired freelancers and consultants to develop their inventory, payroll, order management system and so-on. All of them were morons. It’s not that they’re stupid people, but the job itself–the job of being a contract programmer–creates an abstract entity who is a moron.
Why? Because it’s impossible to show the value of refactoring and documentation to a CEO.
Remember I said that nobody knows what they want. Now say they’ve hired a consulting firm to design their inventory control and the consultants sit in on dozens of meetings, take notes, nod their heads, tour the building, look at the products, produce endless specs and proposals, then sit down and pound out code. Suddenly a zillion gotchas and change requests wriggle out of the carpet like slugs and maggots. The changes are made, but each one compromises the design in some way. Normally you’d iron-out those wrinkles with a good bout of refactoring, but these consultants are on the clock, and when the first bill arrives the CEO is going to want to know what features he’s just paid for.
Imagine the conversation between the consultant and the CEO. “What’s this line item for?” Techno mumble-jumble in reply. “What do I get for it?” Abstract and immeasurable concepts of goodness. “Take it off! I’m not paying for that!”
So consultants and freelance programmers don’t do much refactoring. Once the contract is over they move on to the next job and forget about what they wrote. When something breaks, they start the clock again, hack and hack and hack until it works, submit their invoice and bugger off.
The person behind the role may be highly intelligent and competent (rare, but it happens), but the role makes them a moron. Sometimes they were morons to begin with, and the role makes them even worse.
Now you’ve inherited all that code and you get to fix it and extend it, and maybe–because you’re salaried–spend time refactoring it.
Make friends by writing good code. Make promotions by listening and sympathizing
Your co-workers will love you if it doesn’t suck to perform maintenance on your code. For this you need to read everything about programming that you can find and think critically about your own code. Imagine a stranger is reading it and write like you want to explain how things work.
To make a promotion, listen and sympathize with your boss’s boss–to the people who are making the feature requests. Nothing scares a non-programmer more than a computer because they don’t understand it and yet their business depends on it. Show them you understand how they feel, and when they ask for something that’s ridiculous do not turn into a passive-aggressive jerk. Maybe they don’t know what they’re asking for, but they do know they have a problem. Try to find out what the problem is and propose an alternative that is actually helpful and would satisfy their need. If you do this then they will love you and never want to get rid of you.
This is not “brown nosing”, this is babysitting.