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.
This. Hurry up and wait. That's exactly how it worked for me when I worked for a large company. Need to make a database change? Be prepared to wait 3 weeks unless you can get someone several levels above you on the org chart to take notice. Same for any kind of additional access you might need, or to provision any amount of computing or network resources...
One company I worked for had the same problem - because the (Oracle) database was also linked to their payment system and because they were a big company, the simplest change would require 2 or 3 weeks of approvals (by law, not really their fault).
And you know what my department did?
We've managed to setup our own database servers, so changes became independent of any payment system and could be done on the spot.
I know things suck in corporations, but sometimes it's your fault for not doing anything about it.
Heh, I work in IT and have some users like that. They're pretty smug until they realize it takes us a while to set up any infrastructure because we do little things like, umm, backups, which they don't have, and now suddenly really, really need... Oops.
This isn't about devs versus ops. It's about bureaucracy versus getting shit done. If it takes 3 weeks to ensure reliable infrastructure and backup, I wouldn't complain.
All I was saying is that if you have to wait 3 weeks for the simplest schema change request (which I saw it happens in big corporations), then you should take charge and workaround it before throwing your hands in the air ... sometimes management listens.
This is fine as long as you actually understand what it is you're working around, why it's there, and what the consequences are of working around it. What looks like bureaucracy to a technologist may well be there for a very good business reason.
Sometimes there's a tree across the road simply because a tree fell across the road. But other times there's a tree across the road to keep you from plummeting into the ravine where the washed-out bridge used to be.
Oh yeah, if it's broken, fix it, I don't meant tech but organisationally. Just pointing out that there's often more work that goes into databases than endusers see.
At every job I've ever had, in the interview I have mentioned that I'd rather have 10 hours of work to squeeze into an 8 hour day than have 2 hours of work to expand into an 8 hour day. Thus far, nobody has taken me seriously.
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.
Especially when your employer watches your every move every second you're in their building. Cameras, remote desktops on every PC, services that track what files you open and when, keyloggers, et cetera. Not having enough work in such a paranoid environment where you get griped at for doing anything outside of your responsibilities or for not being in the building exactly eight hours a day can be a living hell.
I'm in a situation like that currently, but in an open plan office, with a manager sitting behind me keeping me in line.
And since our bug tracker is linked to timesheets, things like refactoring don't happen anymore, unless linked to a specific feature/bug (developers can't create these). The nett effect is that things that used to take me 2 hours now take 8 hours, so I can fill the day. Parkinson's law is not a joke.
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.
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.
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.
"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.
I don't know about that. Consider someone working in a sandwich shop. Once you learn how to make the different sandwiches, you just keep making the sandwiches every day. Or a job as a taster at a distillery. You make sure the whiskey doesn't vary in taste. While it may be an enjoyable activity, there's only occasionally something new.
Whereas with coding virtually everything is something new. In coding if you run into the same thing over and over again, you use a reusable component or automate it. You build the equivalent of a sandwich-making machine or whiskey-tasting machine and move on to the next thing.
"In coding if you run into the same thing over and over again, you use a reusable component or automate it."
You and I both know this to be true, but there are wide swaths of development jobs that cater to the C players they've hired and don't allow this sort of automation. Frameworks, more powerful languages and tools, even techniques like recursion aren't allowed because "not everyone would understand them." There's plenty of reasons to not like Rails, or Ruby for that matter, but "because Joe Blub three cubes over might not get it" is one of the worst ones you could give.
That sort of environment sucks, and everyone on here is right to say "if you're in that sort of place, then quit!". That said, it does exist in wide enough circulation that it's hard to sweep it under the rug when talking about the industry as a whole.
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.
Only unexpected change is undesirable. The reason that all change is met with the same hostility is due to the processes set up to document the changes that are wanted.
You know what fast-paced is - ideas thrown at you that invalidate your previous architecture once every 2 weeks. And I don't know how you can get any more fast-paced than that.
If I hadn't enough experience to make the architecture flexible enough or to do unit-tests or to choose the right moment to start from scratch, I would probably go mad.
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!).
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!"
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.
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".
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.
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.
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.
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.
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!
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.
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.
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
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.
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.
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.
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.
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.
"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.
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. ;-)
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.
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.
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.
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.
