Automated hired a programmer-analyst, Alan, to solve their problem.

Meanwhile, Consolidated decided to ask a newly hired entry-level programmer, Charles, to tackle the job, to see if he was as good as he pretended.

Alan, having had experience in difficult programming projects, decided to use the PQR structured design methodology. With this in mind he asked his department manager to assign another three programmers as a programming team. Then the team went to work, churning out preliminary reports and problem analyses.

Back at Consolidated, Charles spent some time thinking about the problem. His fellow employees noticed that Charles often sat with his feet on the desk, drinking coffee. He was occasionally seen at his computer terminal, but his office mate could tell from the rhythmic striking of keys that he was actually
playing Space Invaders.

By now, the team at Automated was starting to write code. The programmers were spending about half their time writing and compiling code, and the rest of their time in conference, discussing the interfaces between the various modules.

His office mate noticed that Charles had finally given up on Space Invaders. Instead he now divided his time between drinking coffee with his feet on the table, and scribbling on little scraps of paper. His scribbling didn't seem to be Tic Tac Toe, but it didn't exactly make much sense, either.

Two months have gone by. The team at Automated finally releases an implementation timetable. In another two months they will have a test version of the program. Then a two month period of testing and enhancing should yield a completed version.

The manager of Charles has by now tired of seeing him goof off. He decides to confront him. But as he walks into Charles's office, he is surprised to see Charles busy entering code at his terminal. He decides to postpone the confrontation, so makes some small talk then leaves. However, he begins to keep a closer watch on Charles, so that when the opportunity presents itself he can confront him. Not looking forward to an unpleasant conversation, he is pleased to notice that Charles seems to be busy most of the time. He has even been see to delay his lunch, and to stay after work two or three days a week.

At the end of three months, Charles announces he has completed the project. He submits a 500 line program. The program appears to be clearly written, and when tested it does everything required in the specifications. In fact it even has a few additional convenience features which might significantly improve the usability of the program. The program is put into test, and, except for one quickly corrected oversight, performs well.

The team at Automated has by now completed two of the four major modules required for their program. These modules are now undergoing testing while the other modules are completed.

After another three weeks, Alan announces that the preliminary version is ready one week ahead of schedule. He supplies a list of the deficiencies that he expects to correct. The program is placed under test. The users find a number of bugs and deficiencies, other than those listed. As Alan explains, this is no surprise. After all this is a preliminary version in which bugs were expected.

After about two more months, the team has completed its production version of the program. It consists of about 2,500 lines of code. When tested it seems to satisfy most of the original specifications. It has omitted one or two features, and is very fussy about the format of its input data. However the company decides to install the program. They can always train their data-entry staff to enter data in the strict format required. The program is handed over to some maintenance programmers to eventually incorporate the missing features.

Sequel:

At first Charles's supervisor was impressed. But as he read through the source code, he realized that the project was really much simpler than he had originally though. It now seemed apparent that this was not much of a challenge even for a beginning programmer.

Charles did produce about 5 lines of code per day. This is perhaps a little above average. However, considering the simplicity of the program, it was nothing exceptional. Also his supervisor remembered his two months of goofing off.

At his next salary review Charles was given a raise which was about half the inflation over the period. He was not given a promotion. After about a year he became discouraged and left Consolidated.

At Automated, Alan was complimented for completing his project on schedule. His supervisor looked over the program. With a few minutes of thumbing through he saw that the company standards about structured programming were being observed. He quickly gave up attempting to read the program however; it seemed quite incomprehensible. He realized by now that the project was really much more complex than he had originally assumed, and he congratulated Alan again on his achievement.

The team had produced over 3 lines of code per programmer per day. This was about average, but, considering the complexity of the problem, could be considered to be exceptional. Alan was given a hefty pay raise, and promoted to Systems Analyst as a reward for his achievement.

Related posts:

1. The Story of Mel, a Real Programmer

"A recent article devoted to the *macho* side of programming made the bald and unvarnished statement:

<<Real Programmers write in FORTRAN.>>

Maybe they do now, in this decadent era of lite beer, hand calculators, and "user-friendly" software but back in the Good Old Days, when the term "software" sounded funny and Real Computers were made out of drums and vacuum tubes, Real Programmers wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.

Lest a whole new generation of programmers grow up in ignorance of this glorious past, I feel duty-bound to describe, as best I can through the generation gap, how a Real Programmer wrote code. I'll call him Mel, because that was his name.

I first met Mel when I went to work for Royal McBee Computer Corp., a now-defunct subsidiary of the typewriter company. The firm manufactured the LGP-30, a small, cheap (by the standards of the day) drum-memory computer, and had just started to manufacture the RPC-4000, a much-improved, bigger, better, faster --- drum-memory computer. Cores cost too much, and weren't here to stay, anyway. (That's why you haven't heard of the company, or the computer.)

I had been hired to write a FORTRAN compiler for this new marvel and Mel was my guide to its wonders. Mel didn't approve of compilers.

"If a program can't rewrite its own code", he asked, "what good is it?"

Mel had written, in hexadecimal, the most popular computer program the company owned. It ran on the LGP-30  and played blackjack with potential customers at computer shows. Its effect was always dramatic. The LGP-30  booth was packed at every show, and the IBM salesmen stood around talking to each other. Whether or not this actually sold computers was a question we never discussed.

Mel's job was to re-write the blackjack program for the RPC-4000. (Port? What does that mean?) The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located.

In modern parlance, every single instruction was followed by a GO TO! Put *that* in Pascal's pipe and smoke it.

Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the "read head" and available for immediate execution. There was a program to do that job, an "optimizing assembler", but Mel refused to use it.

"You never know where it's going to put things", he explained, "so you'd have to use separate constants".

It was a long time before I understood that remark. Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant.
He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. His code was not easy for someone else to modify.

I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the "top-down" method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first, so they would get first choice of the optimum address locations on the drum. The optimizing assembler wasn't smart enough to do it that way.

Mel never wrote time-delay loops, either, even when the balky Flexowriter required a delay between output characters to work right. He just located instructions on the drum so each successive one was just *past* the read head when it was needed; the drum had to execute another complete revolution to find the next instruction. He coined an unforgettable term for this procedure. Although "optimum" is an absolute term, like "unique", it became common verbal practice to make it relative: "not quite optimum" or "less optimum" or "not very optimum". Mel called the maximum time-delay locations the "most pessimum".

After he finished the blackjack program and got it to run ("Even the initializer is optimized", he said proudly), he got a Change Request from the sales department. The program used an elegant (optimized) random number generator to shuffle the "cards" and deal from the "deck", and some of the salesmen felt it was too fair, since sometimes the customers lost. They wanted Mel to modify the program so, at the setting of a sense switch on the console, they could change the odds and let the customer win.

Mel balked. He felt this was patently dishonest, which it was, and that it impinged on his personal integrity as a programmer, which it did, so he refused to do it. The Head Salesman talked to Mel, as did the Big Boss and, at the boss's urging, a few Fellow Programmers. Mel finally gave in and wrote the code, but he got the test backwards, and, when the sense switch was turned on, the program would cheat, winning every time. Mel was delighted with this, claiming his subconscious was uncontrollably ethical, and adamantly refused to fix it.

After Mel had left the company for greener pa$ture$, the Big Boss asked me to look at the code and see if I could find the test and reverse it. Somewhat reluctantly, I agreed to look. Tracking Mel's code was a real adventure.

I have often felt that programming is an art form, whose real value can only be appreciated by another versed in the same arcane art; there are lovely gems and brilliant coups hidden from human view and admiration, sometimes forever, by the very nature of the process. You can learn a lot about an individual just by reading through his code, even in hexadecimal. Mel was, I think, an unsung genius.

Perhaps my greatest shock came when I found an innocent loop that had no test in it. No test. *None*. Common sense said it had to be a closed loop, where the program would circle, forever, endlessly. Program control passed right through it, however, and safely out the other side. It took me two weeks to figure it out.

The RPC-4000 computer had a really modern facility called an index register. It allowed the programmer to write a program loop that used an indexed instruction inside; each time through, the number in the index register was added to the address of that instruction, so it would refer to the next datum in a series. He had only to increment the index register each time through. Mel never used it.

Instead, he would pull the instruction into a machine register, add one to its address, and store it back. He would then execute the modified instruction right from the register. The loop was written so this additional execution time was taken into account --- just as this instruction finished, the next one was right under the drum's read head, ready to go. But the loop had no test in it.

The vital clue came when I noticed the index register bit, the bit that lay between the address and the operation code in the instruction word, was turned on --- yet Mel never used the index register, leaving it zero all the time. When the light went on it nearly blinded me.

He had located the data he was working on near the top of memory --- the largest locations the instructions could address --- so, after the last datum was handled, incrementing the instruction address would make it overflow. The carry would add one to the operation code, changing it to the next one in the instruction set: a jump instruction. Sure enough, the next program instruction was in address location zero, and the program went happily on its way.

I haven't kept in touch with Mel, so I don't know if he ever gave in to the flood of change that has washed over programming techniques since those long-gone days. I like to think he didn't. In any event, I was impressed enough that I quit looking for the offending test, telling the Big Boss I couldn't find it. He didn't seem surprised.

When I left the company, the blackjack program would still cheat if you turned on the right sense switch, and I think that's how it should be. I didn't feel comfortable hacking up the code of a Real Programmer."

Related posts:

1. Life as a programmer
2. The Parable of the Two Programmers

"Around two-thirds of workers say the most stressful aspect of their jobs is their immediate boss, their line manager (Hogan, 2006). While this will come as no surprise to most, this statistic suggests a massive number of unhappy working relationships. So, does this mean that leadership is failing on a massive scale? Well, not exactly...

A recent article published in American Psychologist beautifully explains why so many people experience their managers as piping hot geysers of stress (Vugt, Hogan & Kaiser, 2008). What emerges is that bosses aren't inherently bad people (mostly), but that the modern culture of work sets them up to fail. Here are the seven main reasons I've picked out from this article for why leaders fail:

1. Strict hierarchies.

For Mark Van Vugt of the University of Kent and colleagues a large part of the problem with many modern organisations is their hierarchies. Leaders are at the top of the chain and are assumed to have all the answers, so they make most of the decisions. In reality knowledge and expertise is spread across people in organisations. But it's the leaders who must be seen to lead and so followers get frustrated because their superior knowledge and expertise is frequently ignored. This leads to:

2. Poor decision-making.

Leaders often don't make any better decisions than followers, and frequently make worse ones. This is another consequence of strict hierarchies. Rather than setting up leaders to fail, Van Vugt et al. (2008) argue it's better to agree that leaders are not always the best people to make the decisions. Spreading the responsibility around, or using more participatory strategies for decision-making is often more effective. But this isn't the way things generally work, part of the problem is:

3. Huge pay differentials.

Followers often hate their leaders because of the huge difference in their salaries. It's hard to feel any sympathy for someone whose pay is stratospheric (average CEO pay is 179 times that of average workers). And, because more pay means more status, leaders can quickly come to believe they really deserve the God-like status their pay suggests, resulting in their thinking they have all the answers and that they have the right to treat their employees less than fairly. In the bosses' defence, though, there are:

4. Impossible standards for leaders.

Perhaps because of the huge pay and incredible demands, followers expect their leaders to be almost superhuman. The leadership literature identifies a whole range of personal qualities thought important for a good leader. These include integrity, persistence, humility, competence, decisiveness and being able to inspire the troops. While a leader may be high on one or two of these, they are unlikely to have the full set. Followers are almost bound to be disappointed by what is, after all, another fallible human who is just trying to:

5. Climb the greasy pole.

If the boss is nice to you, it's a bonus, because it's not required for them to get on in the organisation. Leaders are promoted by those higher than them, not those below them - so it's only necessary for bosses to impress their bosses. This is a recipe for disaffection amongst the followers. Talking of which, forget the psychology of leadership, what do we know about the:

6. Psychology of followership?

One of the best points Van Vugt et al. make is that although it's leadership that has been most extensively studied and discussed, most of us end up as followers. So really the psychology of followership is more important than leadership. What is it that makes us follow someone else? And, more subversively: do we need leaders? For example, some research shows that when people know what they're doing, they resent having leadership imposed on them. Generally, though, there's little known about followership, and how to avoid:

7. Alienation.

As a result of the strict hierarchies, huge pay differentials, poor decision-making, greasy-pole climbing and feeling powerless to change huge bureaucracies, followers naturally develop feelings of alienation, and alienation kills motivation and productivity, along with any hope of job satisfaction.

Talk is cheap

By implication the way to rectify these perceived problems is to do the reverse. Don't instigate rigid hierarchies, discourage huge pay differentials, democratise decision-making and don't set impossible standards for leaders. Some organisations are already managing this - presumably those in which followers don't find their bosses the biggest sources of stress - but most are not.

Of course talk is cheap and recognising the problem is quite different to knowing what to do about it, or having the courage to do it. Anyone wanting to make these types of changes across an organisation would have to be a really great leader - and there are truly few of those around.

What do you think?

Do you recognise these problems in your organisation? Has anyone tried to do anything about it? Are there other major reasons leaders fail?"

No related posts.

It's taken me the better part of a year to finish writing this article, and the reasons it took that long are tied directly to the topic at hand. If anything, the last year has made it clear that we as an industry are facing increased levels of stress, illness, and exhaustion. Having learned a few things from my own battle with exhaustion and burnout, I hope they’ll benefit others who are now or may eventually be in the same situation.

Burnout: running on empty

Burnout is a psychological response to “long-term exhaustion and diminished interest,” and may take months or years to bubble to the surface. First defined by American psychoanalyst Herbert J. Freudenberger in 1972, burnout is “a demon born of the society and times we live in and our ongoing struggle to invest our lives with meaning.” He goes on to say that burnout “is not a condition that gets better by being ignored. Nor is it any kind of disgrace. On the contrary, it’s a problem born of good intentions.” Another description in New York Magazine calls burnout "a problem that's both physical and existential, an untidy conglomeration of external symptoms and personal frustrations."

Sounds like fun, doesn’t it?

During his research, Freudenberger and his associate, Gail North, developed a simple outline to describe how otherwise healthy individuals can burn out, the key being that people may experience several or all phases, though not necessarily in a specific order.

The identified phases, several of which I bet sound familiar, are:

* A compulsion to prove oneself
* Working harder
* Neglecting one’s own needs
* Displacement of conflict (the person does not realize the root cause of the distress)
* Revision of values (friends, family, hobbies, etc., are dismissed)
* Denial of emerging problems (cynicism, aggression, and frustration become apparent)
* Withdrawal from social contexts, potential for alcohol or drug abuse
* Behavioral changes become more visible to others
* Inner emptiness
* Depression
* Burnout syndrome (including suicidal thoughts and complete mental and physical collapse) [2]

It's important to note that burnout is not the same as depression, though there are shared characteristics that blur the distinction; burnout can be brought on by fits of depression or may lead to depression itself.

My own head-on collision with burnout came at the end of 2007. In the year since, my focus has changed and I’ve become extremely conscious—and protective—of the balance I need in my life. Here's what I've learned.

How it happens

Burnout doesn’t happen without stress. Characterized as being "too much" of something, stress may come from too many meetings, projects, responsibilities, unrealistic deadlines, improperly set expectations, distractions, or any number of other things prevalent in our hyper-connected world. Stress is not crippling in and of itself, but we each have limits, and once those limits are reached, we can find ourselves teetering on the brink of burnout.

Although burnout is primarily a work-related illness caused by an imbalance in an individual’s personal goals, ideals, and needs as related to their job, stresses and factors outside the workplace can also contribute to the problem by wearing down emotional defenses.

You may be flirting with burnout if:

* Every day is a bad day
* You are no longer emotionally invested in your job or the work you’re doing
* You feel unappreciated or do not feel like you’re making a difference in your job
* There is a clear disconnect between your personal values and what is expected of you
* Self-defined goals or those imposed on you are unrealistic or unreasonable
* A significant amount of your day is focused on tasks that are not fulfilling on a personal or emotional level

Ultimately, burnout results from a lack of equilibrium. When you lose your balance, physically, you fall over. Burnout is very similar, except that once you’re down, it can be a real challenge to get back up.

How to recover from (or prevent) burnout

The first and most important step in preventing or recovering from burnout is to recognize the problem and objectively survey your situation.

* What are the stressors in your life?
* Are there aspects of your job that do not align with your personal goals and values?
* Are you not doing the type of work you enjoy? Are your own measures of success realistic?
* Are you really engaged in the work you’re doing, or are you just overloaded?

These same questions can help you restore your internal balance without going as far as changing jobs or careers, which is rarely a realistic option. Burnout doesn’t have to be a career killer, but it can be if left untreated.

Stop (or at least slow down)

If you’re working 50 or more hours a week, cut that number to the bare minimum. If possible, use up your sick days, work from home one day a week, and take a vacation or a leave of absence to give yourself the time needed to decompress, reflect, and reconnect. Sabbaticals are gaining acceptance in our industry, and even one day outside of your normal routine can help prevent burnout or get on the right track to push through it.

The point being: take yourself out of the problem for as long as you can realistically afford to.

Communicate

When in doubt, talk.

Seek counsel and support from family, friends, and industry peers, or consider more formal coaching, possibly through a local business network or wellness center.

In my case, my wife recognized my burnout before I did, and helped me find a local business coach who understood client demands in the creative realm and the pressures of operating a small business. The time spent reflecting on how I got to where I was at the end of 2007 was invaluable, and has been the catalyst for the many changes I’ve made since.

Set boundaries and expectations

The days of the 9-to-5 job are gone and the boundaries between work and home are blurred to the point of non-existence. We're expected to be available nearly all the time, and the problem is often exacerbated for freelancers or anyone who works primarily from a home office where the only divide between being “at home” and being “at work” is a single door or a flight of stairs.

It’s not a badge of honor to work 80 hours a week or to answer e-mail or to Twitter at all hours of the night. Ask yourself: Have you set sufficient boundaries between your job and your life outside of work? Are you guarding those boundaries?

Although clients may choose to leave you messages and send e-mail at all hours, it’s up to you to set expectations about your responsiveness. As soon as you leave yourself open to responding to e-mails at 10 o’clock at night, you set a precedent that can be hard to take back.

Sleep. More.

The world is a much smaller place now than it's ever been. Information is at our fingertips whenever we want it and wherever we happen to be. Time zones blur, allowing us to work with clients in the same city as easily as those on the other side of the world. But we still need sleep, and we rarely get enough.

Sleep gives our brains a chance to work out problems and process the information we’ve absorbed throughout the day. Even if you can function on four or five hours of sleep, how much better would you function on seven or eight hours? Even though the 9-to-5 work day is history, there’s no reason work should extend into the wee hours of the morning.

Create a daily routine

It’s not unusual for creative types to do their best work at the same time every day. By this I mean that it’s important to follow our own circadian rhythms. Hemingway began writing every morning at dawn and explained his choice this way: “There is no one to disturb you and it is cool or cold and you come to work and warm as you write. You read what you have written and, as you always stop when you know what is going to happen next, you go on from there.”

The same system often works well for designers or developers. Do your most important work (or the work requiring the greatest focus) during that time when you’re most energized and have the fewest distractions. Use the rest of your working hours to solve secondary problems or gather information that will fuel the next productive sprint.

Make time for numero uno

Whether you’re treading water or already below the surface, making time for yourself is critical. It’s easy to get caught up in the demands of bosses or clients and leave precious little time for your own needs.

Spending time with family, friends, or your personal interests may provide the fulfillment you don’t get at work. So get out. Go to a museum or an art gallery. Go to the library or a concert. Get some exercise. Play. Make time for what makes you happy, and guard that time fervently.

Examine your values, goals, and measures of success

Know thyself, but be gentle. What are you passionate about? How do you evaluate yourself against expectations placed on you by managers and clients, and the work you’re doing? Are those measures grounded in reality? Are your personal development goals being met by the type of work you are doing? Are you feeling too much pressure from unrealistic demands or those that go against your values? What frustrates you?

Simply connecting with things that matter to you can provide perspective. Although burnout is a miserable experience, it can also be a great opportunity for personal growth and discovery.

Focus

Good work requires focus.

Focus might mean restricting your access to e-mail, IM, Twitter, and Facebook, or turning off your cell phone. Modern communication conveniences provide a valuable social connection to the outside world, but they can also destroy concentration and clarity.

Change your situation

Although changing careers is usually not an option, there’s plenty you can do to make your job more engaging and fulfilling.

Change departments, learn a new skill, or simply focus more on the things you’re good at, and that make you happy.

Offload responsibilities that are not fulfilling or that are not part of your core job function. If you’re a designer, focus on design, not on day-to-day accounting. If you’re a developer, focus on building great applications, not on client hand-holding. If you’re a freelancer, shake up your routine—and whenever possible, bring in additional help on the parts of projects that you don’t enjoy or that someone else could do better.

Changing your situation could be as easy as changing desks: If you work at home, spend more time at a local coffee shop or bookstore that has free wifi. If you work in a more traditional office, change desks or spend time in another part of the office.

Rely on a good process

The reason we have processes is so that we can focus on getting things done, not on wondering what to do next.

If you don’t have a good work process, get one. Talk to your peers, read up on the topic, and see what processes others use. Experiment and find out what works for you. If you already have a process that you think works, scrutinize it, clarify it, and simplify it as much as possible.

Educate your clients on your processes, follow them yourself, and ensure that everyone you work with understands the consequences of failing to complete deliverables or meet deadlines.

Regaining your balance

When you’re burned out, you know it. You can feel it and taste it, but in order to get past, it you have to acknowledge it and fight to restore your internal equilibrium. Stop, decompress, communicate, and focus. That process often begins with a look inward to learn what gives your life balance, such as family, friends, personal interests, and hobbies—the things that counterbalance your life on the web.

Your life should be just that—a life; if your waking hours are entirely consumed by work, or if you’re unfocused and inattentive to your own needs, burnout will be waiting at every turn.

By Scott Boms

Related posts:

1. The truth about working in the IT industry

No related posts.

Related posts:

1. Programming is like sex
2. The Story of Mel, a Real Programmer
3. Xobni Makes Life Easier. Really. It Does.

2. They pay you to make the client happy…
Just like a prostitute.

3. The client pays a lot of money, but your employer keeps almost every penny…
Just like a prostitute.

4. You are rewarded for fulfilling the client’s dreams…
Just like a prostitute.

5. Your friends fall apart and you end up hanging out with people in the same profession as you…
Just like a prostitute.

6. When you have to meet the client you always have to be perfectly groomed…
Just like a prostitute.

7. But when you go back home it seems like you are coming back from hell…
Just like a prostitute.

8. The client always wants to pay less but expects incredible things from you…
Just like a prostitute.

9. When people ask you about your job, you have difficulties to explain it…
Just like a prostitute.

10. Everyday when you wake up, you say: “I’m not going to spent the rest of my life doing this.”
Just like a prostitute ….

Related posts:

1. Programming is like sex
2. Life as a programmer
3. Burnout