Good Coding Skills Are Not Enough
But I just wanna be a programmer! Why do I need all of these non-coding skills? Cant I just sit in my cubicle and concentrate on programming?
Sure you can. In fact, the overwhelming majority of programmers worldwide do just that. Of course, the overwhelming majority of programmers worldwide also have an extremely common set of complaints about their jobs. The simple reality of the matter is that your job is probably not anywhere near as good as it could be, and neither is your software. Weve already identified a large number of culprits that appear to be responsible for the problems we encounter, but, when it all comes down to the bottom line, its your fault. Ouch. Can I say that? Well, perhaps, if only because Im safe for the moment from the sting of a whiteboard eraser.
How can all of the shortcomings in your software development shop--so many of which are typically caused by managerial decisions that exhibit about as much common sense as a lima bean--be your fault? Simple. If you sit on your hands and do nothing, then youre part of the problem when you could be part of the solution. Wait, that sounded a bit like one of those trendy catch phrases. Maybe Ive been hanging out in Corporate America too long.
If Im suggesting that you take a more active role in dealing with the issues you face as developers, I suppose its not that different from asking you to storm a machine gun nest. Of course, all those years of dealing with maintenance programmers has undoubtedly prepared you better for such a task. Still, to be practical about it, anyone taking risks should have a reason for doing so. In other words, whats in it for you?
Whats in It for Me?
Probably one of the biggest hassles in any fulltime programmers career is sacrificing your life to countless hours of unproductive--and very often unpaid-- overtime. Its bad enough that youre given a situation where you cant get the job done working forty hours a week. The way most businesses are run, the end result may well be yet another release disaster even if you put in eighty hours a week. Thats not exactly a rewarding experience, particularly if you have to give up your life for it. When we fire up the editor, what were reaching for is the next killer app. We are artists as much as anything else. To put blood, sweat, and tears into a project (okay, maybe not the former if you dont have to interact with the maintenance programmer) only to have management ship it in a half-baked state can be downright infuriating, and thats with a full night of sleep. I have no desire to work day and night as it is. Doing so on a project destined for failure adds insult to injury.
Along those lines, one of the things that are in it for you as an artist is the ability to ship a betterquality product. Whether your name is in the About box or not, your signature is on every piece of software you ship. We all tend to take a great deal of pride in our accomplishments, so who wants to be associated with anything other than a spectacular success? Do I work for money or for ego? Both. (In that order, for the record, but definitely both.) If you want to be involved in projects that make you proud, you have to do your part to help them survive in the wild.
Actually, Ive always had a pretty bad attitude towards companies that take advantage of programmers and expect them to dedicate their every waking minute to the job. Maybe its because Ive been a musician all my life and have seen how nightclubs and other aspects of the music industry tend to pay almost nothing. They get away with this because they know we love music so much that wed probably play for free and are usually happy to take whatever we can get. A low-paying gig on the weekend is more fun than no gig. Because of this, bar gigs pay today almost exactly what they paid twenty years ago. Really. Its an unfair and predatory practice but is so common that its become the accepted norm. If you push for more equitable pay, youre simply told that theyre not doing anything different than every other venue in town. Thats typically true, but it doesnt make it right.
Many software development companies employ this exact approach in dealing with programmers, and for the exact same reasons. We got into this business because we were passionate about programming. We tend to do it at home in the evenings and on weekends just for fun. With the same predatory attitude, these sweatshops take advantage of our love for development and make continual overtime an accepted norm.
I have a friend who is a programmer working in such an environment. In fairness, I must say that he was told up front in the interview that, due to the stock options giving the employees a sense of ownership in the company, they hired only those people who were willing to dedicate above-average hours to the job. Nonetheless, hes been killing himself the past few weeks working late hours. I made some of the usual jokes with him regarding end-of-the-project crunch time and asked when the release date was. His answer floored me, even though its nothing new. He said there was no deadline; it was simply a corporate culture. If you werent putting in all the extra hours, you just werent working hard enough.
When theres an honest-to-goodness crisis, you can count on me each time, every time. Ill be the guy with the sleeping bag next to my desk. Obviously, my friend sees it as worthwhile, and hes a pretty sharp guy for whom I have a lot of respect. However, this sort of open-ended abuse of programmers constitutes a gig that I wouldnt touch with a ten-foot pole.
Consequently, for years now I have employed a somewhat unorthodox tactic for avoiding sweatshops. I live in a major city, and there always seems to be plenty of work out there for my particular skill set. Consequently, when I go out for interviews, I do so with the desire of landing a job that I really want. By the time I actually get down to the normal face-to-face interaction with the company, weve already done a lot of the dance and its a foregone conclusion that Im potentially a good fit. They wouldnt bother to interview me otherwise. So, we go through all the normal motions where we each do our best to convince the other that were something that life is just not complete without.
When its just about all said and done and things look good, I ask about the kind of hours that theyre working on average and if overtime is a frequent flyer in their world. Ive found that a good many managers dont want to be honest with you about this because they figure it would be harder to get people to sign on. Theyre certainly correct. So, just to make sure that Im not being suckered into a sweatshop environment, after theyve assured me that they dont work much overtime I happily agree with the philosophy, telling them that I have enough going on in my life that I like to get my job done in forty hours a week. I then tell them that as a seasoned developer its my personal conviction that, if youre unwilling to pull the occasional all-nighter at crunch time, you should get out of the business. However, I feel that any company that has a crisis every week and that requires constant overtime is a company with extremely stupid management, and I have no desire to work for such morons.
The truth is that, if the conversation has indicated to me that Im not the only programmer in the room who curses like a sailor, I use much stronger language than "extremely stupid" because I really want to make a point. Having done so, one of two things usually results. Either they were telling me the truth in the first place about little overtime, in which case weve agreed on yet another topic, or theyre lying to me. If the latter, I have just terminally insulted them and there is no way in heaven or earth that they will hire me. Which is exactly my intent. When times are tough, you take whatever gig you have to in order to survive. However, under normal circumstances, theres plenty of work in our business, and lifes too short to work for abusive companies.
Does all of that sound patently unprofessional to you? Perhaps it is. Nonetheless, ask me how many sweatshops Ive worked in. Now, I spend my nights and weekends living my life while others toil away hour after hour, pushing themselves closer and closer to burnout. Im a decent programmer, but many folks in this business are much, much better than I. And yet, I get paid as well as the next guy and I work forty-hour weeks. Why? Because I realize that, to have a gratifying career, good coding skills arent enough.
The ability to consistently meet your deadlines is indeed another benefit that we can gain by looking beyond our technical abilities. Above and beyond the obvious fact that, if youre hitting your goals in a well organized fashion, youre not killing yourself with pointless overtime. Being successful and productive tends to lower your stress level and makes you less likely to be harassed by management. We get up each morning and spend a very significant portion of our days working for a living. If that experience is unpleasant, then simple math tells us that a very significant portion of our lives is unpleasant. Who wants to live like that?
Of course, if you regain control of your programming life, you can spend more time coding and less time putting out fires. I realize that, technically speaking, coding is coding, but that doesnt mean that I enjoy it all equally. My personal preference is to sit undisturbed writing new code on a project that sparks my interest and enthusiasm. I can assure you, Ive spent many, many hours coding in scenarios that were nowhere near my preference. So have you. I could have gone to school and learned to do a great many things for a living. I became a programmer because it was a way to pay the rent that was actually fun. If Im not having fun, I feel cheated. Consequently, I care a great deal about any aspect of my job that could interfere with the enjoyment of my work, for when Im enjoying what Im doing Im giving it heart, body, and soul. Thats good for me, thats good for the project, and thats good for the company. I believe strongly in win-win scenarios.
Naturally, one of the things we want to do is work on the cool projects instead of the stuff nobody wants to touch. Who cares if youre using the programming language and environment of your choice if the task youve been given is dull, tedious, and probably destined to never see a real, live user anyway? The cool projects, as you have no doubt observed, tend to go to the people who make an effective effort to get them. That sexy new project has to go to someone. Why not you?
I once worked a contract with a friend doing development on a data entry product that had an extremely complex list of input validations that were different for each state in the country and for each new customers needs. The approach that they were taking when we got there was to create a new dynamic link library for each customer/state modification. This struck us as a little cumbersome. We then found that their method of doing this was copying the entire source code base for one library, pasting it to a new directory, going into the code and manually changing anything that needed alteration. Above and beyond the volumes of duplicate code, they even approached the positioning of images by changing magic numbers in the call to display the image, compiling, viewing the image, taking a guess at how much it needed to move, and repeating the process.
My friend, being a serious veteran programmer, observed the obvious that what this really called for was a custom screen editor and code generator, coupled with common code libraries. Of course, we could have solved this problem in other ways that didnt require a code generator, but in talking to the other developers we encountered massive resistance to the idea. They felt that, if there wasnt a lot of code floating around, their job security might be threatened. We both take a dim view of such poor ethics but were realistic enough to know that we were swimming upstream in trying to fight it.
We approached the project manager, who was himself a programmer and a good guy. He was newly arrived to this project and not responsible for the mess of his predecessor. He enthusiastically embraced our idea and told us to get to it. In the end, while the rest of the team slogged away copying and pasting code (my friend also observed that .cpp clearly stood for Copy-and-Paste Programming), we were off creating a cool new app using the latest version of the operating system, all the new UI gadgets, and anything else that we wanted to play with that we felt would make a better tool.
When it was complete, work that took several programmers three months to accomplish was done in a week or two by a single developer. After we had moved on to new contracts, we heard that the project manager was promoted. When a new manager came in, the developers got together, scrapped the system we built, and returned to the old ways of copy-and-paste programming. Who cares? We didnt. Ive long since spent that money. Its my responsibility to conduct myself in an ethical fashion and do quality work; what the company does with it is its own affair. The point is that, although everyone else was working on dull, boring, and tedious tasks, my friend and I were having a blast kicking out a cool app and earning the high regard of the project manager. Why? Because we both pursued talents beyond the technical.
The last reason I list in terms of whats in it for you is no doubt one of the most important. The ability to make better money has a lot to do with non-coding skills. You do work for money, dont you? I suppose I could have pursued different avenues of programming that might make me a buck or two more, but I like what I do. Thats a big deal, and without it I think Id just go back to playing guitar in smoky bars. Lifes too short to spend it doing something you hate, no matter how much it pays. Nonetheless, Ive been broke many times in my life (many of which had a curious relationship to the amount of time I spent playing in smoky bars), and I dont care for the experience. Money aint a bad thing, and, if you want me to write code for you, money is required. How much? Every last penny that I can negotiate, of course. The goal is not just to do what we love for a living, but to get paid extremely well in the process. To accomplish both, youre going to need more than just your technical prowess. If you can code in technical utopia and also have enough money to keep yourself stocked up on the latest bleeding-edge gadgets, isnt that worth a little extra effort?
Who Needs These Skills?
How do these various skills fit into the structure of the development team? You may be thinking that much of what weve discussed thus far is of limited use to a production coder and applies more to those who pursue a management career path. Actually, its never really that simple. Ive never met a programmer whose job could be neatly packaged into one tidy little category. In the real world, throughout the course of the project we end up wearing different hats at different times, even if the job description when we signed on was supposed to be nothing but a coder.
Whether your part of the project is large or small, the same requirements apply if youre to successfully deliver your software. Chances are good that you have some additional responsibilities beyond making sure that your code compiles without warnings and doesnt cause smoke to pour out the back of the box. (Its true, though, that I once came back to my desk in the middle of a debugging session to find a fire extinguisher in front of my keyboard. I can assure you that there were no hardware problems. Honest.) If thats the case, youre going to need skills beyond the technical. However, even if youre fortunate enough to do absolutely nothing but code week after week, you still have other responsibilities. At a minimum, for your project manager to be successful in shielding you from the insanities of the corporate world, hes going to need your support.
Youre also going to be involved in meetings. If you never go to meetings, drop me an email and let me know who the human resources person is at your company. In any event, youre going to find that you spend much of your work-week doing things that dont require compiling, debugging, or uttering the occasional programmers expletive.
The size of your team may shift the types of skills you need, but whether its large or small youve got to be able to cope with the business world in one manner or another. Small teams with a lot of individual autonomy require individuals with good organizational and navigational skills. If youre working in an environment where youre given a task and are then left alone to make it happen, you actually end up doing a lot of project management whether you realize it or not. (You can think of it as just being organized and focused in your work if the "project manager" part makes you twitch.) Whatever you call it, however, you have many of the same duties. You still need to be able to define your requirements clearly, perform adequate design, and arrive at an achievable timeline with milestones arranged along the way, just to name a few. Your compiler wont help you with any of this.
When working on larger projects with multiple teams, youll often encounter as much corporate fumbling from within your team as you do from without. You will likely have a dedicated project manager and perhaps a structure of technical leads as well, along with a hefty complement of programmers. Political considerations will be much more a factor in this environment, as will issues such as how well meetings are run, the competency of your project manager in partitioning tasks, how much interference you get from middle and upper management, and many of the other things weve touched on thus far. Remember, youre at the bottom of the software development food chain. Very little happens higher up that doesnt have an effect on you, one way or another.
You may also find yourself working in the capacity of technical lead from time to time. Although its a testament to the confidence that others have in your technical and organizational skills, this can be a thankless job with great potential for burnout. A technical lead is often nothing more than a project manager with limited scope who carries a full coding load. In other words, not only do you get to do all the work you normally do as a developer, much of it technical and therefore enjoyable, you also get to handle the managerial tasks that are relevant to your team. If it sounds like you just inherited a considerable amount of overtime, youre probably not far from the truth. The trick to working this position with any degree of success, which includes avoiding burnout, is to realize that you cant be a manager at any level, not even the team lead, and get a full days worth of coding in. Depending on how large your team is and how much organizational work youll have to perform, you should take your normal level of coding assignments and knock off a quarter or perhaps even half. Unfortunately, technical leads are not always given the power to make such decisions, which is why its often a real burnout inducer.
Of course, if you have a one-programmer project (and that happens a lot in the business world), youre the project manager, team lead, and coder all rolled into one. If you thought that technical leads had a workload, youll just love this one. Of course, there are some significant benefits to being a one-programmer team. With no other team members to distract you or call you into endless meetings, you might actually get some coding done. However, never forget that there are always going to be managers above you. What theyre called is irrelevant. Any way you shake it, theyre managers and that involves all the normal issues of politics, bureaucracy, their effectiveness in dealing with their own management, and all the rest. Additionally, just because youre the only programmer doesnt mean that its wise to short-circuit the requirements gathering, design, or estimation phases. The rules dont change based on the size of the project, although experience tells us that, if youre a one-programmer team, the chances are good you work in one of those places where they expect to see code flying off your fingertips nonstop. Trying to get a process in place is even harder when youre the only one there.
Taking Control of Your Time
To be successful--and, even more importantly, to be recognized as such by those you work for--you have to get the job done. This sounds too obvious to mention, but sometimes its easy to overlook the obvious. Its important to keep in mind that business people pay you because they want you to produce something. If you really want to be good at your job, theres more to delivering the goods than coding. You have to keep in mind the end goal of the system youre developing and what its supposed to accomplish, and do everything within your power and the scope of your position to see it through to completion. You may or may not be recognized for your extra efforts. You may not even want to be recognized, for a variety of reasons. Nonetheless, your ultimate reward will be in delivering quality software, on time and within budget, without overtime, without stress, and without any other nonsense you can avoid. Make this happen, and you put yourself in a better position for the next project that comes up. Everyone loves a winner.
At every level of development, one of the constants is the need for effective time management if you wish to meet your deadlines. Approaching software development in a scattered and disorganized manner is going to significantly diminish your results and increase the amount of time it takes you to get them. Along with that comes a higher level of stress as youve never really quite got a handle on whats going on. This tends to leave you feeling rather breathless and with the nagging suspicion that youre always running behind. Its probably a correct assessment.
I once knew a project manager that actually oversaw several development efforts. This person always seemed to have several balls in the air at any time. His office looked like a whirlwind of file folders, stacks of paper, and various boxes of uninstalled software, and there were probably a couple of chew toys from his dog in there somewhere as well. He constantly had a harried look about him as if he were somewhere on the border between not being able to cope with it all and the sheer terror that someone else was going to come yell at him. All of his projects were behind, and he spent half his time dealing with customers who were upset about it. This, of course, didnt help free up any time for him to solve the problems.
In short, this was one of the most disorganized managers Ive seen. Little wonder that his projects were a mess. In fact, what thread of cohesion that actually did run through his various teams was the result of the personal initiative of his developers, who wisely saw that they would get no support from their manager and consequently took matters into their own hands whenever possible. The interesting thing about this guy is that, not only was he overbooked as it was, he never hesitated to take on a new project whenever he could get his hands on one. Could he have handled this kind of workload efficiently? Probably not in fortyhour weeks, but it didnt have to be the disaster that it was. It all comes down to organization. He didnt know how to keep his own ducks in a row, had no skills at planning or running a meeting, and interacted with his developers only in a crisis-driven mode, dashing out in a panic to tell them of the latest fire that they had to work late to put out.
With better time management skills, he could have taken control of the various projects, avoided being yanked from one crisis to the next, and perhaps even have delegated a little. Such things would have settled his projects down tremendously. Whats that you say? Its not your problem because you dont want to be a project manager? Youre just a programmer? Well, who do you think he had working for him? If your manager is a mess, and many of them are, youre going to need all the skills you can get purely for self-defense.
System design is another area in which its handy to have some facility in something other than compilers. It is certainly not a given that a good coder is naturally a good software designer as well. Although obviously related, they are two completely separate disciplines. However, you dont have to know how to code to work in an architectural capacity, and you dont have to have design skills to write source code. However, you do need to have a grip on the design side of things before you start writing that source code. If you just shoot from the hip and dont think your way through things on a small scale the same as you would for larger tasks, youre likely to encounter difficulties either halfway through what youre coding or the first time someone else has to interface to your code. We typically think of design in terms of mapping out the entire software system, but, when you get down to it, you should always think before you code. Even if management is inclined to believe that youre daydreaming rather than working.
One of the many reasons you need some facility with design is that, to meet your deadlines, youre going to have to have some skills in estimating as well. Its true that an estimate is of little importance if youre given the date before youre given the assignment, but sometimes youll have a manager who asks you how long a task will take and actually pays attention to what you say. If you cant cook up a good estimate, youre not only setting yourself up for failure, youre doing it to your manager as well. Ive found that in general its a bad thing to make the person who is responsible for your paychecks look stupid to their own boss. People are funny that way.
One of the significant benefits to possessing more than merely technical skills comes when you learn to improve your interaction with others. Sometimes its courtesy, sometimes its being able to deliver the goods, and sometimes its just plain old politics, but its always a beneficial thing that comes back to you. When you come in to the office each morning, you dont deal with a highly specialized class of sentient office furniture. You deal with people. Okay, I did once know someone who spent an inordinate amount of time talking to his furniture but I gave him the benefit of the doubt and chalked it off to sleep deprivation. If you keep in mind that youre dealing with real, live, flesh-and-blood people instead of nameless, faceless coworkers, youre going to have a much better time of it in the business world. The better your people skills, the better your chances of getting what you want, whether its a new computer, a new project, or more money. If you can also learn to be bilingual and speak the language of business people, theres no end to the enhancements your programming career can experience.
For those of us who take our programming seriously, sometimes just the ability to bring better software to life is reward enough. Interpersonal skills help tremendously in this area as well. If you have great new ideas on how your software should be designed or how a particular chunk should be coded, you still have to be able to sell it to others if you want to make it a reality. Proposing new ideas successfully requires more than flowcharts and whiteboards. Decisions are often made not because the facts overwhelmingly pointed to a particular solution but rather due to the charisma of the individual making the presentation, whether it was a formal meeting or just a persuasive conversation in the hallway. Dont feel as if youre really overflowing with charisma? Youd be surprised how much of that can be an acquired skill. We werent all born movie stars. Many times, attention to the details of how things work in the business world and learning a few navigational tricks are all the tools you need to gain the respect and admiration of your peers and management. Many programmers feel that theyll never have much luck in the persuasion department because they werent born natural orators. However, if you learn to speak the language of your audience, understand the things that motivate them, and position yourself appropriately, youll be surprised how often you win. Well be going into these things in more detail later, but Ill touch once more on a recurring theme here: you cant win if you dont try.
Probably the bane of programmers and cubicle dwellers everywhere is the dreaded meeting. Some weeks it feels as if all youve done is travel from one meeting to the next. Sometimes its true. Ironically enough, many of those meetings will be rants from higherups who wonder why the heck were so far behind on our schedule. Youre probably not in charge of most of the meetings you attend and therefore have to suffer through someone elses poor skills at organizing and running such gatherings. Theres only so much you can do in that scenario, but you can help expedite the process at least a little. Further, if you decide to get serious about your skills in meetings, others will notice and a small groundswell may result. A meeting run by an inept manager can be put back on track, shortened, and made more productive when just a few of the attendees understand some of the basics and are assertive enough to help the process along. If youre actually responsible for reducing the number or duration of meetings at your company, youll probably become a folk hero among your peers. (Who knows? They may even name a conference room in your honor.)
Getting What You Want
Something thats not really as obvious as it seems is knowing what you want out of life. The truth is that a very large number of people in this world just dont know exactly what they want. Just as its impossible to meet all the expectations when developing a piece of software with poor or fuzzy requirements, so too is it true in life. That includes your career. If you dont know very specifically what you want, youll have difficulty achieving it and probably wouldnt recognize it if you did.
My observations have led me to believe that a large majority of programmers got into this business much as I did: I started programming for fun, got hooked, and decided that it would be a cool way to make a living. I then went out and got a job. What exactly was I looking for in a programming career? In retrospect, I had absolutely no idea. I just wanted to get paid to write code.
Having put a number of miles behind me by now, I have a much better idea of what I want for two reasons. First, Ive had enough experience to see whats out there, what I like, and what I passionately wish to avoid. Secondly, and I think even more importantly, is the fact that at one point I sat up and realized I was working with fuzzy requirements and decided to do something about it. I actually spent time and gave serious, detailed thought to just exactly what I wanted in my programming career. I then set out to accomplish it.
Naturally, its much easier to get what you want when you know what it is, and I have had a very enjoyable career thus far. Ive spent time doing the types of things I wanted to do and have been paid well for it. This is not because Im any kind of superstar, one-in-a-million programmer. Its simply because I detailed my goals and desires and then set out to accomplish them in exactly the same way that I would approach turning a requirements document into a good design and ultimately an implemented product. That involves little more than taking one step at a time, always with an eye to the future. Of course, from time to time, I revisit my desires and tweak the spec where necessary, as what I want tends to change. I also spend a fair amount of time reviewing where I am, where Ive been, and how things are going so far in my efforts to meet these goals. That helps me to make the necessary course corrections.
Many of us tend to spend our lives on automatic pilot to one degree or another. Im sure if you took a little time to yourself and gave it some thought, you could come up with a pretty decent list of things youd like to change about your current job and perhaps your career or life in general. Thats a step Id encourage you to take. Be specific. Be very specific. What youre defining is the perfect world. Dont leave anything out, even if you think it unlikely to accomplish. Once youve done this, youll have a decent requirements document from which to work.
The next step is to come up with a decent design doc. Take a look at where you are in your career and start brainstorming, just as you would in a design meeting, about how you might get there. Unlike as in software design, in this exercise its acceptable to leave some questions unanswered. You may not see the solution at the moment, but new input or opportunities could come out of the clear blue sky at any point in the future to help you chart a course for that particular goal. Keep it on the requirements list. For all the other items, youll end up with at least a beginning strategy and plan of action. Although this doesnt agree with all of the true software design methodologies, in the real world design tends to get tweaked as we go, benefiting from what we learn and steering around problems as we encounter them. So too will your design doc that you create for your programming career be modified as time goes on. Ive heard it said that no battle plan survives contact with the enemy. Allow for that flexibility.
Once youve got a good design (which in any business is simply a detailed road map for how to get where you wish to be), its time to give some attention to implementation. You now know, in great detail, exactly what the perfect programmers life is, at least for you. You have a strategy in place to make this a reality. The next logical step is to start taking the necessary steps to realize your desires.
When you have both your requirements and design docs sitting in front of you, youll quickly realize that to meet your goals youre going to need a few more tricks up your sleeve than just knowing how to avoid compiler and runtime errors. Thats where were headed next. You already know how to code. Youre good at it, or you wouldnt have a job. Now its time to hone your skills in all of those other areas so you can effectively combat the insanities of Corporate America and achieve your objectives. With any luck at all, the result will be more coding, more fun, and fewer encounters with nervous little dogs. The last time I saw him, the watchmans partner was sporting a camouflage collar and jacket and was having a whispered conversation with the maintenance programmer about inventory control.
About the Author
Christopher Duncan is a vetran contract programmer with more than a decade of experience in both small companies and large corporate environments such as AT&T, Equifax, and Bell Sourth. Irreverent, unconventional, and occasionally controversial, his focus has always been less on the academic and more on simply delivering the goods, breaking any rules that happento be inconvenient.
The Career Programmer: Guerilla Tactics for an Imperfect World. Copyright 2002, Christopher Duncan. Reproduced by permission of Apress. All rights reserved.
# # #