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…
But nobody wants a “fast-paced environment”
61–70 of 70 posts
Re: But nobody wants a “fast-paced environment”
#62"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…
Re: But nobody wants a “fast-paced environment”
#63Earlier 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…
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”
#64There 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.
Re: But nobody wants a “fast-paced environment”
#65Earlier 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…
I'm adding that to my collection of oxymorons. "lean waterfall" process. awesome!
Re: But nobody wants a “fast-paced environment”
#66Earlier 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.
Re: But nobody wants a “fast-paced environment”
#67Earlier 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.
Re: But nobody wants a “fast-paced environment”
#68Earlier 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.
Re: But nobody wants a “fast-paced environment”
#69Earlier 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…
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"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.
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. ;-)