At this time, the United States is *not* in a state of war. If we were, we would be expected to abide by little inconveniences like the Geneva Conventions. This is the logic that Our Fearless Leaders have used to excuse their inexcusable behavior. Therefore, either we are at war and have been violating a considerable number of international laws, or we are not at war and we are expected to follow our own domestic laws, such as the phrasing of the Fifth Amendment that someone else has already mentioned -- which specifically states that it applies to any PERSON, not just to any citizen.
Which is better -- to be seen as criminals in the eyes of the rest of the world, or to be seen as hypocrites both at home and abroad?
Yes, a version control system is always a good idea. There are plenty of them out there, and different people prefer different ones. Find one you like and can use -- for a single-user setup, anything simple and reliable will work. Meostro made a good point about choosing a style and sticking to it -- you'd be surprised how much difference a consistent layout makes in being able to read your own code quickly.
I've also got a couple of suggestions for your code. Feel free to take any, all, or none of them, as it suits you.
First, I strongly recommend getting the book, "The Unix Philosophy." It isn't a technical book, and you don't have to know Unix. It is a book about one particular programming philosophy, which can probably be summed up as, "Make one small thing that does one thing very well. If you need something complicated, make it out of several small, well-made things." It is an excellent book, especially for a programmer trying to decide what his/her own programming style will be.
Second, heavily comment your code. I think anyone who has been programming long can tell you about the code that they thought they wouldn't need to comment because they'd remember what it did... and then had to look at it again six months later and wondered what on earth they'd been thinking.
Also under the heading of commenting your code, get in the habit of putting a standard header at the top of your code files, which shows the name of the module, what it does, what its input parameters are, and what output it generates. This may seem cumbersome and arbitrary at the time, but it helps immeasurably in being able to glance at a module and know what it does, and in being able to find the particular module that you're wanting to re-use.
Third, keep hard-coding of values to an absolute minimum -- they limit the versatility of your module. Parameterize them instead.
Fourth, avoid "magic numbers" -- if you have a numeric value that is being used, strongly consider assigning it a variable name instead. Otherwise, you'll find yourself looking at code that has something like this:
and you've decided that you need to change the '24' in the first formula... but do you need to change it in the second one, too? Do those two numbers need to stay the same, or did they just happen to be the same in this case?
I agree -- the manager's job is to manage, not to code. In fact, according to the Fair Labor Standards Act, a supervisor should spend no more than 20% of his workday in "non-managerial activities" -- in particular, doing the same tasks as those 'under' him.
That said, the manager needs to have a clue about what his people do and how they do it. I think the worst manager I ever had was one of these who thought that management skills were universal, so a good manager could do a good job managing any group of people, even if he had no experience at all with their type of tasks.
On behalf of your team (even if I don't know who they are), THANK YOU for not micromanaging! There are very few things I hate worse than that. Personally, I tend to take the approach of, "Tell me what you want me to do, or tell me how you want me to do it. If you're going to do both of those, you might as well do it yourself."
As for the original topic of whether I'd choose a "good team + good compensation + low utilization of skills" or "lower compensation + unknown team + higher utilization of skills," I would be *very* strongly tempted to choose the former. I *hate* being bored, and if my work isn't challenging me enough then I'll find things to do on my own, but a good team is worth their weight in gold, IMO.
Perhaps the original poster should consider keeping his current position, and taking on an independent-contrator status with the startup company, committing to a small number of hours with them (assuming they're agreeable to this). That way, he gets the best of both worlds -- great team/benefits/pay, and stimulating project work.
> A patent not only stops me from copying something that > someone else has done, but it stops me from expressing > the same thought.
To a certain degree, I agree with you, but for the most part I have to take a different position.
With any comparison, there comes a point where the analogy breaks down. Unfortunately, in comparing patents to restrictions on free speech, that analogy breaks down very quickly.
Free speech, as expressed within the Bill of Rights in the US Constitution, refers to an individual's ability to state his opinions and ideas without State censorship, so long as that individual is not harming another by those statements.
Is it free speech for me to accuse a co-worker of stealing things from my desk, when in fact there is nothing missing? Of course not - my statements are harmful to my co-worker, who is protected by slander laws.
Was it free speech (or even freedom of the press) for a reporter to release the name of a CIA operative? Of course not - revealing her name and profession was harmful to her.
Is it free speech if I take a book or magazine off the shelf at the bookstore, scan it into my computer, and put it up on the web or distribute copies? Of course not - I'm effectively robbing the author, the publisher, the distributor, the artists, etc., and that is precisely what copyright laws and patents are designed to prevent.
A patent is designed to protect the inventor's investment of time, energy, and money, as well as the investments of the inventor's backers (or in this case, employers) so that they can achieve a benefit from their investment.
If I develop a new system, patent it, and start selling it, is it wrong for someone else to copy it and distribute it as their own, whether they charge for it or not? Yes! That person is robbing me, just as surely as if they'd accosted me on the street and taken my wallet. They are stealing the fruits of my labors -- which are mine to give away *if I choose*, but also mine to sell if I choose and can find people willing to buy. (Yes, I support Open Source, but I also support capitalism.)
Patents don't prevent someone else from developing a system that accomplishes the same task (i.e. expressing their own idea), they prevent that person from stealing someone else's work. If you can develop your own way of doing the same thing, you can get your own patent. Patents aren't intended to stop you from expressing and implementing your own ideas, they are intended to protect others who have already expressed and implemented *their* own ideas.
Yes, there are plenty of things getting patented that are utterly ludicrous. Yes, the patent system could stand some serious revision. But until PatentSystem 2.0 is available, this is the only game in town.
As one of my former managers put it, this is the car that's taking us to the dance. If we want to dance, we get in the car. If you feel that strongly about the car, don't go to the dance.
I'm all in favor of Open Source, and wanting to know all the innards of the code that's running on your box. I think this is an outstanding approach to development and testing, as well as an incredible tool for people wanting to learn how to perform a particular task by letting them see an example of how someone else did something similar.
But let's be honest -- how many of the programs running on our systems have we sat down and carefully examined the code for? Five percent? Ten?
Most users assume that the majority of the code, especially the core, has been microscopically analyzed by hordes of uber-geek programmers and given it their blessing, therefore we don't need to check it ourselves.
For that matter, it's not as if all Linux code is written in one language. In order to examine all of the code on their system, a person would have to be fluent in C/C++, Perl, Java, and a host of other languages.
While I'm sure there are people who have the skills, the inclination, and the time to do this, I hope you'll forgive me if I consider those individuals to be well beyond merely "respectable Linux users."
Yes, but you have to consider the original latin roots for the word subpoena.
Sub, meaning below.
Poena, referring to the projective portion of the male genitalia.
And thus, we discover the true meaning of the word sub-poena -- "below the projective portion of the male genitalia"... or, in more common parlance, "by the balls".
Well, I can see now why you chose to write that as 'Anonymous Coward'. I'd certainly be ashamed to put my name to such a collection of unsupported rhetoric.
After all, your perspective is flawed and, unfortunately, rather selfish.
While this is a potentially accurate statement, it also contradicts your later comments about competitive advantages -- something that I'm sure those of us in business will agree is a good thing, but is also inherently "selfish".
To me and my code under the BSD licesnse, someone else is using code *I* chose to put under a BSD license. And that someone, and all the parties that end of using that code, closed or not, is benefiting from it.
Perhaps so. However, this is analagous to us agreeing that I will give your business $20MM, on the condition that you agree to give it away to other companies in your area. You accept the money, then use it as part of your companies operating funds, claiming that since you are spending it with local vendors, they are gaining the benefit. While they are gaining *some* benefit, it is not the one to which we originally agreed, and your company is taking a significantly greater benefit from it by deliberately violating our original agreement.
GPL licensing simply does not and give up that benefit for stilted present gains of a few lines (if any) of badly mangled code.
If the code was so badly mangled, why would anyone else want to use it in the first place? Yes, there is some code out there that is not particularly impressive. On the other hand, it must have *some* merits, or it wouldn't be being used.
They take their profits and distribute them to the entities that made the original code.
Really? Out of curiosity, how many documented examples of this can you provide?
Slashdot Mirror
At this time, the United States is *not* in a state of war. If we were, we would be expected to abide by little inconveniences like the Geneva Conventions. This is the logic that Our Fearless Leaders have used to excuse their inexcusable behavior. Therefore, either we are at war and have been violating a considerable number of international laws, or we are not at war and we are expected to follow our own domestic laws, such as the phrasing of the Fifth Amendment that someone else has already mentioned -- which specifically states that it applies to any PERSON, not just to any citizen.
Which is better -- to be seen as criminals in the eyes of the rest of the world, or to be seen as hypocrites both at home and abroad?
Yes, a version control system is always a good idea. There are plenty of them out there, and different people prefer different ones. Find one you like and can use -- for a single-user setup, anything simple and reliable will work. Meostro made a good point about choosing a style and sticking to it -- you'd be surprised how much difference a consistent layout makes in being able to read your own code quickly.
I've also got a couple of suggestions for your code. Feel free to take any, all, or none of them, as it suits you.
First, I strongly recommend getting the book, "The Unix Philosophy." It isn't a technical book, and you don't have to know Unix. It is a book about one particular programming philosophy, which can probably be summed up as, "Make one small thing that does one thing very well. If you need something complicated, make it out of several small, well-made things." It is an excellent book, especially for a programmer trying to decide what his/her own programming style will be.
Second, heavily comment your code. I think anyone who has been programming long can tell you about the code that they thought they wouldn't need to comment because they'd remember what it did... and then had to look at it again six months later and wondered what on earth they'd been thinking.
Also under the heading of commenting your code, get in the habit of putting a standard header at the top of your code files, which shows the name of the module, what it does, what its input parameters are, and what output it generates. This may seem cumbersome and arbitrary at the time, but it helps immeasurably in being able to glance at a module and know what it does, and in being able to find the particular module that you're wanting to re-use.
Third, keep hard-coding of values to an absolute minimum -- they limit the versatility of your module. Parameterize them instead.
Fourth, avoid "magic numbers" -- if you have a numeric value that is being used, strongly consider assigning it a variable name instead. Otherwise, you'll find yourself looking at code that has something like this:
coopsNeeded = totalChickens / 24;
wireRolls = coopFootage / 24;
and you've decided that you need to change the '24' in the first formula... but do you need to change it in the second one, too? Do those two numbers need to stay the same, or did they just happen to be the same in this case?
This, on the other hand:
coopsNeeded = totalChickens / chicksPerCoop;
wireRolls = coopFootage / foxBlockers;
avoids that sort of confusion.
I hope this helps, and good luck!
I agree -- the manager's job is to manage, not to code. In fact, according to the Fair Labor Standards Act, a supervisor should spend no more than 20% of his workday in "non-managerial activities" -- in particular, doing the same tasks as those 'under' him.
That said, the manager needs to have a clue about what his people do and how they do it. I think the worst manager I ever had was one of these who thought that management skills were universal, so a good manager could do a good job managing any group of people, even if he had no experience at all with their type of tasks.
On behalf of your team (even if I don't know who they are), THANK YOU for not micromanaging! There are very few things I hate worse than that. Personally, I tend to take the approach of, "Tell me what you want me to do, or tell me how you want me to do it. If you're going to do both of those, you might as well do it yourself."
As for the original topic of whether I'd choose a "good team + good compensation + low utilization of skills" or "lower compensation + unknown team + higher utilization of skills," I would be *very* strongly tempted to choose the former. I *hate* being bored, and if my work isn't challenging me enough then I'll find things to do on my own, but a good team is worth their weight in gold, IMO.
Perhaps the original poster should consider keeping his current position, and taking on an independent-contrator status with the startup company, committing to a small number of hours with them (assuming they're agreeable to this). That way, he gets the best of both worlds -- great team/benefits/pay, and stimulating project work.
> A patent not only stops me from copying something that
> someone else has done, but it stops me from expressing
> the same thought.
To a certain degree, I agree with you, but for the most part I have to take a different position.
With any comparison, there comes a point where the analogy breaks down. Unfortunately, in comparing patents to restrictions on free speech, that analogy breaks down very quickly.
Free speech, as expressed within the Bill of Rights in the US Constitution, refers to an individual's ability to state his opinions and ideas without State censorship, so long as that individual is not harming another by those statements.
Is it free speech for me to accuse a co-worker of stealing things from my desk, when in fact there is nothing missing? Of course not - my statements are harmful to my co-worker, who is protected by slander laws.
Was it free speech (or even freedom of the press) for a reporter to release the name of a CIA operative? Of course not - revealing her name and profession was harmful to her.
Is it free speech if I take a book or magazine off the shelf at the bookstore, scan it into my computer, and put it up on the web or distribute copies? Of course not - I'm effectively robbing the author, the publisher, the distributor, the artists, etc., and that is precisely what copyright laws and patents are designed to prevent.
A patent is designed to protect the inventor's investment of time, energy, and money, as well as the investments of the inventor's backers (or in this case, employers) so that they can achieve a benefit from their investment.
If I develop a new system, patent it, and start selling it, is it wrong for someone else to copy it and distribute it as their own, whether they charge for it or not? Yes! That person is robbing me, just as surely as if they'd accosted me on the street and taken my wallet. They are stealing the fruits of my labors -- which are mine to give away *if I choose*, but also mine to sell if I choose and can find people willing to buy. (Yes, I support Open Source, but I also support capitalism.)
Patents don't prevent someone else from developing a system that accomplishes the same task (i.e. expressing their own idea), they prevent that person from stealing someone else's work. If you can develop your own way of doing the same thing, you can get your own patent. Patents aren't intended to stop you from expressing and implementing your own ideas, they are intended to protect others who have already expressed and implemented *their* own ideas.
Yes, there are plenty of things getting patented that are utterly ludicrous. Yes, the patent system could stand some serious revision. But until PatentSystem 2.0 is available, this is the only game in town.
As one of my former managers put it, this is the car that's taking us to the dance. If we want to dance, we get in the car. If you feel that strongly about the car, don't go to the dance.
I'm all in favor of Open Source, and wanting to know all the innards of the code that's running on your box. I think this is an outstanding approach to development and testing, as well as an incredible tool for people wanting to learn how to perform a particular task by letting them see an example of how someone else did something similar.
But let's be honest -- how many of the programs running on our systems have we sat down and carefully examined the code for? Five percent? Ten?
Most users assume that the majority of the code, especially the core, has been microscopically analyzed by hordes of uber-geek programmers and given it their blessing, therefore we don't need to check it ourselves.
For that matter, it's not as if all Linux code is written in one language. In order to examine all of the code on their system, a person would have to be fluent in C/C++, Perl, Java, and a host of other languages.
While I'm sure there are people who have the skills, the inclination, and the time to do this, I hope you'll forgive me if I consider those individuals to be well beyond merely "respectable Linux users."
Yes, but you have to consider the original latin roots for the word subpoena.
Sub, meaning below.
Poena, referring to the projective portion of the male genitalia.
And thus, we discover the true meaning of the word sub-poena -- "below the projective portion of the male genitalia"... or, in more common parlance, "by the balls".
After all, your perspective is flawed and, unfortunately, rather selfish.
While this is a potentially accurate statement, it also contradicts your later comments about competitive advantages -- something that I'm sure those of us in business will agree is a good thing, but is also inherently "selfish".
To me and my code under the BSD licesnse, someone else is using code *I* chose to put under a BSD license. And that someone, and all the parties that end of using that code, closed or not, is benefiting from it.
Perhaps so. However, this is analagous to us agreeing that I will give your business $20MM, on the condition that you agree to give it away to other companies in your area. You accept the money, then use it as part of your companies operating funds, claiming that since you are spending it with local vendors, they are gaining the benefit. While they are gaining *some* benefit, it is not the one to which we originally agreed, and your company is taking a significantly greater benefit from it by deliberately violating our original agreement.
GPL licensing simply does not and give up that benefit for stilted present gains of a few lines (if any) of badly mangled code.
If the code was so badly mangled, why would anyone else want to use it in the first place? Yes, there is some code out there that is not particularly impressive. On the other hand, it must have *some* merits, or it wouldn't be being used.
They take their profits and distribute them to the entities that made the original code.
Really? Out of curiosity, how many documented examples of this can you provide?
My .02 worth,
Draconomicon