I have been blessed with an amazing workplace and my colleagues are really understanding..

However this is my first programming "gig" and i know some people aren't so lucky,

Especially those who run their own company!

(I've seen my boss work unhuman hours and go way beyond out of his way to make a customer happy.)

The ugly truth is when your contracted by a big corporation, as we have been, you learn quickly that corporations don't care for clean readable code, programmer happiness, best practice or maintainability..

And they will call you on weekends.. At 3AM.. with 1 weeks worth of work they need for a meeting at 7AM!

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

Why do we need to be pressured at all? If there is a deadline, then ok, if not, trust we will get it done as soon as we can without cutting corners. Aren't we adults here?
–
JD IsaacksApr 27 '11 at 16:29

3

cutting corners isn't an evil thing, it is a real world consequence of what is of business value to the customer. What you as a developer might think is important and would be "cutting corners" might be on absolutely no value to your customer.
–
Jarrod RobersonApr 27 '11 at 16:33

43

I find that 1 Atmosphere of pressure to be acceptable <("-")>
–
DarknightApr 27 '11 at 16:45

12 Answers
12

How much they should be under and how much they will be under are very different and will be close or far apart depending on the job.

As for should: Enough to get the job done without causing stress to the point where it affects health and well-being (social, mental, physical). If you burn out, it was too much! If it were possible to quantify that, it would differ between individuals.

As for will... Calls on weekends and 3 AM in the morning may be normal if you are on-call and support 24/7 production systems and carry a pager/cellphone and laptop.

It will also depend on industry. Some industries have much tighter deadlines - the game industry will have to ship a product in time for the next (gift-)buying cycle (Christmas, spring graduation season, back-to-school, etc...). Some industries such as finance and insurance sometimes must implement things by a certain deadline due to changes in legislation of their industry. For software products that are not dependent on other cycles (such as consumer retail or government), deadlines might have more leeway and relieve some pressure - unless the client is very insistent (which will depend on the client).

Also, the amount of pressure can be affected by the size of the team. If the workload is spread evenly between a large team you'll feel less pressured than if a very large workload is piled onto a small team.

And the type of work... lots of small support tasks and switching back and forth between them can sometimes create feeling of being more pressured than one or two long-term tasks (at least for me).

The answer is very little to NONE on a daily basisexcluding self inflicted delays.

There are two reasons to have to work under undo external pressure.

Both can be mitigated.

1) Incompetent Management promising unrealistic goals.

2) Incompetent Developers unable to meet realistic goals.

Both can exist at the same time. Neither should have to.

Agile Methodologies, SCRUM in particular can help mitigate these issues to a great extent. The management lets the development team decided what they can reasonably commit to in a single Sprint ( 1 or 2 weeks at most ). Even a very junior development team can learn to estimate what they can accomplish as a team in 1 or 2 weeks.

Agile Methodolgoies also focus heavily on what is of business value to the customer. Clean code, maintainability, best practices, etc. isn't of high value to some customers or some projects.

It depends on the product and the customers desires, if the product owner explains to the customer you can hack something together in 2 weeks that has limitations, but have to go and redo it later to remove those limitations, there is nothing wrong with that. It is technical debt, and it is documented and managed.

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the
items on the right, we value the items
on the left more.

If you have a job, do contract work, or own the company, you have economic pressure. Not many can claim money doesn't matter so I do whatever I want whenever I want. It's nice to know there is a demand for the work you do.

I think the better programmers put more pressure on themselves, but don't show it. You have to take pride in your work without driving yourself nuts.

Any business person is under pressure, from the business owner down. Executive management at a large company also has a lot of pressure. They've got to raise capital, keep the stock up, keep up the loan payments, the bond debt payments, the stock dividends. They've got to satisfy the FCC, along with two handfulls of state and federal regulators. They've got to honor their partnerships, pay their suppliers, make payroll.

You, as a cog in the machine, are going to get some of that pressure. The better the management, the less these externalities are going to be visible, but make no mistake, they hired you to help them meet their commitments, and if you don't, you're gone.

Now, if they make unreasonable demands and are being overly difficult, that means their managerial skills are lacking. That means they aren't very good yet. They get paid to do their job, so don't do it for them. If you don't like having to pay in tears because management is incompetent, leave.

It all sounds insane, but you're not giving us anything like enough information. Prescribing silver-bullet methodologies is premature before we understand the root-causes:

Pressure from whom? WHO is calling you at 3AM on weekends, with a week's worth of work: your
boss? the customer? All of them? What are the main process failures why requirements weren't stated earlier? When are requirements defined? Sit your boss down and walk them through how a specific example of how things should have happened - what is their reaction?

Is your boss a nutjob/workaholic/stressbunny? (we infer he's single and has
no personal life) Is the customer a lunatic? Is the company on the point of
collapse? Or quite possibly several of these? Did your company succeed on
previous projects with other customers? Did your current customer treat other
previous suppliers like this? Did your boss/salesguy underbid a fixed-price contract? Or is your employer making tons of $$$ and paying you flat-rate? If you didn't you sign a contract agreeing to be on-call (and you should be paid for that), tell them it's not acceptable.

What type of software is this (financial? web? etc), when is
software supposed to be delivered, how do you do testing, is there a test plan, how do you measure quality, what are your agreed quality metrics? Does someone need to hire a QA contractor?

"You learn quickly that [the customer?] don't care for clean readable code, programmer happiness, best practice or maintainability.." That's not the important part: your boss and employer should have a reasonable appreciation of these - do they? If not, why not? If yes, why are they sacrificing them?

How much can you influence this insanity (the boss, and your employer, not the customer directly)? Conversely, can you afford to quit? What is your limit for how much insanity you can handle? What would happen if you tell them you take work calls until x pm, and they need to fix their processes urgently (make them specific constructive proposals, backed by data).

As you progress in figuring out the ideal solutions to these, use it as a checklist to find a sane job in a sane company on a sane project. Then when you quit (as Agile Scout recommends), if they care to listen (they may well not), if you haven't already told them what they should be doing, try telling them.

This is going to vary from programmer to programmer. I've seen some programmers thrive under pressure and others go missing in action with the same pressure. A good manager should know how much to apply.

How much pressure should a programmer be under?

Enough to meet a deadline but not too much to sacrifice all quality to do so.

You need to have personal boundaries, of what you're willing to accept and what you're not willing to accept. This will be based on your own values, your own personal life outside of work, your own experience, your own confidence in finding another job, and also how much money for living expenses you have squared away in case you need it.

This is not a decision we can make for you. This is not even a decision you can make for your boss. For instance, your boss may just be a workaholic, a people-pleaser, or a martyr.

Also, there are all kinds of bosses, customers, and corporations out there. Note that if a corporation/customer is going out of business, or is making irrational demands of your time, sometimes there is just nothing you can do to negotiate a more rational working schedule, and sometimes firing your own employer and trying to find a better job can be your best option.

So it all comes back to having personal boundaries. Most phones have an off switch. It's your choice whether you want to use it or not.

I don't think pressure should be a part of normal workflow at all. I am an adult. My manager wants me to do X in time Y, I tell him I will need Y+Z, we talk about it until we find a satisfactory solution. No pressure needed, since both sides want to do a good job and satisfy the client (in my case, the client is the trader sitting next to me, so I'm doubly motivated to a good job -- their profits pay my salary). As long as everybody understands what the game is about, there is no need for pressure. Having to apply pressure means that there is some conflict which needs to be resolved, or somebody doesn't understand something and should be explained what the situation is.

The amount of pressure a programmer will experience will vary widely not only by the company, but also by the point in the development cycle.

If you're closer to the time that a release is due, you can expect longer hours and more pressure to deliver.

However, if you're expected to provide support for mission critical issues, it's possible the you might have to be on-call for nights and weekends.

A lot of the pressure will depend on your team's leadership. If they are reasonable, they will try to manage the expectations for their developers so that too much isn't required of them. You shouldn't be surprised to see things like late changes to specs and last minute bugs, which definitely adds to the pressure.

Knowing that your work can significantly affect your company's revenue stream will be a lot of pressure for anyone in any position. If you're in a good company, they will try to balance the customer's needs with their team's resources, or risk burning out their developers.

In Peopleware, they put forward the idea that knowledge workers tend to be intrinsically motivated - and set their own goals - when they are given the opportunity to apply themselves and set their own quality bar. I know that personally, if I am given the opportunity to write something high-quality, without a lot of external limitations, I'll be motivated enough to set my own (fast) pace and put the pressure on myself to make it happen at the highest level of quality I am capable of.

When pressure is used as an extrinsic motivator (e.g., your boss telling you to finish ASAP) for too long, and you are asked to cut corners and lower your quality bar, you'll eventually lose your intrinsic motivation to work hard and do a good job. When the pressure is manufactured (e.g., setting a deadline that isn't necessary just to put pressure on people) it also erodes trust. Johanna Rothman has a whole section devoted to these 'schedule games' in Manage It.

So I think applying pressure to knowledge workers is counter productive - instead, we should find ways to enable them to pressure themselves by giving them the freedom, , control, and support to set goals that push them beyond their limits and bring their intrinsic motivation to the fore.

If things are properly planned generally you should experience very little stress in day to day work.

Maximum stress to be tolerated

At worse you should feel stress only when something unpredictable goes to hell. (Building fire, infrastructure failure, unusual loss on work hours due to sickness, etc.) The sort of stuff that no one could reasonably predict. In these cases sometimes you have to step up to overcome the disruption, other times it calls for stepping back and adjusting plans accordingly. These events should be rare.

If you feel any level of stress consistently or extremely stressed at any point THERE IS A PROBLEM! These kinds of stress will literally take years off your life and be a huge detriment to both your personal productivity and quality of life. perpetual stress causes depression, irritability, heart disease, etc. Huge spikes in stress can cause heart attack, stroke, ulcers, etc. If Programming ever triggers an Adeline rush or fight or flight reflex, you should strongly consider changing employers immediately.

There are many common stressors at the work place, most of these stressors are related to the following.

Lack of confidence in being able to properly accomplish a task

Lack of autonomy

Hostile working conditions

There are countless individual stressors, but ultimately most are just sub items in the above mentioned.

First, your confidence. If you lack reasonable competency to do your job YOU NEED TO FIX THIS! if you have the necessary skills but just think you're less capable than you really are you also need to fix this, but it's something that might require outside assistance.

Second, lousy planning. In my personal experience from the bottom of the IT food chain to Manager poor planning is the primary stressor in our industry.

Sometimes it's by design (hostage planning) as I call it. Rake the developers over the coals until they agree to an unreasonably ambitious deadline, because hey, people work harder when they think their neck is on the line...

Sometimes it's just a mistake. Forgetting some slow process will be needed, constantly shift directions as "priorities change", planning a big rollout right before a holiday weekend, etc.

Fact is, while hostage planning gets things done, at also gets them done poorly with a higher bug count and more technical debt. Mistakes in planning happen, typically in proper planning you have some cushion time to mitigate mistakes, but it's not always enough, these are the only times stress should reasonably sneak in.

(You can choose whatever planning methodologies work for you and your company waterfall, agile scrum, agile lean, etc. They all can be done relatively stress free. I'm partial towards agile lean.)

Lack of Autonomy

Want to get stressed out fast? have your boss dictate how you do your work, as you work, and constantly visit your desk day in and out for updates.

You're a professional who's been hired for your technical knowledge and abilities, anything that gets in your way is your enemy and stresses you out. A good boss gets you what you need to do your job and has set times (usually a daily or weekly meeting) to check where things are. A terrible boss doesn't let you decide how to implement something and instead just says "you'll do it like this". This lack of autonomy makes you feel like your skills are wasted and creates needless stress that ultimately hinders productivity.

While you can influence autonomy, your boss (and their boss) are the ones who'll determine how much or how little freedom you have to get work done properly.

Hostile working conditions

Not much to explain here, if there is the looming threat of being fired, hostility, sexist, racist, etc behavior it's going to stress you out, and in many cases this behavior is illegal.