21–30 of 70 posts
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.
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.
But the opposite is true, too.
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.
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.
Earlier quoted context omitted.
I'm sorry, I haven't got a minute. Can I let it sink in for 30 seconds, and get back to you?
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.
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 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 s…
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... :)
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.
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.