From the article: The non-atomic nature of doubles and longs is a sop thrown to architectures that can't efficiently do 64-bit operations. That's not nearly as much an issue today as it used to be, however, and few VMs ever took advantage of it. If these types aren't made into objects, then they need to be as atomic as the other single-byte types. What he seems to be missing is that longs and doubles CAN'T be atomic on some (4 byte) thread capable processors.
long a; a++;
Will be non atomic on 4 byte processors. In the case of 0XFFFFFFFF, it first becomes 0X00000000 and then as a second operation checks the overflow and becomes the equivalent of 0X0100000000. If a thread switch occurs in the middle of the a++ and the new thread references the variable stored in a, there is a possibility of getting a value 4 billion off of the value that should be stored in there if the function performing this operation was synchronized.
Solution: lock longs on every operation. Yuck. Just what Java needs, more overhead on numeric operations.
Question: You point out that Java uses native threads but then complain about a lack of a thread scheduler. Aren't the two incompatible (some kernels hide thread scheduling details)? Would you really want Java to emulate threading as a method of creating a thread scheduler? Also, for single processor systems, thread emulation is fine, but multiprocessor systems don't lend themselves well to emulated threads for actual performance. How do you reconsile the two?
No, you also have the current transaction log up. Open up the log and kill the drop command. Now apply the week backup, the nightly backups, and today's log up until the drop. One second gone.
I just like the fact that the number of seconds in a year is about pi*10^7, or, as Carl Sagan pointed out, pi seconds is a nanocentury. I'd be bummed if we changed the standard second. In it's current format it is also extremely convenient to convert between distance and time using c.
Not to mention that sodium or potassium in pure metal form are never by-products of industrial manufacturing processes. They react with nearly anything willing to accept an electron, so any "waste" sodium or potassium are going to be in compounds, usually salts.
The parent is also correct, nobody stores magnesium in oil. Usually it is stored as a metal ribbon resembling a roll of tape. It oxidizes and generally has a white magnesium oxide layer on the edges. Before an experiment, a chemistry teacher will steel wool the ribbon down to make it shiny.
Try using it on 95 or 98. Use a source code generator or something to build about 1-3 Megs of source code, nesting or recursion not required. I've seen it too. No pattern other than all were medium sized projects. I have not encountered it on NT or 2K.
And it's really common in "crappy unsafe languages" like VB, where Form.Load and Form.Activate switch call order based on whether or not you have a breakpoint in the code. Debug by printf all over again (and VB has a Debug.Print method just for that purpose).
Ehhh... NP-complete hardly means something is better done by hand. However, you are right. Most scheduling problems are NP-complete (pp. 238-242 in Garey and Johnson).
Try a greedy add or even loading heuristic. You will find that both are extremely easy to implement and maintain, and often do a "good enough" job for most manual scheduling problems.
Here is a heuristic I wrote for scheduling Navy Instructor Pilots: Get a list of all of the holes in the schedule. Find all candidates for all holes. Find which hole has the fewest candidates (greedy). Find out who has gone the longest without serving this duty (simple even loading). It works better than 97% of the time.
Genetic algorithms are a pain in the --- to write and maintain (and I will be teaching a class on them in the Fall at UCSB, so there's a proper endorsement). Talk to the person who currently writes the schedule and see how they do it. The logic in such an expert system is likely to do a decent job. It's not like you are scheduling for a manufacturing plant where a 2% improvement in scheduling can mean 2% improvement in revenues.
I work for UCSB for Murat Karaorman (the head of the CS department for the College of Creative Studies and now an employee of TI), who worked on that project. They took 2nd place at a techno-fair for most impressive technology behind the technology that was called Digital Versatile Disks. It required a Sun server farm (and well in excess of your 512 Megs of RAM). Exremely cool stuff. Their demo was unrigged, members-of-the-audience style. The thing had a sizeable vocabulary. The company he worked for killed the technology, though. Maybe you read about something different, I'd be curious.
I tend to disagree with you. The development dollars allocated by a developer change from launch titles to late first generation (they often go down) to second generation (they go way up if the publisher sold enough in their first generation titles). So even though the developers have less to learn, they have more money to play with.
I was just giving you a hard time because I had the same initial thought: "Deep pockets? Buy some CASE tools to help you manage (I group version control under software engineering)." Then I re-read the post and realized the "large project" was intended for 4 people at 6 months. I figured scaling the "deep pockets" was also necessary. After starting to respond I got up on my soapbox, which is where all that other crap came from. My point was that the benefits don't necessarily scale with the cost (the fact that most of our developers have licenses to some expensive CASE tools and still prefer to work in emacs, notepad, and slickedit really negates the integrates-with-all-expensive-editors features of those CASE tools).
The main benefits I see to ClearCase is that 1. It mounts as a network drive and therefore works with ANY editor that runs under windows, whether or not that editor has built in support for version control software. 2. It is not a CLI version control system though it supports scripting. I hate trying to remember CVS commands.
The main benefits I see with CVS: 1. It's FREE 2. There are cheap proprietary GUIs that capture benefit 2 above.
The big problem I see with CVS: Renaming and moving files in a directory structure kinda bites in CVS. You are almost better taking a tarball of your entire directory tree and saving it as a seperate file in case you need to rollback to a point before files got moved around.
I think you misunderstood his "deep pockets." He can hire 4 programmers overseas for 6 months. That's the equivalent of 1 floating license for a Rational product. Also, I don't know if you've used Rational tools much. Hiring a fresh college grad or unemployed programmer on the cheap to work on a product will probably give you a better return on your investment than a rational tool. The cost difference between Rational tools and alternatives is staggering. My company bought 3 Floating licenses to Rational Enterprise Studio (or whatever the heck it was called) before realizing that it just wasn't worth it (we still use Rose on occasion).
Our company uses *ack* SourceSafe and SourceOffSite with very few problems. One programmer is using Notepad for all her T-SQL programming. One guy does his Visual C++ development in xemacs under Cygwin. Most people here are doing PHP editing with Visual Slick edit. We have a dedicated Mandrake box running Bugzilla. I do my design documents in Netscape Composer. HTML or text do a nice reverse delta compression in SourceSafe and it is easy to parse in PERL if I want to do some autogenerated code.
One of the problems I see with Rational software is that it ends up not being cheeper than home grown solutions, and you can't modify the heck out of it as easily as the stuff you built.
Apple is aiming at the "boutique" server market (well, probably not much of a "market" at these prices).
I said a similar thing about the first iMac. "What is the point of building a computer for techno-phobes if it costs more than a techno-phobe is willing to spend?" I was wrong. Don't underestimate Apple's market analysis. I think they've learned their lessons since the days of the Newton.
Please give me an example of an embedded database engine (or a non-embedded one that is easy to configure and CHEAP) that works with Java. I am a lecturer at UCSB and would love to teach a class using a cheap RDBMS. I downloaded InstantDB to evaluate, but the product is no longer supported (I got an email stating such the day after downloading it). I don't want to tie my students to MS or Oracle. If you have a list, I would be most grateful. I have installed MySQL, but 1. I don't know its Java support and 2. It fails some of the basics that I want for an academic use of an RDBMS (transactions, referential integrity, etc.). I installed Postgres a LONG time ago, and don't know its current state. I would prefer something slow and written in Java (for platform independence reasons) than something fast and expensive (my budget for licenses is zero becuase my courses are all optional CS classes).
Many states in the US have "At will employment." Yes, you have a contract, but it basically says that you are an employee bound by laws that say you can quit whenever and they can fire you whenever.
Employees still have rights. I'm not sure how the email would hold up in court. I know all salary changes at my company require the signature of the effected employee BEFORE they go into effect. This is pretty standard in many contracts, even for "at will" employers.
That being said, how much more code can the greatest code produce relative to someone just out of school? 2x? 3x? 4x? Whatever point that is, when the greatest coder makes more than 4x the amount of someone out of school, it's time to fire him/her and hire 4 new people.
OUCH, that's a little scathing, but not altogether troll-like. There are some things that senior developers can do that someone just out of school can't (and there are exceptions in both directions).
I have worked for a small business (currently at a 50 person company), a not-so-small business (500 person company), and contracted to some big ones (read SAIC, who acts like the biggest company in the world). Not the best sampling, but decent.
At the 50 and 500 person companies, senior developers bring a lot to the table. They figure out how to solve the customers' problems. They are the subject matter experts--the customer knows they have a problem, but doesn't know what it is or how to solve it. Senior dev mentor the junior dev.
The fact is, there are some problems that hiring a dozen fresh graduates won't solve that a single senior developer can. It isn't always about pumping out code (if it was, we'd write a code generator for it). And for those fresh graduates that can perform as senior developers, they'll get promoted quickly.
Companies that do not see this are going to wind up short on talent. I've noticed this at the big companies. They have a lot of talented programmers--all contractors. They have a lot of junior developers as permanent employees. Any of the junior developers who make the grade jump ship and become contractors, or they go work for someone who treats their employees right.
Want to bust the salary cap for being a programmer? Learn to write! If you can write proposals that get contracts, you can charge whatever the hell you want. Every place I've worked, management only thought with dollars. If you bring in more dollars and budget a higher salary for yourself, there's no reason to prevent you from making more. A side benefit is that you can often remove layers of management and bring in projects with less overhead costs. Think of it as running your own company from inside your company.
Where I work, junior developers work with senior developers on a project. Both groups get their timesheets signed by and assignments from the tech lead, who is a programmer. The tech leads report directly to the president of the company. Project managers exist, but as a support function (and they earn their keep by shielding developers from the customer). Our R&D team spends about 8 hours a week writing proposals (on average). For a 50 person company, this seems to work.
That said, I feel obligated to point out that we didn't build this hierarchy first. We had a director of development who was a micromanaging PHB. We had a CTO who did absolutely nothing. That was our analogy to the promoted programmer you had. First he was promoted to Director of Development, but he sucked. So they promoted him to CTO. Then he sucked. The DoD they replaced him with was terrible. Now the DoD is gone, and the CTO is a developer again (at the same CTO salary), but because he was out of the loop for too long, we have him writing VBA in MS Excel. Aside from the fact that a programmer who is effectively a junior developer is making more than the tech leads, we seem to have reached a nice equilibrium.
Have you found any of this reprinted online? I would be interested in reading this. I work for two employers, a government contractor full-time and a university part-time. With both of them I signed away any rights to my work. I always wonder if one would sue the other. I don't have time to do work on the side, so I really haven't considered it much of a loss as far as my own projects go.
I work in California, so any link regarding CA law would be cool.
Not surprising. Many implementations of rand() return even, then odd, then even, then odd, etc. That is why you should never do rand()%2 for a random bool. It is better to use something like rand()&32<<5. Anyway, even+odd=odd, so your problem would fit that pattern. Mod 6 and + 1 won't change that (Mod 6 preserves parity and + 1 just swaps parity between your two rolls). Look in Knuth for some better random number generators that don't have such restrictions. For dice rolling, there is a really convenient one that just XORs two bits in a number and shifts everything to the right replacing the leftmost bit with the XOR result. It's extremely easy to code, but I don't have my copy of Knuth at work right now.
Crap! I've been rooked! Seriously, we use PHP to write interfaces for some pretty cool operations research applications. I often like to think that I work for a "serious" business.
What about Forte for Java? It freezes for me considerably less than it used to. What does Dev Studio offer you that Forte doesn't (other than the obvious--it works with C++)? Both show call stacks, have decent watch windows, interface with source code versioning control, compile code, highlight syntax, etc. Anyway, I think that it is fairly close to Visual Studio.
I downloaded KDevelop about a year ago. I have no idea how far it has come since then. It had a lot of nice development features, but I couldn't get any of the debugging features to work right.
I tend to like Visual Studio, but now that I am also working with PHP, it doesn't exactly help. I can program emacs to do syntax coloring, but I am, quite frankly, too lazy (plus it has been years since I learned how to do that kind of stuff in emacs, it would take me a while). Looks like notepad rules.
You are missing the point as well (sly grin). Corporations do not buy a system with an interface because it is more efficient. They buy it because they are consumer whores and the marketing gods tell them to. UI science should not be liberally applied in business. You think that aesthetics and efficiency go hand in hand? History is full of examples of products that failed to compete against less efficient solutions simply because they weren't marketed properly. Aqua is beautiful. XP is beautiful. Buy them because they told you to and they look pretty in commercials.
Seriously, you are a minority in that you bought your computer on a set of real scientific criteria. I have not used OSX much, and was used to OS9, so I really hope that after the learning curve it becomes as friendly as previous iterations.
My analogy wasn't intended to be perfect. When I was thinking about skins, I was just thinking about the plaf stuff in Java. The min and max buttons move around, analogous to the radio being in different places on different cars. Everything else just looks different. In cars, you might have knobs or up and down pushbuttons to represent the same feature. Your horn might be in the middle or symmetrically positioned toward the sides of the wheel. The pedals might be different shapes. My car has three pedals: clutch, brake, gas. My dad's car has three pedals: parking brake, brake, and gas. So they do change pedal layout from model to model. Fortunately, they don't change gas and brake around, because it really is life critical. My min and max buttons are not, so they really are more analogous to the radio buttons than the pedals. And gearshift grids do change from model to model. Several of the newer automatic cars have a shifter that behaves as a sequential shifter. Some cars have park behind first. Some have it after fifth. I wasn't really trying to comment on the customizability of an interface as much as I was on the idea of a standard interface. Actaully, I had a more well thought out post first, but then my browser crashed. I just tried to cram all my thoughts back into the re-post. The customizability part should have just been thrown out.
The reason for the car analogy in the first place is that most people seem to have a complete disconnect when thinking about user interfaces on computers. They forget that people have been studying human machine interaction for a very long time.
I also really don't have anything against Raskin. I have a copy of his book at my work. I remember in a previous interview he said a lot of really interesting things, like how it was bad to design a cd player UI on a computer to look like a cd player like in your home. I disagree with him on that. However, he made some very convincing arguments about how there was much functionality you could add if you broke from the "like the real world version" model.
Part of my point was that in a computer you rarely have to react as fast and with as deadly consequences as you do in a car. The analogy was just meant to provoke thought, not to say any one thinking is right or wrong.
To help argue your point instead of trying to convince you otherwise, think about turn indicators on a car. There was one prototype where the turn indicator control on the car was connected to the steering wheel (not the column, the wheel). After all, motorcycle turn indicators work this way. BUT, motorcycles don't turn their wheel all the way around like a car. Imagine the disdain of the driver when they wanted to cancel their turn indicator in the middle of a turn. Same thing with radio stations or cruise control. Fortunately, you don't use cruise control in the speed region where you twist your steering wheel all the way around. Basically, that became the design rule use by the big three auto makers: if you might need to use something in the middle of a sharp turn, don't put it on the steering wheel (except the horn, which is often in the middle or symmetrically represented on the sides). Some standardization is good.
Now devil's advocate: I use a car and a motorcycle. In my motorcycle, my throttle is on the right, but so is the brake. My shifter is on the left. My turn indicators don't automatically cancel. I use hands for things that I use my feet for in the car. Should we standardize the interface for motorized vehicles? Probably not.
On motorcycles, people do make functional changes more analogous to skins. My shifter shifts up by pressing up with my toe. I have a number of friends who race and like to upshift pressing down. The difference between upshifting and downshifting in a turn can mean life or death consequences. I don't ride their bikes because their customization render the interface unusable for me. Perhaps in an environment where you need to pool resources standardization is good. I still think that the added productivity to an individual by allowing customization is worth it in an environment where resources are more or less owned by an individual. YMMV
Customisation is required for ANYTHING we interact with in a major and complex way, computers are probably the biggest example of this yet, thankfully their customisability is growing.
I agree. Something to think about: A car is the most time critical interface that most people deal with. Take your eyes off the road for 8 seconds to change the radio station while a child crosses the street. And yet, most people manage NOT to kill someone with their car. These are the same people that bitch and moan about computers being hard to use. Anyway, everyone has a certain ammount of customization to their car. They use their favorite radio station. They adjust the seat. They roll down the windows. They adjust the mirrors. Should these things be standardized? Absolutely not. Sure, I found it a pain to have to adjust the seat after my girlfriend drove me home, but it was definitely better than her driving without reaching the pedals.
Computer interfaces are analogous; "I like it" IS a good reason to change your interface. Comfort with a tool improves productivity.
Besides, it would be difficult to have anyone find a comprehensive set of widgets without overwhelming even the best user. There is a big difference between multi-line and single line text boxes (press the enter key when there is a default button on the screen). Or tri-state vs. binary check boxes. Or the hundreds of ways a calendar could be used. If the functionality of something is different, should the look be different? What about the grids in Access vs. the grids in excel?
I agree that skins that move the window resizing controls around might have a learning curve for a guest at a machine. But is it bad? A slight loss of productivity for a guest for a comfort increase for the main user is probably worth the tradeoff. I know that I like changing my window background to 20% grey. It provides enough contrast without blasting my eyes with bright white light. Just because a text box functionally mimics paper and ink doesn't mean that it needs the same colors. And think about editors with syntax highlighting. I may browse code looking mostly at braces. I damn well want my braces to stand out. You might browse code by comments, whereas I find them distracting, so you choose a high contrast comment color and I choose a low contrast color. Because we are different, we have difficulties at each other's machines, but it's a lot better than each of us being less productive most of the time.
Slashdot Mirror
You hit the nail on the head:
From the article:
The non-atomic nature of doubles and longs is a sop thrown to architectures that can't efficiently do 64-bit operations. That's not nearly as much an issue today as it used to be, however, and few VMs ever took advantage of it. If these types aren't made into objects, then they need to be as atomic as the other single-byte types.
What he seems to be missing is that longs and doubles CAN'T be atomic on some (4 byte) thread capable processors.
long a;
a++;
Will be non atomic on 4 byte processors. In the case of 0XFFFFFFFF, it first becomes 0X00000000 and then as a second operation checks the overflow and becomes the equivalent of 0X0100000000. If a thread switch occurs in the middle of the a++ and the new thread references the variable stored in a, there is a possibility of getting a value 4 billion off of the value that should be stored in there if the function performing this operation was synchronized.
Solution: lock longs on every operation. Yuck. Just what Java needs, more overhead on numeric operations.
Question: You point out that Java uses native threads but then complain about a lack of a thread scheduler. Aren't the two incompatible (some kernels hide thread scheduling details)? Would you really want Java to emulate threading as a method of creating a thread scheduler? Also, for single processor systems, thread emulation is fine, but multiprocessor systems don't lend themselves well to emulated threads for actual performance. How do you reconsile the two?
No, you also have the current transaction log up. Open up the log and kill the drop command. Now apply the week backup, the nightly backups, and today's log up until the drop. One second gone.
I just like the fact that the number of seconds in a year is about pi*10^7, or, as Carl Sagan pointed out, pi seconds is a nanocentury. I'd be bummed if we changed the standard second. In it's current format it is also extremely convenient to convert between distance and time using c.
Not to mention that sodium or potassium in pure metal form are never by-products of industrial manufacturing processes. They react with nearly anything willing to accept an electron, so any "waste" sodium or potassium are going to be in compounds, usually salts.
The parent is also correct, nobody stores magnesium in oil. Usually it is stored as a metal ribbon resembling a roll of tape. It oxidizes and generally has a white magnesium oxide layer on the edges. Before an experiment, a chemistry teacher will steel wool the ribbon down to make it shiny.
Try using it on 95 or 98. Use a source code generator or something to build about 1-3 Megs of source code, nesting or recursion not required. I've seen it too. No pattern other than all were medium sized projects. I have not encountered it on NT or 2K.
And it's really common in "crappy unsafe languages" like VB, where Form.Load and Form.Activate switch call order based on whether or not you have a breakpoint in the code. Debug by printf all over again (and VB has a Debug.Print method just for that purpose).
Oh, you were just trolling... damn.
Greedy add.
The coward's way out. Often works on real world problems.
Ehhh... NP-complete hardly means something is better done by hand. However, you are right. Most scheduling problems are NP-complete (pp. 238-242 in Garey and Johnson).
Try a greedy add or even loading heuristic. You will find that both are extremely easy to implement and maintain, and often do a "good enough" job for most manual scheduling problems.
Here is a heuristic I wrote for scheduling Navy Instructor Pilots: Get a list of all of the holes in the schedule. Find all candidates for all holes. Find which hole has the fewest candidates (greedy). Find out who has gone the longest without serving this duty (simple even loading). It works better than 97% of the time.
Genetic algorithms are a pain in the --- to write and maintain (and I will be teaching a class on them in the Fall at UCSB, so there's a proper endorsement). Talk to the person who currently writes the schedule and see how they do it. The logic in such an expert system is likely to do a decent job. It's not like you are scheduling for a manufacturing plant where a 2% improvement in scheduling can mean 2% improvement in revenues.
I work for UCSB for Murat Karaorman (the head of the CS department for the College of Creative Studies and now an employee of TI), who worked on that project. They took 2nd place at a techno-fair for most impressive technology behind the technology that was called Digital Versatile Disks. It required a Sun server farm (and well in excess of your 512 Megs of RAM). Exremely cool stuff. Their demo was unrigged, members-of-the-audience style. The thing had a sizeable vocabulary. The company he worked for killed the technology, though. Maybe you read about something different, I'd be curious.
I tend to disagree with you. The development dollars allocated by a developer change from launch titles to late first generation (they often go down) to second generation (they go way up if the publisher sold enough in their first generation titles). So even though the developers have less to learn, they have more money to play with.
I was just giving you a hard time because I had the same initial thought: "Deep pockets? Buy some CASE tools to help you manage (I group version control under software engineering)." Then I re-read the post and realized the "large project" was intended for 4 people at 6 months. I figured scaling the "deep pockets" was also necessary. After starting to respond I got up on my soapbox, which is where all that other crap came from. My point was that the benefits don't necessarily scale with the cost (the fact that most of our developers have licenses to some expensive CASE tools and still prefer to work in emacs, notepad, and slickedit really negates the integrates-with-all-expensive-editors features of those CASE tools).
The main benefits I see to ClearCase is that
1. It mounts as a network drive and therefore works with ANY editor that runs under windows, whether or not that editor has built in support for version control software.
2. It is not a CLI version control system though it supports scripting. I hate trying to remember CVS commands.
The main benefits I see with CVS:
1. It's FREE
2. There are cheap proprietary GUIs that capture benefit 2 above.
The big problem I see with CVS:
Renaming and moving files in a directory structure kinda bites in CVS. You are almost better taking a tarball of your entire directory tree and saving it as a seperate file in case you need to rollback to a point before files got moved around.
I think you misunderstood his "deep pockets." He can hire 4 programmers overseas for 6 months. That's the equivalent of 1 floating license for a Rational product. Also, I don't know if you've used Rational tools much. Hiring a fresh college grad or unemployed programmer on the cheap to work on a product will probably give you a better return on your investment than a rational tool. The cost difference between Rational tools and alternatives is staggering. My company bought 3 Floating licenses to Rational Enterprise Studio (or whatever the heck it was called) before realizing that it just wasn't worth it (we still use Rose on occasion).
Our company uses *ack* SourceSafe and SourceOffSite with very few problems. One programmer is using Notepad for all her T-SQL programming. One guy does his Visual C++ development in xemacs under Cygwin. Most people here are doing PHP editing with Visual Slick edit. We have a dedicated Mandrake box running Bugzilla. I do my design documents in Netscape Composer. HTML or text do a nice reverse delta compression in SourceSafe and it is easy to parse in PERL if I want to do some autogenerated code.
One of the problems I see with Rational software is that it ends up not being cheeper than home grown solutions, and you can't modify the heck out of it as easily as the stuff you built.
Apple is aiming at the "boutique" server market (well, probably not much of a "market" at these prices).
I said a similar thing about the first iMac. "What is the point of building a computer for techno-phobes if it costs more than a techno-phobe is willing to spend?" I was wrong. Don't underestimate Apple's market analysis. I think they've learned their lessons since the days of the Newton.
Please give me an example of an embedded database engine (or a non-embedded one that is easy to configure and CHEAP) that works with Java. I am a lecturer at UCSB and would love to teach a class using a cheap RDBMS. I downloaded InstantDB to evaluate, but the product is no longer supported (I got an email stating such the day after downloading it). I don't want to tie my students to MS or Oracle. If you have a list, I would be most grateful. I have installed MySQL, but 1. I don't know its Java support and 2. It fails some of the basics that I want for an academic use of an RDBMS (transactions, referential integrity, etc.). I installed Postgres a LONG time ago, and don't know its current state. I would prefer something slow and written in Java (for platform independence reasons) than something fast and expensive (my budget for licenses is zero becuase my courses are all optional CS classes).
Many states in the US have "At will employment." Yes, you have a contract, but it basically says that you are an employee bound by laws that say you can quit whenever and they can fire you whenever.
Employees still have rights. I'm not sure how the email would hold up in court. I know all salary changes at my company require the signature of the effected employee BEFORE they go into effect. This is pretty standard in many contracts, even for "at will" employers.
That being said, how much more code can the greatest code produce relative to someone just out of school? 2x? 3x? 4x? Whatever point that is, when the greatest coder makes more than 4x the amount of someone out of school, it's time to fire him/her and hire 4 new people.
OUCH, that's a little scathing, but not altogether troll-like. There are some things that senior developers can do that someone just out of school can't (and there are exceptions in both directions).
I have worked for a small business (currently at a 50 person company), a not-so-small business (500 person company), and contracted to some big ones (read SAIC, who acts like the biggest company in the world). Not the best sampling, but decent.
At the 50 and 500 person companies, senior developers bring a lot to the table. They figure out how to solve the customers' problems. They are the subject matter experts--the customer knows they have a problem, but doesn't know what it is or how to solve it. Senior dev mentor the junior dev.
The fact is, there are some problems that hiring a dozen fresh graduates won't solve that a single senior developer can. It isn't always about pumping out code (if it was, we'd write a code generator for it). And for those fresh graduates that can perform as senior developers, they'll get promoted quickly.
Companies that do not see this are going to wind up short on talent. I've noticed this at the big companies. They have a lot of talented programmers--all contractors. They have a lot of junior developers as permanent employees. Any of the junior developers who make the grade jump ship and become contractors, or they go work for someone who treats their employees right.
Want to bust the salary cap for being a programmer? Learn to write! If you can write proposals that get contracts, you can charge whatever the hell you want. Every place I've worked, management only thought with dollars. If you bring in more dollars and budget a higher salary for yourself, there's no reason to prevent you from making more. A side benefit is that you can often remove layers of management and bring in projects with less overhead costs. Think of it as running your own company from inside your company.
Where I work, junior developers work with senior developers on a project. Both groups get their timesheets signed by and assignments from the tech lead, who is a programmer. The tech leads report directly to the president of the company. Project managers exist, but as a support function (and they earn their keep by shielding developers from the customer). Our R&D team spends about 8 hours a week writing proposals (on average). For a 50 person company, this seems to work.
That said, I feel obligated to point out that we didn't build this hierarchy first. We had a director of development who was a micromanaging PHB. We had a CTO who did absolutely nothing. That was our analogy to the promoted programmer you had. First he was promoted to Director of Development, but he sucked. So they promoted him to CTO. Then he sucked. The DoD they replaced him with was terrible. Now the DoD is gone, and the CTO is a developer again (at the same CTO salary), but because he was out of the loop for too long, we have him writing VBA in MS Excel. Aside from the fact that a programmer who is effectively a junior developer is making more than the tech leads, we seem to have reached a nice equilibrium.
Have you found any of this reprinted online? I would be interested in reading this. I work for two employers, a government contractor full-time and a university part-time. With both of them I signed away any rights to my work. I always wonder if one would sue the other. I don't have time to do work on the side, so I really haven't considered it much of a loss as far as my own projects go.
I work in California, so any link regarding CA law would be cool.
Not surprising. Many implementations of rand() return even, then odd, then even, then odd, etc. That is why you should never do rand()%2 for a random bool. It is better to use something like rand()&32<<5. Anyway, even+odd=odd, so your problem would fit that pattern. Mod 6 and + 1 won't change that (Mod 6 preserves parity and + 1 just swaps parity between your two rolls). Look in Knuth for some better random number generators that don't have such restrictions. For dice rolling, there is a really convenient one that just XORs two bits in a number and shifts everything to the right replacing the leftmost bit with the XOR result. It's extremely easy to code, but I don't have my copy of Knuth at work right now.
Crap! I've been rooked! Seriously, we use PHP to write interfaces for some pretty cool operations research applications. I often like to think that I work for a "serious" business.
What about Forte for Java? It freezes for me considerably less than it used to. What does Dev Studio offer you that Forte doesn't (other than the obvious--it works with C++)? Both show call stacks, have decent watch windows, interface with source code versioning control, compile code, highlight syntax, etc. Anyway, I think that it is fairly close to Visual Studio.
I downloaded KDevelop about a year ago. I have no idea how far it has come since then. It had a lot of nice development features, but I couldn't get any of the debugging features to work right.
I tend to like Visual Studio, but now that I am also working with PHP, it doesn't exactly help. I can program emacs to do syntax coloring, but I am, quite frankly, too lazy (plus it has been years since I learned how to do that kind of stuff in emacs, it would take me a while). Looks like notepad rules.
You are missing the point as well (sly grin). Corporations do not buy a system with an interface because it is more efficient. They buy it because they are consumer whores and the marketing gods tell them to. UI science should not be liberally applied in business. You think that aesthetics and efficiency go hand in hand? History is full of examples of products that failed to compete against less efficient solutions simply because they weren't marketed properly. Aqua is beautiful. XP is beautiful. Buy them because they told you to and they look pretty in commercials.
Seriously, you are a minority in that you bought your computer on a set of real scientific criteria. I have not used OSX much, and was used to OS9, so I really hope that after the learning curve it becomes as friendly as previous iterations.
My analogy wasn't intended to be perfect. When I was thinking about skins, I was just thinking about the plaf stuff in Java. The min and max buttons move around, analogous to the radio being in different places on different cars. Everything else just looks different. In cars, you might have knobs or up and down pushbuttons to represent the same feature. Your horn might be in the middle or symmetrically positioned toward the sides of the wheel. The pedals might be different shapes. My car has three pedals: clutch, brake, gas. My dad's car has three pedals: parking brake, brake, and gas. So they do change pedal layout from model to model. Fortunately, they don't change gas and brake around, because it really is life critical. My min and max buttons are not, so they really are more analogous to the radio buttons than the pedals. And gearshift grids do change from model to model. Several of the newer automatic cars have a shifter that behaves as a sequential shifter. Some cars have park behind first. Some have it after fifth. I wasn't really trying to comment on the customizability of an interface as much as I was on the idea of a standard interface. Actaully, I had a more well thought out post first, but then my browser crashed. I just tried to cram all my thoughts back into the re-post. The customizability part should have just been thrown out.
The reason for the car analogy in the first place is that most people seem to have a complete disconnect when thinking about user interfaces on computers. They forget that people have been studying human machine interaction for a very long time.
I also really don't have anything against Raskin. I have a copy of his book at my work. I remember in a previous interview he said a lot of really interesting things, like how it was bad to design a cd player UI on a computer to look like a cd player like in your home. I disagree with him on that. However, he made some very convincing arguments about how there was much functionality you could add if you broke from the "like the real world version" model.
To help argue your point instead of trying to convince you otherwise, think about turn indicators on a car. There was one prototype where the turn indicator control on the car was connected to the steering wheel (not the column, the wheel). After all, motorcycle turn indicators work this way. BUT, motorcycles don't turn their wheel all the way around like a car. Imagine the disdain of the driver when they wanted to cancel their turn indicator in the middle of a turn. Same thing with radio stations or cruise control. Fortunately, you don't use cruise control in the speed region where you twist your steering wheel all the way around. Basically, that became the design rule use by the big three auto makers: if you might need to use something in the middle of a sharp turn, don't put it on the steering wheel (except the horn, which is often in the middle or symmetrically represented on the sides). Some standardization is good.
Now devil's advocate: I use a car and a motorcycle. In my motorcycle, my throttle is on the right, but so is the brake. My shifter is on the left. My turn indicators don't automatically cancel. I use hands for things that I use my feet for in the car. Should we standardize the interface for motorized vehicles? Probably not.
On motorcycles, people do make functional changes more analogous to skins. My shifter shifts up by pressing up with my toe. I have a number of friends who race and like to upshift pressing down. The difference between upshifting and downshifting in a turn can mean life or death consequences. I don't ride their bikes because their customization render the interface unusable for me. Perhaps in an environment where you need to pool resources standardization is good. I still think that the added productivity to an individual by allowing customization is worth it in an environment where resources are more or less owned by an individual. YMMV
I agree. Something to think about: A car is the most time critical interface that most people deal with. Take your eyes off the road for 8 seconds to change the radio station while a child crosses the street. And yet, most people manage NOT to kill someone with their car. These are the same people that bitch and moan about computers being hard to use. Anyway, everyone has a certain ammount of customization to their car. They use their favorite radio station. They adjust the seat. They roll down the windows. They adjust the mirrors. Should these things be standardized? Absolutely not. Sure, I found it a pain to have to adjust the seat after my girlfriend drove me home, but it was definitely better than her driving without reaching the pedals.
Computer interfaces are analogous; "I like it" IS a good reason to change your interface. Comfort with a tool improves productivity.
Besides, it would be difficult to have anyone find a comprehensive set of widgets without overwhelming even the best user. There is a big difference between multi-line and single line text boxes (press the enter key when there is a default button on the screen). Or tri-state vs. binary check boxes. Or the hundreds of ways a calendar could be used. If the functionality of something is different, should the look be different? What about the grids in Access vs. the grids in excel?
I agree that skins that move the window resizing controls around might have a learning curve for a guest at a machine. But is it bad? A slight loss of productivity for a guest for a comfort increase for the main user is probably worth the tradeoff. I know that I like changing my window background to 20% grey. It provides enough contrast without blasting my eyes with bright white light. Just because a text box functionally mimics paper and ink doesn't mean that it needs the same colors. And think about editors with syntax highlighting. I may browse code looking mostly at braces. I damn well want my braces to stand out. You might browse code by comments, whereas I find them distracting, so you choose a high contrast comment color and I choose a low contrast color. Because we are different, we have difficulties at each other's machines, but it's a lot better than each of us being less productive most of the time.
Of course, I may just be full of dung.