So, you've been through Dilbert hell. But now you've made it, right? You've got more character and more experience. You escaped with your will intact, and no battle scars. Hah, right. You've got plenty of ingrained bad habits from your years in hell, and you'd better start figuring out what they are and cutting them out of your life.
Not that developing bad habits was the result of stupidity on your part. Your survival skills served you well when they were needed, and made perfect sense at the time, but you're out of there now, and must adapt to better circumstances. Everyone comes back from war a little bit shell-shocked, the trick is to pull yourself back together and move on.
Below are five of the worst bad habits of thoroughly downtrodden programmers, what causes them, and how to get over them. If too many of the causes apply to you right now, then I hate to say it, but you're still in hell. Get out. Get out now.
1. Pre-engineering
An old boss of mine said that every line of code deleted is time wasted. As a purely defensive measure, I did what programmers since the beginning of time have done when there will never be a chance to modify something later - make the first draft do everything you can possibly think of, and then some. Sure, the code won't work as well as if you'd written it after first implementing a smaller version to figure out how it should really work, and most of the fancy functionality will be completely extraneous, but there really is no other option here. If you don't put in the functionality now, you're going to have to hack it in by some awful kludge later, thus lighting the kindling which will burn down the project.
Now that you don't have to worry about a management old code fetish, you can stop wasting time developing a hydraulic drill when all you need is a hammer and chisel. I know you like the aesthetics of beautiful completely general interfaces which can remain unchanged for the next ten years, but chances are you'll never need a hydraulic drill, and if it turns out you really do need one, you'll build it later, and it will be a better one than the one you'd write now, because you'll actually understand hammers then.
By the way, you can't write a new interface which won't be changed for ten years. Trust me on this one. You can't.
2. Glop Refactoring
You've got a lake which you want to use as a source of hydroelectric power. The normal way to do this would be to construct a dam, then dig a trench leading from the lake to the dam to the ocean, and start collecting power. Only you can't do that. There will be interminable political arguments about where the trench should be, how much water it should let through, what the design of the dam will be, and just about anything else which can be argued over. There is no way a dam will ever get constructed.
But you have learned a way. Without getting anyone's permission, as a single unilateral act, you dig a trench from the lake to the ocean and just let water start coursing through. Sure, it's going to drown a nearby town if it keeps up, but that town is certain to make damn well sure a dam is built to keep itself from going underwater, and then you'll have a dam.
I hate to break it to you, but you're going to have to stop doing that. Yes, I know chaos is fun. Yes, I know it's very effective to just change an interface resulting in a build broken in 500 places and wait for everyone else to fix their code to comply with yours, but really, you can do things in a much more orderly way now, and bringing the project to a state of total anarchy is uncalled for, however much fun it may be.
3. Not Sleeping
You can't steal time from your sleep schedule, you can only borrow it. Eventually you have to pay it back. With interest. Yes, you *have* to get XYZ done by yesterday, or... or... Well, *something* really bad will happen. Take a minute to consider most deadlines you've had. Is the deliverable going to ship the day after the deadline? Of course not, this is just the regular monthly deliverable. By the time the shipping deliverable rolls around you'll be paying back your sleep debt, with interest.
I'm going to let you in on a little secret. The exact form and date of the final deliverable doesn't matter all that much. Market research always says it would be best to be five years ahead of everyone else in terms of functionality, and able to ship tomorrow. You don't even need surveys to figure that out. The only way to make a useful schedule is with a healthy attention to reality. If there won't be time to include a feature, trim it, and if the bare minimum functionality can't be done in time, let the deliverable date slip.
In the end, all that matters is the code you write, not the hours you put in. If you find yourself falling asleep in your chair, forcing yourself to type to avoid nodding off, go home and get some sleep. You'll more than make up for the lost time the next day.
4. Doing all the code yourself
So you're a genius, and can write anything better than anyone. You've single-handedly held together projects where noone knew what was going on. You've pulled all-nighters to fix someone else's architectural error which had stopped progress completely. You're so cool, you don't even feel embarrassed bragging about it.
Unfortunately, you're still only one person, and like it or not can only accomplish one man-hour per hour. Your coworkers, while imperfect, aren't the idiots you used to work with, and can do not only an adequate job, but a downright good one. Delegate work to other people. Go without checking up on what they're doing for days at a time - paying even loose attention to what problems are turning up will cause you to waste time thinking of solutions, stealing time from your own tasks. Trust me, the project will be better off if everyone has a chance to contribute. You might even be impressed at how cleverly other people can do things too.
5. Not giving information to management
"How's the project going?"
"Fine."
"Any difficulties?"
"It's going fine."
Bad managers wouldn't be nearly so harmful if they only knew they were bad. The results of their ignorance are mandated solutions which not only make the original problem worse, but cause new ones as well. In the hands of an idiot, useful information about progress turns into the steel which forms the support beams of the Artifice Of Things I Can Claim To Have Done. Political animals need such artifices, it's what the other political animals look for. All the kids are doing it.
If you never tell a bad manager how anything's going, you'll never get a stupid mandated solution, and the project will be that much better off. You've probably even got some standard tasks for management to do to make themselves feel useful, like hold focus groups. The information gleaned from focus groups is usually about as accurate as asking accountants how pushing the plus button makes them feel, but you won't use the information anyway, so it doesn't matter, and management won't notice that you didn't, because they'll be too busy holding another focus group you asked for.
You don't work for those idiots any more. Your current boss will not only not use information against you, but use it to make the world a better place. If the final deliverable is going to slip a bit, management will go tell marketing that the product launch will be a bit later. Marketing might even be having their own problems and appreciate the extra time. Companies run smoothest when management has all the information which might be relevant to corporate decision making.
I've noticed that a lot of programmers complain about clueless managers when the fault lies partially with the programmers or team leaders themselves. Not keeping the managers up to date on progress and problems makes them feel edgy and powerless, a situation that blows up when major problems and deadline slippage occurs.
Managers need to know when things are going wrong as soon as possible - one of the reasons is that they can negotiate with their own bosses or clients to give your team more leeway in deadlines or features. Or they can prioritize tasks and let you know which ones are more important to get working and complete first. This has the effect of taking some pressure off you.
Keep in mind that if you think it is hard to tell the boss about stuff not going well _now_, imagine what it will be like when it is too late.
In relation to sleeplessness - I cannot stress more how important it is to keep a routine, I spent several years on a 30-hour cycle, sleeping whenever I was too tired to code any more. In the best case you will be left neglecting your social life and having constant nagging thoughts about things that you want to do outside work/hacking that never seem to get done. In the worst case it left me with health problems and very bad sleeping habits, stuff that I am getting a hold on only now.
Don't fall into the trap. When you're getting tense and moody, go outside, have a long walk, play the guitar, ring a friend. When you get back to your console you'll feel better and more focused.
And remember to take stretching breaks every half hour! :) Good for your wrists, good for your mental health.
The difference between a "Dilbert" job and a satisfying one can be project management. I have no idea how people learn or teach this skill; maybe that's why so many people identify with "Dilbert."
A couple of behaviors to look for in a good project manager anyway:
1. Keep project status reports on the web where everyone involved in the project can see what's going on. Keep them up to date. (Keep everyone's current contact info on the site too; chances are that someone's email address or phone number will change during the project.)
2. Protect hackers from clients -- train clients to check the project web site or talk to you rather than asking implementors about the project status.
3. Make a new version of the spec, and consider revising the schedule, if the requirements change. Don't let clients "interpret the spec" to mean more features.
4. In exchange for all your work on behalf of the implementors, insist that they give you the information you need to do your job, and explain it to you if you don't get it. Don't let lazy hackers bamboozle you.
The classic image of project management works is a bunch of lazy programmers sitting around trying to get as little done as possible, with a heroic project manager standing over them with a bullwhip and a stopwatch forcing them to do work.
This view is, of course, just plain wrong. Most of the skill in project management is in turning what is generally a hostile process into a cooperative one. There are many aspects of this, much too many for me to even give a good summary here, so I'll give pointers to a few books -
Peopleware - Most projects fail not for any technical reasons but because the employees are mistreated and demoralized. Much of this book will be preaching to the choir for advogato readers, but there's still much useful wisdom here, such as the study of cubicles (they're atrocious.)
Non-Manipulative Selling - It may seem strange to recommend a book on sales for project management, but it's in the relationship between engineering and the customer where most software projects really hit trouble. This book is where I learned how to keep such discussions from becoming bitter arguments. It's also great for learning to evaluate salespeople - It turns out they're a bunch of slimeballs not because of anything inherent to sales, but because there's widespread incompetence in the field.
Extreme Programming Explained - The most important part of this book is not any of the technical advice (which is generally excellent) but the section on planning. Software simply cannot be planned in the nice, scheduled way building construction is. This book is the only serious work I know which accepts that now exceedingly obvious fact and builds on top of it, rather than trying to come up with ever more elaborate and time-consuming exercises to try and force the round peg of software development into the square hole of rigid schedules.
That's a much more interesting article than the one about turds.
dmarti writes "Protect hackers from clients -- train clients to check the project web site or talk to you rather than asking implementors about the project status"
If you think that's the only reason a client will want to talk to the coders, I have a cast-iron-project-specification-which-will-never-change to sell you.
For every occasion that I've appreciated someone keeping the client out of my hair there's been another where I've actually wanted to talk to the end-user and find out what they're asking for (after all, it might just possibly be easy ...). Having all this stuff filtered through (and if you're lucky, interpreted by) a non-technical "single point of contact" as often as not ends up with everybody concerned getting pissed off.
As for status reports, there will be no need for "training" as the project manager is already keeping the client well-informed and abreast of developments - they don't need to go behind his back to find out what's happening. Ho ho.
I disagree wholeheartedly with dmarti. As a not-too-surprising concept, the best way to find out what a customer needs is to talk to them. Most companies I've worked with have placed a solid wall between customers and the people working on solutions for them, ensuring that they will always be out of touch with what the customer is really needing, and will inevitably end up working on projects that are of no value to them.
May I suggest some light reading which might illustrate my point better?
It's a matter of degree. I've lived in environments where I was desperate for customer input, and I've lived with customers who only called to make your next three weeks a living hell (Fred-o-Grams, anyone?).
A good project manager is one who can understand the needs of his team, fight for them when they need it, and task them when it is required. When it comes to customer contact, the traffic should usually be initiated by the coder. The project manager should filter customer initiated contact, because while it might be important usage patterns, it could also be impossible feature requests and useless heckling.
I lived in an environment of really, really bad project management for a while. The project managers had no care about the people in the project, just that the dates on their Micro$quash Project sheets were filled in correctly. It was strictly a political exercise that allowed them to claim they were getting work done. I don't live in that environment anymore, and I'm very happy for it. I have since experienced and heard of project management that is run well. I hope to see more of that.
In the end, project management itself is necessary for large projects. A dedicated project manager means that a coder doesn't have to take it on, and is free to actually code. The trick is finding a good one.
I generally get nervous when people start using Microsoft Project to "run" or "manage" projects: it's a reporting tool, nothing more. Use it to tell you how short of people you are, use it to show your own manager why you can't finish, but don't use it to make decisions on who to assign to which task.
Management has several rôles; few if any managers can do all of them, but taht doesn't mean they don't matter.
In some environments, team leaders protect the team members against interference from other departments or managers. That can be good, or it can be bad. Sometimes a good middle manager can save a project from being stopped, or maybe can explain to upper management why some entirely different vision of the project would be better.
If you're doing consulting or bespoke contractring work, frequent contact with the customer is generally very good. You don't want to be protected from speaking to the people you've got to satisfy. But you also want to assign a single point of contact, one person at the client and one in the programming slave-galley, so that you don't lose lots of time with five people talking to the customer all at once. If that contact fails, or if more people are needed, bring them in as needed, but it's a judgement call.
The managers should also be helping the staff to feel valued and motivated. Programming has a strong creative element, and that must be burtured and rewarded. In non-computer-programming companies it's often also important to provide a creative space where the programmers can work without having to follow rules set down for spot welders about not wearing jeans, keeping their shoes on, not eating at their desks, not being naked at work, and not having sex in their cubicles. Well, OK, find your own limits and rules. A common one is to do with office hours: some people are more creative in the afternoon and evening. It might be helping to providea place where people feel they can have fun too, letting them surf the net unmonitored or play video games after hours, or choosing a random team member to horse-whip each week, anything they enjoy.
For my part I've found it very demanding, mnaging programmers. People have also said that I'm not very easy to manage, probably because I'm unconventional and would rather get things done than fill in a form.
In some set-ups, the managers are also responsible for comparing the software against the specifications, and for revising the specs as the software and the customers' perceptions of their needs all change.
I don't believe in the 30-foot-high-fence-with-armed-guard approach.
If you're a manager going off to meet a client to help draft a spec, see if you can take a programmer with you who will be involved in the work. Take programmers to trade shows, have them do a small amount of booth duty and then let them wander round the show, and you'll get some innovative solutions to problems as they are exposed to more ideas. They'll feel good at seeing happy customers too (if you have any).
Finally, the manager is there to intercede and to help people get along: it's a government rôle. Society is a group of people who accept certain constraints in order to be able to live together well. If someone in your team isn't working well, if you are having a hard time solving a problem, if you are finding it hard to get on with someone else in your team, if you don't understand or don't agree with a partiocular decision, you should be able to go to your manager and discuss it, and if necessary your manager should pull in everyone involved and deal with it then and there.
Programmers who don't want to do anything are rare in my experience; programmers should be lazy, in that they want the computer to do the work for them.
I have to say that I agree with dmarti: part of what a good software manager does is to protect hackers from the clients. This doesn't mean hermetically sealing them in their cubicles; this means that it's the manager's job to give the hackers space to create the client's solution.
Of course, the reverse is true: there are many many times where the hackers need direct contact with the client. But these interactions are most productive when they are about requirements, solutions, and technical issues. They are not productive when they degenerate into the political; it is this that the good manager will protect her team from.
I would like to add a few major gripes from my point of view as a coder and hardware hacker. Most managers/teamleaders that I have worked with do these things, and they REALLY piss me off! So managers, do more than just take this down as notes. Read it three times or more until it sinks in, ok?
1: If your any kind of manager, and your programmer needs something (NDA style API specs for example) either go and get it or delegate someone to get it for them. All to many times I have been promised information on this and that and never any effort was put into getting that information. Keep your promises or don't make them.
2: Make sane deadlines. Don't expect something to go untested out the door. Investors tend to frown on demos that crash, and end users end up calling the coders bad names. I personally think that the quality of my code directly reflects my abilities. Patence my money grubbing whores! Let's do things right and even I can benifit!
3: Monitor progress yourself! Personally, I don't like filling in silly reports, or spending alot of time doing anything that even resembles paperwork. I don't even like to write documentation that newbies can understand. When you think about, how easy can a manager can do this themself? All a manager really has to do is grep for all the comments in the source code. Most code comments tell a story, such as problems, etc. Atleast, MY code does, and I would bet that the majority of coders do this too. If there seems to be any major problems, ask what's up. Seems fairly a straight forward approach to me, and the coder codes, and does not waste time filling out sensless reports and learning some interface to a stupid report generation program that he or she could really give a crap about.
4: Don't delegate techincal jobs to nontech people, and if your nontechnical, PLEASE don't try and do it yourself. Oh so many times have I watched complete idiots who know ZERO about hardware run out and pick up boards that will absoultly never fit the demand of the project, not even stuff that will fit for a demo. It's not only a waste of the company's money, but a waste of time for everyone involved. Ask the coder who is writing the device driver what he thinks will work, they know this stuff. Why else they wouldn't be writing a device driver? Perhaps you should let them seek out the proper hardware.
5: All to many times does the project change. I'm not talking the end goal, but the part the coder is working on. Interruption of a project to go off and work on something completely unrelated is a VERY BAD THING to do! Knock that $h!t off ok? It's extremely counter productive, and the coder feels like they are being thrashed about like a large program in a RAM starved machine. Tell/hire someone else to do it, because this part is _MY_ baby until _I_ am done with it. Basically, back off and let my creativity flow, _PLEASE_!
I do have other gripes with self-proclaimed and so-called management wannabe's but these are the ones that majorly piss me off. I won't even go into how management lies alot to the coders or keeps them in the dark to the point where it hampers the progress, as that could possibly become an entirely different article and I would probably slip and start naming companies and people. I really rather not go there. I suppose I am to nice of a guy to do that. You know who you are anyhow.
So how about you? Got any gripes?
AJK
While on the subject of good management, I feel it apropos to point out that Benjy Feen (author of MonkeyBagel) has written a short but insightful piece about the difficulties of good management (though he's dealing with managing sysadmins, I think the advice transfers well) and why it is so essential that we try hard to get it right. You can grab it here:
I posted a reply to this I think you might enjoy, but some kind of off-by-one error in the article number appended my comment to Why We Should All Test the New Linux Kernel instead. If you want to read it, go there and scroll down to the 4th comment, "Bjarne Stroustrup on the Humanity of Programming".
This has happened to me before. How do I tell the maintainers of Advogato about this?
Man, I'd have dropped these people like a hot potato- you've got a lot more patience that I.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank