
But nobody wants a “fast-paced environment” - kpdvx
http://programmers.stackexchange.com/questions/59173/why-do-ads-for-s-w-engineers-always-say-they-offer-a-fast-paced-environment
======
PaulHoule
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.

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

~~~
stewiecat
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.

~~~
Stormbringer
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.

------
mrspeaker
As was pointed out in the comments, fast-paced == lots of unpaid overtime. If
you had good project planners (or project managers who don't start factoring
timelines based on the amount of unpaid overtime they can get you to do) then
you'd be working in a "well-paced environment". Which is a nice place to work.

------
edw519
"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 seem fairly normal to most senior or start-up programmers.
It's all relative.

~~~
Stormbringer
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?

~~~
sid0
While it is simple and trite, how is it profound? All human activity is change
by that definition.

~~~
Stormbringer
Because in IT we somehow have tricked ourselves into thinking that change is
undesirable.

~~~
praptak
Really? I read quite a lot opinions (articles, blog posts, comments) from IT
people and haven't really found anyone expressing such a blanket statement.

Even the complaints about spec changes are seldom about changes per se, but
rather about the impedance mismatch between the changes and an inflexible
process.

------
thenduks
Saying 'fast-paced' usually (in my experience) is a claim that the team
doesn't get hung up and blocked on a bunch of minute details and 'sign-offs'.
In other words - there's no committee.

Even if that isn't the norm, putting so much stock in the copy in a job ad is
probably a waste of time anyway. Just because the ad says 'fast-paced' or
refers to the person they're looking for as a 'ninja' doesn't mean it wouldn't
be an awesome place to work -- from my perspective, quite the opposite, any
text like that makes it feel like it was written by a company without an HR
department (+10!).

~~~
ultrasaurus
I've written a few job ads and I'm sure I've said fast-paced and other filler
words.

I wish I meant "When reality and the plan don't match, we change the plan," in
reality it was "Hmm, this text needs to look longer -- I'll use adjectives!"

------
bioh42_2
I have the great misfortune of working at a big company which has tons and
tons of specs AND frequent spec changes.

Our process is waterfall that refuses to accept the reality that marketing
runs this company and they change their minds a lot.

My point is only that if there was something better I would quit mediately.
But I would rather deal with this at a biotech, then work at the most
wonderful company working on social apps, or advertising apps, or ticketing,
or booking, etc.

Pick your poison kids.

~~~
wladimir
Heh, that sounds very familiar. When I got my job, it was told that the reason
for using a waterfall model was that "the specifications are very clear, and
developers just have to implement them".

Reality is so different... :)

~~~
shade
Sounds like my last job. They had gotten burned a few times by waterfall
projects failing, so their reaction was to try to implement waterfall even
_more_ rigorously.

You had to design and document the entire project up front and then break it
out into individual tasks and estimate them. Two points that I thought were
particularly horrible:

Your estimates immediately became hard deadlines. If you guessed 3 months ago
that gnarfling the garthok would take you 8 hours and you were wrong, it went
against you on your metrics. Even better, if you finished the job in _less_
time than you estimated, they'd complain and tell you that you missed low and
needed to do a more precise job of estimation next time.

I suggested to my boss once that if they insisted on having all this
documentation written (seriously, we were supposed to write up docs on what
the function names were going to be, what the arguments were, and what they'd
do -- _before_ we were allowed to write any code) then we should probably
build some time into the schedule to make sure we could update them based on
what we'd learned during the actual process of writing the code. He told me "I
understand what you're saying, but that's not possible. We need all of the
documentation done up front so that if we're behind schedule, we can add more
people to the project and they can read that documentation to get up to speed
quickly."

I looked at him for a few seconds, stunned speechless, then basically said "In
my experience, that never works." A few weeks later, I was laid off, I suspect
because I wasn't toeing the line and buying into the "new" Lean waterfall
process. Best thing that ever happened to me, in the end.

~~~
wladimir
It's kind of the same here. We first have to write a design document, then get
it reviewed by people all over the organisation. This reviewing _has_ to be
done in a meeting, which is impractical because it is almost impossible to
find a time where everybody is available AND a room is available.

Writing a design document doesn't sound that bad, but the requirements are
completely unclear when you start the project. Usually, the stakeholders don't
even exactly know what they want, so it's very hard to get concrete
requirements. And they change their mind all the time, so if you just scrapped
something, many times you have to add it back later.

Only when it is deemed OK, it is officially allowed to start programming. If
not, back to the drawing board. Worst part is that the opinions differ on how
detailed this design document should be. Some people complain if it is not
detailed enough, others complain if it is too detailed.

When you have the OK, the red tape only starts. You have to mail or run around
asking people to grant change access to their part of the source code. In many
cases, simply referring to the design document for explanation is not enough.
Nope, as they generally had "no time" to go over the document, if you want to
get work done, you should explain everything that you're going to change in
their part.

Even the SCM system that we use is slow. Checkouts take ages, builds take
ages. This way of development really doesn't work for me and many others.
Luckily there is an (unofficial) way to "fork" the code, so that you can start
working and experimenting while writing the design document. Without this,
it'd be almost impossible to get the amount of detail required.

And when you're done coding, you need to write a document with testcases,
which goes through the same review process. When you're done testing, another
document with test results...

In this case, the process works because it is not very rigidly enforced.
Unluckily, some people in management think that code quality will improve if
and only if more checks are put in place. So every half year there are more
checkboxes and process steps.

------
chrisaycock
A manager once told me, "multitasking may be inefficient, but that's what we
do here." Let that admission sink in for a minute.

~~~
JulianMorrison
I'm sorry, I haven't got a minute. Can I let it sink in for 30 seconds, and
get back to you?

~~~
chrisaycock
The manager was admitting to doing something that he knew was inefficient. He
ultimately knew that multitasking was the worst practice, but he chose to do
it anyway.

There's ignorance, and then there's willfully choosing to do wrong.

Edit: This was at an investment bank, in the proprietary trading group. There
are no customers or deadlines. So we (should) only work on something we
believe will make money.

~~~
JulianMorrison
In such a situation I think all tasks should be globally sorted (according to
business-determined weighting) by the metrics:

\- how much do we expect to gain if we do it

\- how much do we expect to lose if we don't

\- how much (black swan worst case) might we lose if we don't

\- how easy is it

and then programmers should just pick off the top of list, updating the tasks
metrics if they subjectively change.

That way there are multiple tasks queued but only one in play, and context
switching happens when a task changes importance.

------
pauldisneyiv
Interesting - it would be helpful to have a definition of "fast-paced". The
phrase is far too vague.

I love working very hard (potentially fast) on a product that I'm making great
headway on. Perhaps I'm in the zone or I know I need to hit a deadline.

That being said if I'm being asked to produce things frantically (also fast
paced) with little to no direction or thought behind it...that's not so hot.

In general job descriptions should be more self aware and try to communicate
the environment more specifically.

~~~
grammaton
> Interesting - it would be helpful to have a definition of "fast-paced". The
> phrase is far too vague.

Welcome to the wonderful world of MBA-speak.

~~~
sixtofour
<http://www.dilbert.com/strips/comic/2009-05-18/>

------
kingofspain
Reminds me of estate agent talk. "Fast-paced, agile, challenging environment"
as a plus point on a job ad usually makes me skip right over. I know people
say you should turn your weaknesses into strengths but I don't think this is
the way!

------
ChuckMcM
Its like the other phrase I dislike "Rockstar programmers". Now my idea of
"rock stars" is that they are temperamental, have low self confidence, and
spend 90% of their time complaining. I've met, and occasionally worked with,
programmers that fit that particular shoe and frankly I wouldn't try to
recruit them.

I am sure the HR/Recruiter is trying to convey a sense of urgency that keeps
you at the top of your game, but I agree with most of the comments that
companies that create their own urgency by not planning is the more common
occurrence.

------
rglover
Fast-paced environment usually describes places that lack an attention to
detail and quality, which above anything else should be the core focus of a
company. A lot of people are suggesting that pace refers to the amount of work
which I don't think is entirely correct. A business could have all the work in
the world and still move at a snail's pace. @mrspeaker made an excellent point
in that the ideal environment would be "well-paced." More often than not,
though, this sort of terminology was probably picked from similar job postings
that the HR person (generalizing, of course) saw elsewhere.

------
grammaton
Fast paced is generally code for "we have the attention spans of fruit flies.
We'll expect you to pick up the slack for our failings."

------
amitraman1
"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

------
acconrad
It's just marketing - on the converse, no one wants to sound slow...it
associates with boredom. Fast-paced signals energy and excitement, but
translates to over-worked and poor balance with the rest of your life.

When I hear this it reminds me of when engineers in interviews say "I work
with the smartest people." Of course you do...who works with the 2nd smartest
people? Who admits to working with average people? I'd like to know how you
distinguish that in an ad/interview.

------
Alex3917
The fact that 'fast-paced' has negative connotations for older/wiser workers
is irrelevant. They're targeting the same sort of 20-year-olds who all wanted
to work for MS in the late 90s because they had free soda. The commenters
criticizing this tactic seem oblivious to the fact that the companies using it
don't want them.

------
snorkel
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.

------
mcritz
I offered my last girlfriend a fast-paced environment. I'm single now.

Ladies.

------
tomkarlo
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.

------
yannickmahe
I moved from an extremely fast-paced environment to a well balanced, well
managed software shop. I regret that choice a lot. While I do have now
work/life balance, sleep longer nights and never do any overtime, I can't help
but feel I'm not even close to the productive levels I had before. I loved
being pushed to my limit, constantly having to come up with new solutions to
new problems, etc.

On the plus side, I now have the time to launch my company which will - I hope
- give me once again the kind of environment in which I can push my own
limits.

~~~
cema
Well I guess in a fast paced environment you are pushed and in a balanced
environment you pace yourself. We are adults not cogs.

~~~
yannickmahe
Less challenge means less of a reason to push yourself in my opinion. I rather
relished the possibility to jump on problems other people left alone.

Perhaps it's more an issue of challenge than pace, pace being a side effect of
the challenge you encounter.

~~~
cema
Or perhaps of a challenge your boss encountered. May be a wrong kind of
challenge, depending on the boss.

------
m3mnoch
"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.

~~~
gaius
Yet if you read a job ad from IBM or HP or Microsoft, they're "fast-paced"
too.

~~~
Lennie
And there is the problem.

The phrase 'job ad' has the word 'ad' in it and thus anything which is
mentioned in the ad was probably (re)written by marketing and thus isn't true
to begin with. ;-)

------
mgrouchy
I work in what I would call a fast-paced environment.

What I always took fast-paced to mean is that, as a startup who is trying to
build a business we are constantly evolving our goals to develop the best
product possible. This means making smart but quick decisions based on
actionable data.

Whether that means adding new features, dropping ones that don't work, etc.
thats what we are going to do.

------
nphase
Interesting. When I think of fast paced environment, I think of a driven
environment with lots of youthful energy that moves quickly.

Shameless self-promotion: My Chicago Startup Tap Me, (<http://tap.me>) is
hiring. If this kind of work environment sounds appealing to you, my email
address is in my HN profile.

------
kalendae
trying to predict how the company is based on the job listing is on the same
order of magnitude of effectiveness as trying to predict how good the
candidate is based on the resume. There's probably just some rough correlation
on a large scale. I used to have a lot of notions from reading various blog
posts but too often they prove to be totally wrong in specific instances. One
of my worst experiences ever was going after a clever puzzle online leading to
arduous days of coding and grilling and more puzzles (invested so much time)
only to get a sub-par offer and lots of 'hard negotiating' which i always
avoid. fact is words like fast-paced, multitasking, excellent communications,
team player, rockstar, a player, self motivated blah blah blah, I simply
ignore. I imagine the same goes on in the other direction, so I no longer put
them on my resume.

------
mildweed
I want to be a Greybeard UNIX monk some day.

------
Florin_Andrei
Depends.

I'm an adrenalin junkie, so if I'm passionate about something, it better be
fast-paced, or else I get bored.

But if it's boring already? Then yeah, everyone please chill.

------
sabat
I've always assumed that "fast-paced" meant that you weren't going to
encounter a company moving at corporate-speed -- you know, where a project
takes 6-12 months (min.) of meetings, tiger teams, blue ribbon panels, design
by committee, political posturing, ad nauseum.

