You suddenly find yourself working 50-60 hour weeks, put on call with no compensation, given unreasonable amounts of work...
So why did you let that happen to you? Why didn't you say "no"?
I'm curious...how old are you? I used to feel the same way about a particular job. Then I got older and realized it was just a job, and if I didn't like it, I should find a new one.
Isn't there some sort of moderation like -1 (Has a Rush quote in sig)
Re:Do we really WANT our sims to get old and die?
on
The Sims 2 Announced
·
· Score: 1
Do we really want to take the time and energy to make Sailor Moon in The Sims and then have her get old and fat and sit around complaining about taxes until she croaks, then we get her mutant pink haired offspring running around?
If you have lot's of time, create a slightly different resume for each company based on your research and your estimate of their "atmosphere" or "corporate culture" or "Feng Shui energy displacement patterns" (that's as good as anything else, I guess).
I would think that everybody would do this, if they're actually trying to get a job.
If you're talking about the native compilation aspect of gcj, there's a goodly number of things that won't work when compiled with gcj. Most notable is Swing.
If you're talking about the bytecode compilation aspect of gcj, then you still need a JVM to run those bytecodes in.
Um... You just said I'd have to be a moron to choose the company of developers who can cooperate. Heh heh heh!
Damnit...I knew I'd fuck up that grammatical construction.
I guess my biggest problem is that those who reject XP are usually those who've never tried it, and dismiss it with straw-man arguments. Especially here on/., when its something I do know something about, and few other people in this thread seem to.
For me, its the software development methodology that makes sense to me. And for those people it doesn't seem to make sense for...well..they're some kind of weird freak. =)
Really though...all else being equal, is it better to have a company full of developers who can cooperate, or a company full of developers who can't? You've got to be a goddamn moron to pick the former.
As for the design part of things...this is just my experience successfully using XP for real business software development: Do you need design? Yes. Do you formal design? No. Do you need to design everything ahead of time? Absolutely not. XP came about in part because enough people found that BigDesignUpFront just doesn't work well enough.
As for my tone...this is some of the nicer stuff I post on Slashdot. Karma to burn.
I think that my point was that whenever programmers have to collaborate on a single stretch of code, they will inevitably disagree on implementation details and algorithms, and that this will lead to unproductive debate that will bog down a project.
I guess I'm glad I don't work with people like this. To me, those people suck at life, or at least, suck at what I think is an essential part of their job.
Split-the-functionality-up-into-modules-with-defin ed-interfaces sounds nice, but I've never found it to work in practice. Maybe my co-workers and I suck at our job (I don't think we do). But in my experience with software development, design of that sort that is specified ahead of time will change sufficiently enough that it's not worth putting together in the first place. Collective code ownership and evolving design allow those changes to easily happen.
How do you figure out what the interface between your modules should be. Nearly all of the time, you're not going to find the correct interface until you're nearly done with the modules. Along the way, you're going to have to do something awful like:
Compromise with him on every interface issue on which you differ, taking time, and resulting in a mediocre interface,
Argue over interface design philosophy, taking up additional time.
Have shouting matches over what the interface contract should be, taking up even more time, and annoying others.
To be honest, if this is how you work with your other programmers, one or both of you should be fired. No methodology is going to save you.
One of the ideas behind XP is that the process you've described really doesn't work that well. Requirements can and will change. Design usually cannot be properly understood until you're in the middle of the implementation. XP takes those things into account.
No, you're not the only one. Was also available for the Apple ][.
nt
Sometimes I doubt your commitment to Sparkle Motion!
Its not a troll when its true.
I was wondering why the article sucked so much, then I saw it was posted by Cliff.
i said nt
If you don't plan on playing sports, you can live pretty normally without an ACL.
I'm sure my priorities will be different once I have kids. Yikes!
Isn't there some sort of moderation like -1 (Has a Rush quote in sig)
Do we really want to take the time and energy to make Sailor Moon in The Sims and then have her get old and fat and sit around complaining about taxes until she croaks, then we get her mutant pink haired offspring running around?
Yes yes yes.My hard drive is already filled with protein, but that has more to do with muzzle velocity than it does with any sort of research or experimentation.
Money has this magical way of making obstacles disappear.
Perforce is free-as-in-beer for the development of software that is licensed exclusively under an Open Source license.
http://www.perforce.com/perforce/price.html
I would think that everybody would do this, if they're actually trying to get a job.
I'm assuming Jetty is also written in Java. So you'd have to get Jetty to compile w/ gcj as well.
Under windows, I imagine you could do all that from within Cygwin.
If you're talking about the native compilation aspect of gcj, there's a goodly number of things that won't work when compiled with gcj. Most notable is Swing.
If you're talking about the bytecode compilation aspect of gcj, then you still need a JVM to run those bytecodes in.
MarathonMan Brought to you by your good friends at ThoughtWorks.
Someone who reads Tolkein once a year should know how to spell the names of major characters.
Then why did you butcher the names?
Gollum -> Golem
Gimli -> Ghimli
Saruman -> Sauroman
Eowyn -> Aowen
Chump. I even cut you slack on owyn. (why is /. chewing up the É?)
Um... You just said I'd have to be a moron to choose the company of developers who can cooperate. Heh heh heh!
Damnit...I knew I'd fuck up that grammatical construction.
I guess my biggest problem is that those who reject XP are usually those who've never tried it, and dismiss it with straw-man arguments. Especially here on /., when its something I do know something about, and few other people in this thread seem to.
For me, its the software development methodology that makes sense to me. And for those people it doesn't seem to make sense for...well..they're some kind of weird freak. =)
Really though...all else being equal, is it better to have a company full of developers who can cooperate, or a company full of developers who can't? You've got to be a goddamn moron to pick the former.
As for the design part of things...this is just my experience successfully using XP for real business software development: Do you need design? Yes. Do you formal design? No. Do you need to design everything ahead of time? Absolutely not. XP came about in part because enough people found that BigDesignUpFront just doesn't work well enough.
As for my tone...this is some of the nicer stuff I post on Slashdot. Karma to burn.
I guess I'm glad I don't work with people like this. To me, those people suck at life, or at least, suck at what I think is an essential part of their job.
Split-the-functionality-up-into-modules-with-defin ed-interfaces sounds nice, but I've never found it to work in practice. Maybe my co-workers and I suck at our job (I don't think we do). But in my experience with software development, design of that sort that is specified ahead of time will change sufficiently enough that it's not worth putting together in the first place. Collective code ownership and evolving design allow those changes to easily happen.
How do you figure out what the interface between your modules should be. Nearly all of the time, you're not going to find the correct interface until you're nearly done with the modules. Along the way, you're going to have to do something awful like:
To be honest, if this is how you work with your other programmers, one or both of you should be fired. No methodology is going to save you.
One of the ideas behind XP is that the process you've described really doesn't work that well. Requirements can and will change. Design usually cannot be properly understood until you're in the middle of the implementation. XP takes those things into account.