There is at least 2 big problems:
1) He went outside the scope of his employment contract for outsourcing when he was hired as programmer
2) He gave keys to company network to some other unauthorized persons
> Of course it causes all these things. If you're refusing to modify existing code, then you can't refactor it to handle extra cases
This is already covered by the rules. What you're describing is part of the "intersection" of old code and new code. Avoiding those changes as far as possible is the correct route (but the new code still needs to be integrated to the system so that it's executed as part of the program's execution). But writing independent module first, and then integrating it carefully to the system is the correct route. Just need to be more careful with the intersection, since all those modifications are dangerous.
1. naah, it causes no such things. 2. It's not about bug fixes. That is handled by not writing broken code in the first place. If you need to write same thing twice, you're wasting time the first time you wrote it. You should review your code policies if you have large number of bugs to fix. 3. information lost = noone bothers to rewind the version control history to find the exact version of the software that actually works. It needs to work every day and every week for years. It's not enough that half the versions are working and the rest need to be reconstructed from version control histories. Everything in version control must work. Deleting code is dangerous because you cannot track all dependencies from the deleted code to the whole system.
1) Adding new code is always ok. Just need to keep it independent of the old code. Avoid modifying intersection of old code and new code. 2) Modifying code is dangerous. It can break features anywhere in the system. 3) Deleting code is extreamly dangerous. It can both break code, and lose information what was original code version.
No amount of version control hacks is changing these rules.
Here's reasons why I don't like this topic:
1) There is no bad code. Every programmer has written the best code they can write. If you have trouble reading it, buy some better glasses.
2) Complex code is not bad code. The programmer you're trying complain about is smarter than you think. He saw some complex problem in your software architecture and his complex code fixed it. You still can't even see the problem, much less the solution. It works, and any complaining about the details is useless.
3) Reading someone elses code is always difficult. about 90% of programmers think they write better code than others simply because reading ideas from other programmers is difficult. This accounts large portion of "bad code" out there. You need to find better criteria for labeling someone elses code bad. How about check test cases that fail... Oh wait, where's our test cases?
I'm pretty sure their huge device is just not accurate enough. Two separate measurements can give different results based on how they configured the device. And if one of them gives photons and the other some Z's, then it's clear the difference is based on different devices measuring it. I'm surpriced their measurement result fits to same page in the graph... few GeV/c difference is so small we can confidently say higgs exists...
Since I didn't see their data, I can only guess what could be the problem. They're detecting both neutrinos and light some way. My bet is that their detector for light have some additional delay making the light detection wrong. They probably didn't spend millions on the light detection system since they were planning to detect neutrinos only. Probably cheap parts are causing this problem.
" it's killing pretty much everything it makes and just repackaging stuff made by another company."
If it's so easy that just repackaging someone elses work, why wouldn't microsoft do it themselves? There would be no reason for microsoft to play this game, if your theory is correct.
While your answer was mostly ok, the last paragraph ruined it. There are no people who are not confident programmers, because everyone is trying their best. Everyone is different. For some people or teams code reviews are useful. But sometimes it just doesnt work. This is not because the developer was inexperienced or not very good, but instead because code reviews just are not suitable for everyone. Big mistake is trying to forcefeed your own conventions and practises to other people. Not everyone needs code reviews. Or there are other problems. Assign the problems to the responsibility of the process. Never blame other people. People are not idiots, Programmers especially. Everyone is still trying their best.
good companies will have 15 different positions open and their interview just jumps from one position to another every time the person makes a mistake. If they have only one position open, then they are very tight on money, and the position will not last too long.
Stump the candidate obviously tests how fast they are. If the company have tight deadlines, they obviously need people who are very quick solving these problems. If you failed on of these tests, they were looking for more experienced people for the position and you were not a good match for it. It's better to find something else. Slow and inexperienced people in these positions can cause large amount of damage.
Of course I bet the company will have lots of difficulty finding anyone suitable for the position, but at least they're trying to fill it.
This whole story is based on someones assumption that their coworkers are idiots. Anyone who thinks like that ought to work alone, far away from other people. And what this guy does: spreads the idea to everyone via slashdot. Now everyone who reads it needs to work alone. How is this helping with building nice working teams where people actually respect the choices other people have made in their life?
I think it's other way around. Science is actually very interesting and there are people who would do it even if they couldn't get any money for it. The reason why pay is bad, and job security even worse, is that those people would do it anyway. It's just so interesting that they have to use very efficient ways of discouraging people to do it to regognize who have lost their faith in the science they're doing. Once that happens, it's known that it'll lead to nothing and the people should be doing something else. This is why job security and pay in science is very bad. Those are the only way to regognize which research is actually going to be valuable. Ask the scientists themselves. If they jump to do something else, they're no longer believing their research is going to be useful.
Guess you missed the announcement where they demonstrated working cold fusion month ago? Fusion doesnt have to be very efficient. E=mc^2 takes care of that. c is very big number. Even very small or slow reaction will produce enough energy that you can do useful stuff with it.
From the article and the details they're giving, it doesn't sound very good way to produce fuel. First the sunlight has very low efficiency. And if you're splitting water, you won't get any more energy out than what you could utilize from the sun's energy. And everyone who has spent any time outside during summer knows that the amount of energy that hits the earth can warm it slightly, but it hardly has enough energy to move your car. This means that we'd need to cover very large amount of earth's surface with these panels until you can drive significant number of cars with this fuel.
The reason why oil can move your car is because it took a million years for plants to store energy which was then converted to oil. It's not very good if you need to wait million years before you can drive half a mile with your car. With this tech that splits water, you'd actually keep the panels working for thousands of years before you can get enough fuel....
Once we run out of oil, we will have big problems. Hopefully by that time, they can get cold fusion to work reliably and make it run our cars.
> there's less crackers where there are enforced laws against computer crime though.
It doesn't work like that. Mostly enforcing those laws just causes backlash. Mostly those crackers are just young people who have not yet figured out what is the alternative to the cracking and they just follow what everyone else is doing around them. Different people find different ways to handle the situation; for some it's creating some software on their own, and others will find they want to create graphics... I see this stage just a mechanism for making young people choose what they want to do in the future. The only way to get them choose it themselves is to put them in situation where they need to change the status quo. But it needs a mechanism which detects if the people can actually make their own decisions, instead of just following what others are doing.
Lets see how it works. Opengl has 4 different ways to use the apis: 1) immediate mode, 2) display lists 3) vertex arrays 4) vbo's.
It is recommended to use vbo's in all code because it's the fastest. What they forgot to say is that you need to learn display lists and vertex arrays before trying with vbo's. If it takes half year to explore how each different way of using the api works, it takes 2 years before you can get vbo's to work. This effort is trivial if you're a company with 30 developers, but it's very big problem if you're a hobbyist with limited amount of time to use for it. In 2 years, with the old tech using sprites etc it was possible to create the whole game in that time. With opengl, all you can do is just learn the api in that time. How is that an improvement? Of course if you _already_ know the api, it's easy to choose the correct way to do it, but most hobbyist game developers only have time to explore the possibilities of one or two of the alternatives. Each of them have different restrictions. It's just impossible to know the restrictions before you actually try it yourself. And trying it takes long time. And end result after choosing wrong api is that you don't get frame rates working at all. Your game is useless.
Oh and each of them works different way. Once you learn one way of doing it, and it fails to work, all your previous knowledge of the api is useless. Just waste of time. And time is what hobbyist game developers do not have. Not enough to play with the api _and_ design your game.
But sure, there are people who invested 10 years of their life for one technology, and they can get some games done with opengl. Or maybe they have a team or company. Either way, it's not getting easier to write these games. Why are people using tech that makes it more difficult to write games?
Not only that but directX and opengl are actually making writing games considerably more difficult. The problem is that they both enforce some arbitrary rules in their api's, while game developers would want freedom to do anything the hardware is capable of doing. Writing what developer wanted was easy when you could directly access the screen pixels. Now that is not possible and developers need to do hacks to get the same thing. The problem is these arbitrary restrictions that the api's are enforcing.
The fact is that neither opengl nor directx is designed for the game developers. They're designed to make game development so difficult that hobbyists cannot do it! So that the playing field is completely reserved for companies.
But the green stuff is the wrong answer. They just want to push us back to 1700s where everything was transported with horses.:)
We should be looking forward into new great stuff and not going backwards in time.
The real problem with energy is that there just isn't that much of it available after 2 billion years of trying matter configurations randomly. Any configuration of matter that could release some energy has already been tried, and it already released all the energy 100000 years ago. So not much is left. It takes technological advancement to find those configurations that have not been tried yet. Energy stuff is fighting billions of years of evolution. It's not easy task. We need to use all possible ways we can find to solve the problems. Including nuclear. Especially nuclear because of E=mc^2. c is very big number. Solar energy is no better than nuclear. (the only difference between solar and nuclear is that the reaction happens few millions of km's away in the sun). Cold fusion folks seem to be already building working reactors. But it has problems with reproducibility. They don't know how it works. So it could stop working when you get small changes in temperature and there is nothing they could do to restore it. The green stuff is considerably worse. The green stuff doesn't even have a chance. The energy balance equation just doesnt work for them.
Slashdot Mirror
There is at least 2 big problems:
1) He went outside the scope of his employment contract for outsourcing when he was hired as programmer
2) He gave keys to company network to some other unauthorized persons
> Of course it causes all these things. If you're refusing to modify existing code, then you can't refactor it to handle extra cases
This is already covered by the rules. What you're describing is part of the "intersection" of old code and new code. Avoiding those changes as far as possible is the correct route (but the new code still needs to be integrated to the system so that it's executed as part of the program's execution). But writing independent module first, and then integrating it carefully to the system is the correct route. Just need to be more careful with the intersection, since all those modifications are dangerous.
1. naah, it causes no such things.
2. It's not about bug fixes. That is handled by not writing broken code in the first place. If you need to write same thing twice, you're wasting time the first time you wrote it. You should review your code policies if you have large number of bugs to fix.
3. information lost = noone bothers to rewind the version control history to find the exact version of the software that actually works. It needs to work every day and every week for years. It's not enough that half the versions are working and the rest need to be reconstructed from version control histories. Everything in version control must work. Deleting code is dangerous because you cannot track all dependencies from the deleted code to the whole system.
It's more like breaking already tested code is wasting too much time...
1) Adding new code is always ok. Just need to keep it independent of the old code. Avoid modifying intersection of old code and new code.
2) Modifying code is dangerous. It can break features anywhere in the system.
3) Deleting code is extreamly dangerous. It can both break code, and lose information what was original code version.
No amount of version control hacks is changing these rules.
Here's reasons why I don't like this topic:
1) There is no bad code. Every programmer has written the best code they can write. If you have trouble reading it, buy some better glasses.
2) Complex code is not bad code. The programmer you're trying complain about is smarter than you think. He saw some complex problem in your software architecture and his complex code fixed it. You still can't even see the problem, much less the solution. It works, and any complaining about the details is useless.
3) Reading someone elses code is always difficult. about 90% of programmers think they write better code than others simply because reading ideas from other programmers is difficult. This accounts large portion of "bad code" out there. You need to find better criteria for labeling someone elses code bad. How about check test cases that fail... Oh wait, where's our test cases?
> Of course! This would surely not have occurred to the particle physicists who built and operate
> the machine and published these results.
Well, it always sounds like if they make the same mistake twice, then it's already better to publish it...
I'm pretty sure their huge device is just not accurate enough. Two separate measurements can give different results based on how they configured the device. And if one of them gives photons and the other some Z's, then it's clear the difference is based on different devices measuring it. I'm surpriced their measurement result fits to same page in the graph... few GeV/c difference is so small we can confidently say higgs exists...
I bet they get 99.9999% reliability for their electricity... Sounds just like what the data center needs.
Since I didn't see their data, I can only guess what could be the problem. They're detecting both neutrinos and light some way. My bet is that their detector for light have some additional delay making the light detection wrong. They probably didn't spend millions on the light detection system since they were planning to detect neutrinos only. Probably cheap parts are causing this problem.
If you only consider that they can get it from only the few individuals who did lose in the lottery, it sounds much more reasonable.
" it's killing pretty much everything it makes and just repackaging stuff made by another company."
If it's so easy that just repackaging someone elses work, why wouldn't microsoft do it themselves? There would be no reason for microsoft to play this game, if your theory is correct.
While your answer was mostly ok, the last paragraph ruined it. There are no people who are not confident programmers, because everyone is trying their best. Everyone is different. For some people or teams code reviews are useful. But sometimes it just doesnt work. This is not because the developer was inexperienced or not very good, but instead because code reviews just are not suitable for everyone. Big mistake is trying to forcefeed your own conventions and practises to other people. Not everyone needs code reviews. Or there are other problems. Assign the problems to the responsibility of the process. Never blame other people. People are not idiots, Programmers especially. Everyone is still trying their best.
good companies will have 15 different positions open and their interview just jumps from one position to another every time the person makes a mistake. If they have only one position open, then they are very tight on money, and the position will not last too long.
Stump the candidate obviously tests how fast they are. If the company have tight deadlines, they obviously need people who are very quick solving these problems. If you failed on of these tests, they were looking for more experienced people for the position and you were not a good match for it. It's better to find something else. Slow and inexperienced people in these positions can cause large amount of damage.
Of course I bet the company will have lots of difficulty finding anyone suitable for the position, but at least they're trying to fill it.
This just means your company is not very desirable for the more experienced folks. And everyone who has experience is already busy.
This whole story is based on someones assumption that their coworkers are idiots. Anyone who thinks like that ought to work alone, far away from other people. And what this guy does: spreads the idea to everyone via slashdot. Now everyone who reads it needs to work alone. How is this helping with building nice working teams where people actually respect the choices other people have made in their life?
I think it's other way around. Science is actually very interesting and there are people who would do it even if they couldn't get any money for it. The reason why pay is bad, and job security even worse, is that those people would do it anyway. It's just so interesting that they have to use very efficient ways of discouraging people to do it to regognize who have lost their faith in the science they're doing. Once that happens, it's known that it'll lead to nothing and the people should be doing something else. This is why job security and pay in science is very bad. Those are the only way to regognize which research is actually going to be valuable. Ask the scientists themselves. If they jump to do something else, they're no longer believing their research is going to be useful.
Guess you missed the announcement where they demonstrated working cold fusion month ago? Fusion doesnt have to be very efficient. E=mc^2 takes care of that. c is very big number. Even very small or slow reaction will produce enough energy that you can do useful stuff with it.
From the article and the details they're giving, it doesn't sound very good way to produce fuel. First the sunlight has very low efficiency. And if you're splitting water, you won't get any more energy out than what you could utilize from the sun's energy. And everyone who has spent any time outside during summer knows that the amount of energy that hits the earth can warm it slightly, but it hardly has enough energy to move your car. This means that we'd need to cover very large amount of earth's surface with these panels until you can drive significant number of cars with this fuel.
The reason why oil can move your car is because it took a million years for plants to store energy which was then converted to oil. It's not very good if you need to wait million years before you can drive half a mile with your car. With this tech that splits water, you'd actually keep the panels working for thousands of years before you can get enough fuel....
Once we run out of oil, we will have big problems. Hopefully by that time, they can get cold fusion to work reliably and make it run our cars.
> there's less crackers where there are enforced laws against computer crime though.
It doesn't work like that. Mostly enforcing those laws just causes backlash. Mostly those crackers are just young people
who have not yet figured out what is the alternative to the cracking and they just follow what everyone else is doing around them.
Different people find different ways to handle the situation; for some it's creating some software on their own, and others
will find they want to create graphics... I see this stage just a mechanism for making young people choose what they want to do in the future. The only way to get them choose it themselves is to put them in situation where they need to change the status quo. But it needs a mechanism which detects if the people can actually make their own decisions, instead of just following what others are doing.
Lets see how it works. Opengl has 4 different ways to use the apis: 1) immediate mode, 2) display lists 3) vertex arrays 4) vbo's.
It is recommended to use vbo's in all code because it's the fastest. What they forgot to say is that you need to learn display lists and vertex arrays before trying with vbo's. If it takes half year to explore how each different way of using the api works, it takes 2 years before you can get vbo's to work. This effort is trivial if you're a company with 30 developers, but it's very big problem if you're a hobbyist with limited amount of time to use for it. In 2 years, with the old tech using sprites etc it was possible to create the whole game in that time. With opengl, all you can do is just learn the api in that time. How is that an improvement? Of course if you _already_ know the api, it's easy to choose the correct way to do it, but most hobbyist game developers only have time to explore the possibilities of one or two of the alternatives. Each of them have different restrictions. It's just impossible to know the restrictions before you actually try it yourself. And trying it takes long time. And end result after choosing wrong api is that you don't get frame rates working at all. Your game is useless.
Oh and each of them works different way. Once you learn one way of doing it, and it fails to work, all your previous knowledge of the api is useless. Just waste of time. And time is what hobbyist game developers do not have. Not enough to play with the api _and_ design your game.
But sure, there are people who invested 10 years of their life for one technology, and they can get some games done with opengl. Or maybe they have a team or company. Either way, it's not getting easier to write these games. Why are people using tech that makes it more difficult to write games?
Not only that but directX and opengl are actually making writing games considerably more difficult. The problem is that they both enforce some arbitrary rules in their api's, while game developers would want freedom to do anything the hardware is capable of doing. Writing what developer wanted was easy when you could directly access the screen pixels. Now that is not possible and developers need to do hacks to get the same thing. The problem is these arbitrary restrictions that the api's are enforcing.
The fact is that neither opengl nor directx is designed for the game developers. They're designed to make game development so difficult that hobbyists cannot do it! So that the playing field is completely reserved for companies.
Now that everyone on slashdot knows where to get a real yoda statue, are we already taking bets on how long it'll be still there...
But the green stuff is the wrong answer. They just want to push us back to 1700s where everything was transported with horses. :)
We should be looking forward into new great stuff and not going backwards in time.
The real problem with energy is that there just isn't that much of it available after 2 billion years of trying matter configurations randomly. Any configuration of matter that could release some energy has already been tried, and it already released all the energy 100000 years ago. So not much is left. It takes technological advancement to find those configurations that have not been tried yet. Energy stuff is fighting billions of years of evolution. It's not easy task. We need to use all possible ways we can find to solve the problems. Including nuclear. Especially nuclear because of E=mc^2. c is very big number. Solar energy is no better than nuclear. (the only difference between solar and nuclear is that the reaction happens few millions of km's away in the sun). Cold fusion folks seem to be already building working reactors. But it has problems with reproducibility. They don't know how it works. So it could stop working when you get small changes in temperature and there is nothing they could do to restore it. The green stuff is considerably worse. The green stuff doesn't even have a chance. The energy balance equation just doesnt work for them.