Live data from Hacker News

But nobody wants a “fast-paced environment”

programmers.stackexchange.com

61–70 of 70 posts

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

#61
post #55

Earlier quoted context omitted.

We've managed to setup our own database servers 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 lis…

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.

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

#62
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…

I thought the agile guys were all about refactoring, which is not building anything, adding anything, or fixing anything.

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

#63
post #55

Earlier quoted context omitted.

We've managed to setup our own database servers 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 lis…

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.

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

#64

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.

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.

In job interviews, never mention actual or imaginary pathology in an actual or imaginary workplace. It almost always works against you.

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

#65
post #28

Earlier quoted context omitted.

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... :)

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 t…

> Lean waterfall process

I'm adding that to my collection of oxymorons. "lean waterfall" process. awesome!

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

#66
post #40

Earlier quoted context omitted.

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

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

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.

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

#67
post #46

Earlier quoted context omitted.

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

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.

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

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

#68
post #62

Earlier quoted context omitted.

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…

I thought the agile guys were all about refactoring, which is not building anything, adding anything, or fixing anything.

Refactoring is still change

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

#69
post #28

Earlier quoted context omitted.

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... :)

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 t…

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.

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

#70
post #56
post #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.…

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

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. ;-)

Post reply on HN