Live data from Hacker News

But nobody wants a “fast-paced environment”

programmers.stackexchange.com

31–40 of 70 posts

Re: But nobody wants a “fast-paced environment”

#31
post #12

There is a sort of stress that comes from a "slow-paced environment" where you've got a 50% or less duty cycle of doing real work because you're always waiting for somebody else to do something. Too little work can be just as stressful as too much.

Having not enough work to do is slightly worse than having too much, IMHO

This is the battle I fight every day. I'd rather have a workload that's 110% of my capacity than be at 50%, which I generously where I'm at now.

We're an "agile" shop that grossly under-allocates out of fear of failing a sprint.

Re: But nobody wants a “fast-paced environment”

#32
post #12

There is a sort of stress that comes from a "slow-paced environment" where you've got a 50% or less duty cycle of doing real work because you're always waiting for somebody else to do something. Too little work can be just as stressful as too much.

Having not enough work to do is slightly worse than having too much, IMHO

Just pretend you're at Google and you have a 20% project you work on. Or learn you some iPhone/'roid programming so you can earn some $ on the side.

Or manage your investment protfolio.

Robert Kiosaki (of Rich Dad/Poor Dad fame) in one of his books gives a couple of examples of people who became millionaires while working for the man and collecting mediocre paychecks. Both were in jobs with plenty of downtime or waiting around for other people. One was a fireman who would read the financial news/stock reports looking for bargain stocks, the other was (I think) working for the Postal Service and he would spend his 20% time looking for real estate bargains.

Alternately, you could start preparing now for your next job.

I worked one time for a boss that I really didn't see eye to eye with (his behaviour included being intoxicated at work to give you an idea). The company had done some semi-disastrous change over of an old reliable minicomputer that customers would access directly via modem to some new fangled dodgy and unreliable web based system. So to punish me for not sucking up to my boss, I got stuck in another building with no computer and had to take phone calls of people complaining bitterly about this. Basically our script boiled down to figuring out which browser they had, and then walking them through the upgrade to the latest version, and if that didn't fix whatever problem they were having, there wasn't anything we could do.

I was, of course, mortally offended. Tech support? The lowest of the low? the janitors of IT? ptooiee

But at the time I was reading through 7 habits and got to the bit about the guy in the concentration camp who decided that the only person that could decide whether he was unhappy was himself.

Anyway, that humbled me a bit. Tech support might not be glamourous, but it's certainly no death machine.

So I decided to enjoy it, even though I had to deal with angry people who had nothing to do. During the downtime I worked on adventures for Shadowrun or AD&D or something like that, basically just doodling. It filled up the time pretty fast. When someone angry would call I would empathise with them a lot more (which calms them down really quick), and I'd be apologetic that they'd been put in that situation by my company.

Eventually my evil ex-boss figured out that I was actually enjoying the tech support. So he took me off it, and gave me nothing to do. So then what I did was I took to wandering around, asking other people how they were doing, helping other programmers debug their code (there's something semi-magical about sitting down at the code they've been banging their head against and then indenting their code properly... half the time they suddenly see the problem, the other half the time it gives you time to figure out what the problem is but to them it looks like you find the problem instantaneously :D )

I'd also put my hand up for any work in obscure and dreadful old languages, things Man Was Not meant To Know. you know, like COBOL or C++ :D In a sufficiently large and sufficiently old organisation there's a surprising amount of that stuff lurking in the background that desperately needs maintenance.

Re: But nobody wants a “fast-paced environment”

#33
post #12

Earlier quoted context omitted.

Having not enough work to do is slightly worse than having too much, IMHO

This is the battle I fight every day. I'd rather have a workload that's 110% of my capacity than be at 50%, which I generously where I'm at now. We're an "agile" shop that grossly under-allocates out of fear of failing a sprint.

This also happens in those implementations of Agile where they try to pretend that programmers are all easily interchangeable cogs in a machine. The problem is, anybody they get who is better than average or has some natural talent is going to be bored out of their tree.

What I would do, is start picking future cards and then when they come up give ridiculously low estimates for them (because they were already finished on my machine :D ).

"Oh, you want a persistence layer for all this? Okay, that will take... -17 minutes."

Or, alternately, if I didn't want to bend people's minds or break the wills of the junior programmers (messing with the jps is half the fun of these sorts of things :D ), I'd work on some technical debt, since Agile projects tend to accumulate it faster than a sophmore with Daddy's credit card.

Re: But nobody wants a “fast-paced environment”

#34
post #27

"fast-paced environment" says more about the people than the environment... Let's say, for example, that your environment changes at rate "10". If you normally move at rate "7", this environment would seem fast-paced to you. But if you're accustomed to moving at rate "15", you wouldn't even consider it to be fast-paced. In my experience, what most junior and enterprise programmers would consider "fast-paced" would se…

Although normally the Agile evangelists are whacked out wierdos, one of them did say something useful to me recently.

He said that "all coding is change". This is simple, trite and deeply profound.

All coding is change. Either you're building something new (change) or you're fixing a bug (change) or you're adding a feature (change).

The whole rhetoric about programmers who don't like other programmers being 'afraid of change' or unwilling to 'embrace change' is nonsense.

Given then, that all coding is change... I wonder what it means to say that some environments change faster than others.

What does this mean? Requirements flip-flop? Staff turnover? Starting projects and then killing them softly with this song?

Re: But nobody wants a “fast-paced environment”

#35
Software job postings are full of cliches. Best to ignore the description and instead use the interview to ask how project requirements are decided, scheduled, and delivered. If their process doesn't mention any input from developers other than "deliver" then ask how often morale improvement beatings are administered.

Re: But nobody wants a “fast-paced environment”

#36
"Fast Paced Environment" means:

1) The specs are not in place 2) They are a software company, mostly 3) The managers are not really managers, but engineers who were given a battle field promotion 4) They have a set of key customers who control 51% of revenue, who dictate everything and change their mind frequently

Re: But nobody wants a “fast-paced environment”

#37
"fast-paced environment" means getting shit done. it means rolling hard like facebook, google, zynga, groupon, etc. it means launching fast. it means getting feedback fast. it means failing fast. it means the exact opposite of the folks complaining about it who work at ibm or hp or microsoft or yahoo or aol. or worse yet, some hole-in-the-wall enterprise vendor inflating internal budgets and wallowing in mediocrity.

fast-paced to me means "if you can't keep up, don't step up."

regardless, if you have to ask, it's not a place for you to work.

m3mnoch.

Re: But nobody wants a “fast-paced environment”

#38

There is a sort of stress that comes from a "slow-paced environment" where you've got a 50% or less duty cycle of doing real work because you're always waiting for somebody else to do something. Too little work can be just as stressful as too much.

Weirdly enough, I find that fast-paced and slow-paced can be combined into an annoying hybrid I'll just call "unpaced." An unpaced organization has a hurry-up-and-wait mentality about decisionmaking, but once a decision has been made -- inevitably, right before a big delivery deadline has come and gone -- everyone is sent into an unnecessary crunch mode: the aptly named "fire drill."

Nine times out of ten, if you're at a company with a lot of fire drills, it's because somebody a few levels above you isn't managing timelines appropriately, or some folks at that level just aren't talking to each other. Point is, the "fast-paced" moments are usually symptoms of a deeper issue.

Re: But nobody wants a “fast-paced environment”

#39
I want a fast-paced environment. And I want to work with people who also like a fast-paced environment.

A fast paced environment is not the same as a "ridiculous hours" environment (I've done that - 80 hrs per week, high pressure). Nor is it a "death march" environment.

What it should be is a place where people come in to work ready to go, work intensely for 8 or 9 hours, then go home to enjoy the rest of their lives. I work at one of the more aggressive large web companies and we have an "email blackout" policy on weekends, for example - if it's not an operations problem, we ask folks to wait until the work week to send emails about it so that folks can concentrate on enjoying their time off undiluted by work and be ready to go on Monday.

Re: But nobody wants a “fast-paced environment”

#40
post #27

"fast-paced environment" says more about the people than the environment... Let's say, for example, that your environment changes at rate "10". If you normally move at rate "7", this environment would seem fast-paced to you. But if you're accustomed to moving at rate "15", you wouldn't even consider it to be fast-paced. In my experience, what most junior and enterprise programmers would consider "fast-paced" would se…

Although normally the Agile evangelists are whacked out wierdos, one of them did say something useful to me recently. He said that "all coding is change". This is simple, trite and deeply profound. All coding is change. Either you're building something new (change) or you're fixing a bug (change) or you're adding a feature (change). The whole rhetoric about programmers who don't like other programmers being 'afraid o…

While it is simple and trite, how is it profound? All human activity is change by that definition.
Post reply on HN