Yeesh! That one reads more like a cautionary tale in not having a backup plan, and not having a backup plan for your backup plan.
A question to ask yourself when dealing with something like this: "Could a software problem ever cause a catastrophic overflow?" If the answer is "yes," then you'd better make sure you've got a double contingency for dealing with it--an overflow spillway leading to the original reservoir (which this one lacked), and mechanical failsafes so the pumps will stop working if the water gets above a certain level. What happened doesn't sound like any kind of failure in this method of energy storage, but an utterly reckless approach to safety.
Pumping water uphill is a surprisingly effective energy storage technique. This isn't practical for most people's houses, but on a large scale it works very well.
Welcome to the rest of the software industry. Guess what "junior" developers are hired to do? They get stuck with the crap no one else wants to bother with, and once they prove themselves, they get to move up the food chain (either within the company, or having gained enough experience to bail for a better job.)
I'd like to bump your comment just for pointing out that quantitative statistics on a resume are a great idea! I've seen too many resumes where it's unclear exactly what someone did. "Maintained application X." Well, great. That sure tells me a lot. "Inherited application X from retiring developer; documented legacy codebase of over 3 million lines; improved performance 40%" tells me a LOT more about what someone did. (Yes, they could very well be lying, but a resume full of this stuff indicates either a true bullshit artist or someone who knows what they're doing, and I can figure out which is which when I'm interviewing you.)
I'd also point out that the accomplishment statements on your resume are the least verifiable pieces of information in the whole document, so don't be afraid to toot your own horn. I think software developers are more likely to downplay their individual contributions, but in a resume you really need to talk yourself up, since it's basically a sales pitch to prospective employers.
The "why" is definitely important if you have code that needs to be maintained over a long period of time and by more than one person. Yes, anyone can read the code and figure out what it does, but without any indication as to why, future maintainers are likely to break it. Or, say you do things a certain way because of a known compiler bug--once that bug is fixed (maybe years down the road), someone else can pick up on that and change the code, since your comment indicated it was only done this way to avoid a compiler bug (trivial example.)
Documentation explaining what the code is doing can be helpful if, in the course of reading it, you realize it doesn't actually do what the documentation says.:) Again, though, this goes back to what the original programmer intended and why, something you can never divine from code alone.
The current philosophy in game design appears to be, "Will it make for a flashy demo??" Gameplay is secondary to how pretty the game is. And it's hard to blame the game devs for this--the game-playing public has demanded better and better graphics, and continues to accept crappy gameplay.
When developing a AAA title, you can't have everything. You have to bump something in order to make launch date. And since no one wants to cut graphics or multiplayer functionality, what gets the shaft? Single-player gameplay and overall complexity. Make the game itself simpler, so you have fewer graphics to produce, less code to write, and less to test.
It's also crazy because these days, hardly anyone has to write engines anymore. There are so many out there--pick one! A lot of the hard work has already been done for you!
I'd much rather play a game with so-so graphics and awesome gameplay (and replayability) than something super flashy that I can beat in 8 hours and never touch again. Unfortunately, that's not the trend.
Yeah, I don't want to give Elite short shrift, but admittedly I didn't play it as much.
I wish the Battlecruiser/Universal Combat games had ever lived up to their potential. One thing they always lacked was that "living universe" feel you got from the Starflight games. What good are fully-rendered planets when there's nothing interesting on them?
Plus, you couldn't communicate with other ships, the vast majority of the time. Lame.
The Starflight games are brilliant and I would argue they have yet to be surpassed in the "open universe exploration" department. What other game gives you a galaxy with over 100 star systems to explore, and you can land on just about every planet, go mining, and trade with the locals? You also had to have some intelligence because the game didn't stop you from doing stupid things. If you ignored your science office when he pointed out that the gravity on this planet is 20x normal, enjoy the crushing death when you try to achieve planetfall.:)
Combat was also really difficult. Your ship is little better than a pea shooter when you start out, and most of the time you have to talk your way out of trouble (which means having a good comms officer is essential, otherwise you won't understand a damn thing the aliens are saying.)
God, I loved those games. A modern remake would be great, but that whole genre seems to be pretty much dead.
Seriously. Most of the NES games I had were hard as all hell, and even today they present a fair amount of difficulty for me, whereas I could pick up most new games and breeze through them.
The original TMNT game stands out as one of the most frustrating gaming experiences of my entire life.
Yeah, "mistake," my ass. This is fraud and possibly dereliction. Who knew it was that damn difficult to run a test and write down the results? It's only people's freedom, driving privileges, and not-inconsequential sums of money involved.
This is true, but it's not that employers aren't allowed to know about it, they just aren't allowed to directly ask. I have no idea if, legally, asking to access your Facebook profile amounts to the same thing. I suspect this has not been tested in court.
I'm not "close" to all of them but for each and every one I could tell you exactly how I know them, for how long, and at least a few things I know about them.
I went down the list and I'd say I'm "close" to 52 of them, and "very close" to about a dozen.
Slashdot Mirror
Why go to all that trouble when you've already got gravity to do the work for you?
Yeesh! That one reads more like a cautionary tale in not having a backup plan, and not having a backup plan for your backup plan.
A question to ask yourself when dealing with something like this: "Could a software problem ever cause a catastrophic overflow?" If the answer is "yes," then you'd better make sure you've got a double contingency for dealing with it--an overflow spillway leading to the original reservoir (which this one lacked), and mechanical failsafes so the pumps will stop working if the water gets above a certain level. What happened doesn't sound like any kind of failure in this method of energy storage, but an utterly reckless approach to safety.
Pumping water uphill is a surprisingly effective energy storage technique. This isn't practical for most people's houses, but on a large scale it works very well.
That's hardly just Georgia.
I commit frequently. I'm a bit perturbed by people who don't.
(Of course, I use git, so I can do local commits as often as I want, and only push when I'm confident what I'm sharing isn't a broken mess.)
Welcome to the rest of the software industry. Guess what "junior" developers are hired to do? They get stuck with the crap no one else wants to bother with, and once they prove themselves, they get to move up the food chain (either within the company, or having gained enough experience to bail for a better job.)
I'd like to bump your comment just for pointing out that quantitative statistics on a resume are a great idea! I've seen too many resumes where it's unclear exactly what someone did. "Maintained application X." Well, great. That sure tells me a lot. "Inherited application X from retiring developer; documented legacy codebase of over 3 million lines; improved performance 40%" tells me a LOT more about what someone did. (Yes, they could very well be lying, but a resume full of this stuff indicates either a true bullshit artist or someone who knows what they're doing, and I can figure out which is which when I'm interviewing you.)
I'd also point out that the accomplishment statements on your resume are the least verifiable pieces of information in the whole document, so don't be afraid to toot your own horn. I think software developers are more likely to downplay their individual contributions, but in a resume you really need to talk yourself up, since it's basically a sales pitch to prospective employers.
The "why" is definitely important if you have code that needs to be maintained over a long period of time and by more than one person. Yes, anyone can read the code and figure out what it does, but without any indication as to why, future maintainers are likely to break it. Or, say you do things a certain way because of a known compiler bug--once that bug is fixed (maybe years down the road), someone else can pick up on that and change the code, since your comment indicated it was only done this way to avoid a compiler bug (trivial example.)
Documentation explaining what the code is doing can be helpful if, in the course of reading it, you realize it doesn't actually do what the documentation says. :) Again, though, this goes back to what the original programmer intended and why, something you can never divine from code alone.
As much as I loved the QFG games, they were more adventure game than RPG.
Those weren't RPGs.
The current philosophy in game design appears to be, "Will it make for a flashy demo??" Gameplay is secondary to how pretty the game is. And it's hard to blame the game devs for this--the game-playing public has demanded better and better graphics, and continues to accept crappy gameplay.
When developing a AAA title, you can't have everything. You have to bump something in order to make launch date. And since no one wants to cut graphics or multiplayer functionality, what gets the shaft? Single-player gameplay and overall complexity. Make the game itself simpler, so you have fewer graphics to produce, less code to write, and less to test.
It's also crazy because these days, hardly anyone has to write engines anymore. There are so many out there--pick one! A lot of the hard work has already been done for you!
I'd much rather play a game with so-so graphics and awesome gameplay (and replayability) than something super flashy that I can beat in 8 hours and never touch again. Unfortunately, that's not the trend.
Let's eat grandma!
Yeah, I don't want to give Elite short shrift, but admittedly I didn't play it as much.
I wish the Battlecruiser/Universal Combat games had ever lived up to their potential. One thing they always lacked was that "living universe" feel you got from the Starflight games. What good are fully-rendered planets when there's nothing interesting on them?
Plus, you couldn't communicate with other ships, the vast majority of the time. Lame.
(Countdown to Derek Smart flames in 3, 2, 1...)
The Starflight games are brilliant and I would argue they have yet to be surpassed in the "open universe exploration" department. What other game gives you a galaxy with over 100 star systems to explore, and you can land on just about every planet, go mining, and trade with the locals? You also had to have some intelligence because the game didn't stop you from doing stupid things. If you ignored your science office when he pointed out that the gravity on this planet is 20x normal, enjoy the crushing death when you try to achieve planetfall. :)
Combat was also really difficult. Your ship is little better than a pea shooter when you start out, and most of the time you have to talk your way out of trouble (which means having a good comms officer is essential, otherwise you won't understand a damn thing the aliens are saying.)
God, I loved those games. A modern remake would be great, but that whole genre seems to be pretty much dead.
Seriously. Most of the NES games I had were hard as all hell, and even today they present a fair amount of difficulty for me, whereas I could pick up most new games and breeze through them.
The original TMNT game stands out as one of the most frustrating gaming experiences of my entire life.
I assume you mean QFG2? Yes, it was remade: http://www.agdinteractive.com/games/qfg2/homepage/homepage.html
I'm a pretty crappy gamer and I agree, the Megaman games weren't that hard. I beat the first three without really putting much effort into it.
The cheat code only gives you something like 40 lives, not infinite. (I still have this game and play it, but yeah, never once beat it...)
Fester's Quest is also notorious for being incredibly difficult to beat. (Incidentally, same engine as Blaster Master.)
Yeah, "mistake," my ass. This is fraud and possibly dereliction. Who knew it was that damn difficult to run a test and write down the results? It's only people's freedom, driving privileges, and not-inconsequential sums of money involved.
This is true, but it's not that employers aren't allowed to know about it, they just aren't allowed to directly ask. I have no idea if, legally, asking to access your Facebook profile amounts to the same thing. I suspect this has not been tested in court.
I'm well aware of that, that's why I said "employers should be forbidden", acknowledging that they currently aren't.
That's the joke. </Wolfcastle>
I'm not "close" to all of them but for each and every one I could tell you exactly how I know them, for how long, and at least a few things I know about them.
I went down the list and I'd say I'm "close" to 52 of them, and "very close" to about a dozen.
Fortunately, I am not that kind of schmuck. ;) But many people are, and realistically, most people always will be.