Read the duology Hyperion and Fall of Hyperion by Dan Simmons if you are looking for this type of story line. Way cool books. There are 2 other books that are sequals to the first two (Endymion and Rise of Endymion but I don't think that they are as good as the first ones).
Another option that you can do is
work through an umbrella corp. This
blends 1099 and W2 in that you are
still an employee of a company, but
depending on your umbrella corp
you can do things like deduct
business equipment (i.e. "Yes Mr
Taxman, that dual AMD is a business
expense...") More info on umbrella corps
and a small list of several:
http://rmpcp.com/umbrellas.shtml
A good place for this kindof discussion
is the Real Rates BBS, which can
also help you figure out if you are being
screwed (BTW, 60% of billing sounds like
you are getting screwed, generally it
should be around 70%). At any rate,
here is the link to the board:
Don't worry if they have the "highest performance" or if they have the "coolest widgets".
You are forgetting one thing -- software is supposed to solve problems. Sometimes those problems are "My nuclear reaction simulation doesn't run fast enough" or "People that are sight impaired can't see the button". Software, like any other engineering discipline involves a series of tradeoffs that must be made to effectively solve the problem.
Instead worry if they have the best design, if they are technically "right" for the task at hand
The best design depends highly on what you are trying to do. If you need high performance from your software (like embedded medical applications) then architectural mechanism such as layer-bridging or even (gasp) monolithic structures may be appropriate. If you are trying to design for a high degree of reuse and interoperability (as you suggest) then strict layers and delegation models are more appropriate. My point is that it is impossible to have an objective idea of the best design for all software since software in general needs to solve a wide (and largely contradictory) set of problems. The "technically 'right'" may be in direct opposition to building layered, reusable components.
Stop worrying about making languages that allow you to produce specific functionality in fewer lines of code, and worry about producing the highest level of quality
Directly contradicts
This would require that we accept standard functionality at each level of the layering process and then allow people to write ever simpler code due to this great deal of layering
One of the items discussed is charging more for insurance for those people who possess genes that may produce serious illness (sickle cell anemia, skin cancer, etc...) It seems that to be fair, then people with positive traits (e.g. genes associated with low cholesterol or healthy hearts(don't know if these are actual genes, but bear with me) should get insurance discounts. Maybe this would ultimately decrease the insurance rates for everyone...
Slashdot Mirror
Did anyone else notice that the equipment room has wood paneling? I didn't know they built cell towers in the 70's....
Read the duology Hyperion and Fall of Hyperion by Dan Simmons if you are looking for this type of story line. Way cool books. There are 2 other books that are sequals to the first two (Endymion and Rise of Endymion but I don't think that they are as good as the first ones).
Another option that you can do is
work through an umbrella corp. This
blends 1099 and W2 in that you are
still an employee of a company, but
depending on your umbrella corp
you can do things like deduct
business equipment (i.e. "Yes Mr
Taxman, that dual AMD is a business
expense...") More info on umbrella corps
and a small list of several:
http://rmpcp.com/umbrellas.shtml
A good place for this kindof discussion
is the Real Rates BBS, which can
also help you figure out if you are being
screwed (BTW, 60% of billing sounds like
you are getting screwed, generally it
should be around 70%). At any rate,
here is the link to the board:
http://pub2.ezboard.com/bcomputerconsultants
Regards,
Chooks
Don't worry if they have the "highest performance" or if they have the "coolest widgets".
You are forgetting one thing -- software is supposed to solve problems. Sometimes those problems are "My nuclear reaction simulation doesn't run fast enough" or "People that are sight impaired can't see the button". Software, like any other engineering discipline involves a series of tradeoffs that must be made to effectively solve the problem.
Instead worry if they have the best design, if they are technically "right" for the task at hand
The best design depends highly on what you are trying to do. If you need high performance from your software (like embedded medical applications) then architectural mechanism such as layer-bridging or even (gasp) monolithic structures may be appropriate. If you are trying to design for a high degree of reuse and interoperability (as you suggest) then strict layers and delegation models are more appropriate. My point is that it is impossible to have an objective idea of the best design for all software since software in general needs to solve a wide (and largely contradictory) set of problems. The "technically 'right'" may be in direct opposition to building layered, reusable components.
Stop worrying about making languages that allow you to produce specific functionality in fewer lines of code, and worry about producing the highest level of quality
Directly contradicts
This would require that we accept standard functionality at each level of the layering process and then allow people to write ever simpler code due to this great deal of layering
Regards,
Chooks
One of the items discussed is charging more for insurance for those people who possess genes that may produce serious illness (sickle cell anemia, skin cancer, etc...) It seems that to be fair, then people with positive traits (e.g. genes associated with low cholesterol or healthy hearts(don't know if these are actual genes, but bear with me) should get insurance discounts. Maybe this would ultimately decrease the insurance rates for everyone...