But another interesting quote relevant to this article:
"Recognizing a revenue opportunity when they saw one, eight equatorial countries proclaimed in the Bogota Declaration of 1976 that they owned the portion of the geostationary orbit above their territories. They demanded that any nation wishing to place satellites in said orbit first obtain permission from the country beneath. Since the equatorial nations' ability to enforce this claim at the time was approximately zilch, the U.S. and other developed countries said: In your dreams. But you wait. If Ecuador ever perfects that 23,000-mile-range surface-to-space missile, I'll bet negotiations get reopened real quick."
To clarify, the doc states that the the values are derived from the hardware information. Not much can fit in two DWORDs, and many devices will map to the same value. As if that wasn't enough, the two DWORDs are then put through an MD5 hash. MD5 is one way, there's no way to get back the original information.
Given this scheme it's absolutely impossible for Microsoft to decode your hardware information. That's one of the reasons the article concluded that WPA is not as problematic as some people think.
Now that we know WPA isn't violating anybody's privacy the main caveat is the inconvenience. I won't argue with that.
A few years ago, when I was in college, I stuck it to some idiot for doing the same thing (might have even been MD5). It's the one and only time I reported someone for abusing the systems (yes, I approached him nicely the first time). He was a regular undergrad running it on every available machine in the CS department. It was nice'd, but it still managed to peg the CPU and slow down interactive use on all the machines by quite a bit. Very annoying; nobody has the right to monopolize computer time on public systems at the expense of everyone else. Use your own.
First, code reviews are a really, really good thing. I'm sorry for all of you with ego's so fragile that you can't stand the code getting reviewed. Two key aspects of a successful code review is to realize that nobody is perfect and argue over style another time.
Most code I write forms the foundation of the application and most of it is a template based framework (stl extensions). It's complex enough that nobody even tries reviewing it. They just take my word for it that it works:).
Hahahahaa. Wow, imagine seeing this in the same paragraph stating that code reviews are harmful. Kind of says it all, doesn't it?
Speaking of pair programming, I'm sure it's great for some stuff, such as boilerplate code or the grunt work coding that's a certain percentage of any project, but it disrupts flow. It also encourages people to chat and get off topic, which is hard to avoid. Group writing is rarely successful, I'm not sure why group programming would be any different.
The Mad Scientists Club is an awesome set of books for kids. I know that it helped shape my intellectual curiosity and define my childhood (and career path).
Contrary to what most people thing, programming is not rocket science. It's more time consuming than anything else.
Contrary to what most people think, rocket science isn't rocket science, either.
Now before someone accuses me of being egotistic let me explain: Writing software is all about mastering arbitrary complexity. This is hard, because we're always trying to push the limits. As soon as we get new tools to make something easier, we move onto more complex projects. (This is true for a lot of fields, not just software.)
Booch says it best:
A physician, a civil engineer, and a computer scientist were arguing about what was the oldest profession in the world. The physician remarked, "Well, in the Bible, it says that God created Eve from a rib taken out of Adam. This clearly required surgery, and so I can rightly claim that mine is the oldest profession in the world." The civil engineer interrupted and said, "But even earlier in the book of Genesis, it states that Got created the order of the heavens and the earth from out of chaos. This was the first and certainly the most spectacular application of civil engineering. Therefore, fair doctor, you are wrong: mine is the oldest profession in the world." The computer scientist leaned back in his chair, smiled, and then said confidently, "Ah, but who do you think created the chaos?"
"We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds."
Instead of concocting an unusual strategy involving a 50% pay cut, why not just work less?
I realize this is easier said than done, but but more companies are realizing that encouraging too much overtime leads to burnout and isn't a good long-term strategy.
There will be times, of course, when you'll need/want to make the extra push to get something done, but make this the exception and not the rule. If you're doing a good job and your company fires you simply because you aren't working 70+ hours a week then take it as an omen and work someplace else.
(IANAL, but I don't believe that you can be forced to work more than 40 hours a week on an ongoing basis.)
Peer review - This one has already been mentioned. IMHO this should be informal, developers are not grading each other. Rather, make sure that they are all code reviewing each other's work. Developers should take pride in their work and put their names on code they write and contribute to. (This makes it easier to get a feel for the quality of their code and also helps developers and managers know who to turn to when they have problems.)
Ownership - Make sure that developers have clear ownership boundaries. They work on other pieces, of course, but they are primarily responsible for delivering the component that they own. If a piece falls behind or is low quality you know who is responsible. You must still take into account other factors. If an inexperienced developer falls behind because he took on too much, that doesn't necessarily reflect badly on him.
Set goals - Developers should set their own goals (guided by their manager(s)) and be judged by how well they accomplish them.
Ranking - When all is said and done management should rank the developers and give out bonuses accordingly. The best get the highest bonuses, it goes down from there. Ranking is easier than you think, especially when you have a variety of data to use. This ranking should not be published!
Spot bonuses - If you can, give out spot bonuses when someone is doing particularly good work. This is purely a motivation thing. Again, don't make it public or make a big deal over it. You don't want to demotivate everybody that didn't get the bonus.
There are many traps and pitfalls. It's very subjective, you need to work especially hard to ensure that it does not become a popularity contest
The number of bugs will be higher for proactive developers that take on more work. Plus, the time it takes to fix a bug varies greatly on the underlying code. Some bugs that sound trivial are actually quite hard to fix, while big features can be done quickly. And what happens when developer A writes tons of bad code, moves onto something else, and developer B gets to clean up?
Bug tracking software will give you a small part of the overall picture, but don't rely on it entirely.
This is/. so some people will probably cringe, but if you're as good as you say you are then try Microsoft. Seriously.
Great place to work and they're always looking for smart, competent people. When you're fresh out of college I don't think they look for skills in specific technologies (beyond stuff like C++). The important things are your problem solving skills and your ability to learn quickly. For example, most interviewers don't care whether you code a solution in C, C++, or Java.
You sound like a good fit as a Software Design Engineer. Sponsorship shouldn't be a problem. You should interview, even if it's just for kicks.
Even if you don't heed my advice, look into some real companies and not some inane IT shops. If the interviewers aren't interested in your checkers and chess programs I'd consider that a bad sign.
When they compare it to Terminal Server or Citrix correct them on it. Citrix and Terminal Server are kind of like pcAnywhere, screenscrapers.
Sorry, I can't let this pass. Not only is this wrong, but Terminal Server is quite a bit faster than X. It's even fast enough to run Office at a tolerable speed over a 56k modem.
On my version (20.7 under Win2k) it does exactly that by default. I have the regular cursor I can use in either area and there's a faded cursor synchronized in the other section.
Hewlett-Packard: responsible for confusing generations of calculator users.
Whatever. As anyone here with an IQ > 40 will tell you, RPN if far superior to infix notation. Besides, it's pretty rude to make snide comments like that when linking to an obituary.
It is kind of sad though. I have tremendous respect for anybody who can build the kind of company HP has become.
2. Selecting a bunch of files. Here the GUI can get quite awkward or useless. If the selection criterion is simple enough, it might be workable: select all files starting with project1*, for example. Sort by name, select the relevant files. But if the selection pattern is more complex, that might not work. You really have the urge to type something like SELECT *YAHOO* in the address bar, that would be so much easier.
Windows Explorer is pretty flexible when it comes to shell extensions and folder templates. In fact, you've given me a pretty good idea for a quick weekend project. Ideally it should support both regular expressions and globbing.
Assertions are great. I personally litter my code with assertions (for invariantes, preconditions, postconditions, etc.), but it's no substitute for running through code with a debugger.
I don't care how good you are, if you write any quantity of code at all you should be stepping through it with a good debugger before checking it in. It's an excellent sanity check and also allows you to explore unlikely error conditions by tweaking values (or manually stepping into code via. 'Set Next Statement').
I hate to knock everyone's pet design methodology, but OO design *really* is overkill for smaller projects; and all projects start off small.
No, not all projects start off small. One of the rules of thumb of commercial software development is a product that takes less than six months to develop probably has no real value. Why? Because a group of average programmers can copy it in less than a year.
I'd ask what experience you have, but I see you're posting from a.edu domain. However, even in school I found that careful design allowed me to trump the rest of the class at software projects. Usually by a lot. And in less time, too.
Free software gets written because some developer has an itch. Rather than drawing up miles of uml charts for a design, [s]?he whips something quick out in a language they are familiar with (and one with lots of existing code, no less). Only afterwards does it start to grow into something that might benefit from a structured design.
I've written some extremely useful stuff this way! But there are words for this: hacking, cowboy coding, etc. Do not confuse this with software engineering.
Slashdot Mirror
Do you think a great scientist like Stephen Hawking would ever get "bought" (as you put it) by a company like Microsoft?
According to this CNN interview his son works for Microsoft. I haven't looked to see if he still does.
Of course not.
But another interesting quote relevant to this article:
"Recognizing a revenue opportunity when they saw one, eight equatorial countries proclaimed in the Bogota Declaration of 1976 that they owned the portion of the geostationary orbit above their territories. They demanded that any nation wishing to place satellites in said orbit first obtain permission from the country beneath. Since the equatorial nations' ability to enforce this claim at the time was approximately zilch, the U.S. and other developed countries said: In your dreams. But you wait. If Ecuador ever perfects that 23,000-mile-range surface-to-space missile, I'll bet negotiations get reopened real quick."
Except for the fact that a random number is thrown in, altering the hash.
To clarify, the doc states that the the values are derived from the hardware information. Not much can fit in two DWORDs, and many devices will map to the same value. As if that wasn't enough, the two DWORDs are then put through an MD5 hash. MD5 is one way, there's no way to get back the original information.
Given this scheme it's absolutely impossible for Microsoft to decode your hardware information. That's one of the reasons the article concluded that WPA is not as problematic as some people think.
Now that we know WPA isn't violating anybody's privacy the main caveat is the inconvenience. I won't argue with that.
Excessive, but not unwarranted.
A few years ago, when I was in college, I stuck it to some idiot for doing the same thing (might have even been MD5). It's the one and only time I reported someone for abusing the systems (yes, I approached him nicely the first time). He was a regular undergrad running it on every available machine in the CS department. It was nice'd, but it still managed to peg the CPU and slow down interactive use on all the machines by quite a bit. Very annoying; nobody has the right to monopolize computer time on public systems at the expense of everyone else. Use your own.
And I don't suppose that could be because of the 180 day trial period of the beta, could it?
First, code reviews are a really, really good thing. I'm sorry for all of you with ego's so fragile that you can't stand the code getting reviewed. Two key aspects of a successful code review is to realize that nobody is perfect and argue over style another time.
Most code I write forms the foundation of the application and most of it is a template based framework (stl extensions). It's complex enough that nobody even tries reviewing it. They just take my word for it that it works :).
Hahahahaa. Wow, imagine seeing this in the same paragraph stating that code reviews are harmful. Kind of says it all, doesn't it?
Speaking of pair programming, I'm sure it's great for some stuff, such as boilerplate code or the grunt work coding that's a certain percentage of any project, but it disrupts flow. It also encourages people to chat and get off topic, which is hard to avoid. Group writing is rarely successful, I'm not sure why group programming would be any different.
The Mad Scientists Club is an awesome set of books for kids. I know that it helped shape my intellectual curiosity and define my childhood (and career path).
Another good one for the same age group is The Great Brain.
Oh, and while I'm reminiscing, Legos rock
Contrary to what most people thing, programming is not rocket science. It's more time consuming than anything else.
Contrary to what most people think, rocket science isn't rocket science, either.
Now before someone accuses me of being egotistic let me explain: Writing software is all about mastering arbitrary complexity. This is hard, because we're always trying to push the limits. As soon as we get new tools to make something easier, we move onto more complex projects. (This is true for a lot of fields, not just software.)
Booch says it best:
A physician, a civil engineer, and a computer scientist were arguing about what was the oldest profession in the world. The physician remarked, "Well, in the Bible, it says that God created Eve from a rib taken out of Adam. This clearly required surgery, and so I can rightly claim that mine is the oldest profession in the world." The civil engineer interrupted and said, "But even earlier in the book of Genesis, it states that Got created the order of the heavens and the earth from out of chaos. This was the first and certainly the most spectacular application of civil engineering. Therefore, fair doctor, you are wrong: mine is the oldest profession in the world." The computer scientist leaned back in his chair, smiled, and then said confidently, "Ah, but who do you think created the chaos?"
Font quality for starters. Even at 1600x1200 your display isn't anywhere close to the resolution of a crappy laser printer.
I use cleartype on a 120 DPI display, and while it's quite nice I expect that to double a few times before the display is considered "good enough."
"We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds."
The article: Things You Should Never Do
Instead of concocting an unusual strategy involving a 50% pay cut, why not just work less?
I realize this is easier said than done, but but more companies are realizing that encouraging too much overtime leads to burnout and isn't a good long-term strategy.
There will be times, of course, when you'll need/want to make the extra push to get something done, but make this the exception and not the rule. If you're doing a good job and your company fires you simply because you aren't working 70+ hours a week then take it as an omen and work someplace else.
(IANAL, but I don't believe that you can be forced to work more than 40 hours a week on an ongoing basis.)
Peer review - This one has already been mentioned. IMHO this should be informal, developers are not grading each other. Rather, make sure that they are all code reviewing each other's work. Developers should take pride in their work and put their names on code they write and contribute to. (This makes it easier to get a feel for the quality of their code and also helps developers and managers know who to turn to when they have problems.)
Ownership - Make sure that developers have clear ownership boundaries. They work on other pieces, of course, but they are primarily responsible for delivering the component that they own. If a piece falls behind or is low quality you know who is responsible. You must still take into account other factors. If an inexperienced developer falls behind because he took on too much, that doesn't necessarily reflect badly on him.
Set goals - Developers should set their own goals (guided by their manager(s)) and be judged by how well they accomplish them.
Ranking - When all is said and done management should rank the developers and give out bonuses accordingly. The best get the highest bonuses, it goes down from there. Ranking is easier than you think, especially when you have a variety of data to use. This ranking should not be published!
Spot bonuses - If you can, give out spot bonuses when someone is doing particularly good work. This is purely a motivation thing. Again, don't make it public or make a big deal over it. You don't want to demotivate everybody that didn't get the bonus.
There are many traps and pitfalls. It's very subjective, you need to work especially hard to ensure that it does not become a popularity contest
This is harder than you make it sound.
The number of bugs will be higher for proactive developers that take on more work. Plus, the time it takes to fix a bug varies greatly on the underlying code. Some bugs that sound trivial are actually quite hard to fix, while big features can be done quickly. And what happens when developer A writes tons of bad code, moves onto something else, and developer B gets to clean up?
Bug tracking software will give you a small part of the overall picture, but don't rely on it entirely.
This is /. so some people will probably cringe, but if you're as good as you say you are then try Microsoft. Seriously.
Great place to work and they're always looking for smart, competent people. When you're fresh out of college I don't think they look for skills in specific technologies (beyond stuff like C++). The important things are your problem solving skills and your ability to learn quickly. For example, most interviewers don't care whether you code a solution in C, C++, or Java.
You sound like a good fit as a Software Design Engineer. Sponsorship shouldn't be a problem. You should interview, even if it's just for kicks.
Even if you don't heed my advice, look into some real companies and not some inane IT shops. If the interviewers aren't interested in your checkers and chess programs I'd consider that a bad sign.
When they compare it to Terminal Server or Citrix correct them on it. Citrix and Terminal Server are kind of like pcAnywhere, screenscrapers.
Sorry, I can't let this pass. Not only is this wrong, but Terminal Server is quite a bit faster than X. It's even fast enough to run Office at a tolerable speed over a 56k modem.
On my version (20.7 under Win2k) it does exactly that by default. I have the regular cursor I can use in either area and there's a faded cursor synchronized in the other section.
When it doubt, Emacs will probably do it.
hexl-mode is pretty decent.
Hewlett-Packard: responsible for confusing generations of calculator users.
Whatever. As anyone here with an IQ > 40 will tell you, RPN if far superior to infix notation. Besides, it's pretty rude to make snide comments like that when linking to an obituary.
It is kind of sad though. I have tremendous respect for anybody who can build the kind of company HP has become.
2. Selecting a bunch of files. Here the GUI can get quite awkward or useless. If the selection criterion is simple enough, it might be workable: select all files starting with project1*, for example. Sort by name, select the relevant files. But if the selection pattern is more complex, that might not work. You really have the urge to type something like SELECT *YAHOO* in the address bar, that would be so much easier.
Windows Explorer is pretty flexible when it comes to shell extensions and folder templates. In fact, you've given me a pretty good idea for a quick weekend project. Ideally it should support both regular expressions and globbing.
Check out http://msdn.micro sof t.com/library/periodic/period00/w2kui2.htm for how do do stuff like this!
Windows is incredibly flexible and programmable, it's just not always as obvious as *nix window managers.
Assertions are great. I personally litter my code with assertions (for invariantes, preconditions, postconditions, etc.), but it's no substitute for running through code with a debugger.
I don't care how good you are, if you write any quantity of code at all you should be stepping through it with a good debugger before checking it in. It's an excellent sanity check and also allows you to explore unlikely error conditions by tweaking values (or manually stepping into code via. 'Set Next Statement').
Two words:
Version Control
Leaving commented out code in the current version of the source just makes it less readable for future maintainers.
CE already does this -- there's a Terminal Server Client for at least the HPC versions of CE.
Don't you know, everybody here thinks they're smarter than Feynman. Bow down and worship the genius Unix sysadmins.
I hate to knock everyone's pet design methodology, but OO design *really* is overkill for smaller projects; and all projects start off small.
No, not all projects start off small. One of the rules of thumb of commercial software development is a product that takes less than six months to develop probably has no real value. Why? Because a group of average programmers can copy it in less than a year.
I'd ask what experience you have, but I see you're posting from a .edu domain. However, even in school I found that careful design allowed me to trump the rest of the class at software projects. Usually by a lot. And in less time, too.
Free software gets written because some developer has an itch. Rather than drawing up miles of uml charts for a design, [s]?he whips something quick out in a language they are familiar with (and one with lots of existing code, no less). Only afterwards does it start to grow into something that might benefit from a structured design.
I've written some extremely useful stuff this way! But there are words for this: hacking, cowboy coding, etc. Do not confuse this with software engineering.