Not entirely sound. I bought a house aged 20 and then house prices slid over the next 5 years. 5 years later (after earnings inflation) I could have bought my house for 20% less.
So, whilst buying early is good, the most important less in investment is always buy low
I agree, software is mathematics, and problem solving in it is basically a case of functional composition. Give me a software problem that is possible in software, and I can solve it.
But give someone a problem like "cure cancer" and the answer cannot be broken down. People have to try and fail, try and fail. And eventually succeed. One that knowledge is known, all that trial and error would have been worthless.
Unless drug research was done by public bodies, no progress would be made because no private research would happen.
What if you already know how to, but choose not to?
What about the damage you've done to the understanding and complexity of the code through optimising, and the subsequent increase in cost to every further change? Keep the code as simple and as close to the business requirements as is possible.
As for AMD, they only make faster processors because of the competition. Completely different metaphor (unless you are writing software that has to outrun a competitor's).
Re:As a woman in IT, I somewhat agree with the par
on
Women Leaving I.T.
·
· Score: 1
You seriously don't sound like any programmer I've met! Most teams I've met in companies of "tools" developers (like low level stuff) have been men. Most sysadmins are men (in fact, I can't think of a single woman sysadmin).
Like I say, most women I've met are more business orientated and for a massive amount of work in programming in business, that's the most useful thing.
I've been in IT since the mid 80s, and recall things we used to do for data, like playing around with packing multiple flags into a single byte as bits. That took people being more clever with the code. I haven't done things like that for years - storage is just so cheap.
The biggest problem I see in software is understanding of user requirements. The closer that programmers can be to that, the more chance of a better solution.
I avoid optimisation for its own sake. Optimisation often means more code, or harder to understand code, and that means more expensive code. Sometimes, it's the right thing to do, though.
I know women in IT who love what they do. They got into it through things like maybe mathematics. They are developers who right software.
However, they couldn't care two hoots about next years language unless it does something considerably more for them than what they've got now. They are interested in delivering the job for the business.
I'm glad you like the constant change. The constant change should be upwards. We should be seeing new 4GL tools that reduce the amount of code and closer to the business (thus raising understanding) giving us greater productivity. But most companies are just pumping out newer versions of programming languages with newer libraries. It's not helping productivity, and the changes to programming languages often introduce more risks.
The learning should be upwards. We should be learning more about our users and business, and the tools should be virtually standing still. That would improve productivity.
Incidentally, most of them work damn hard. They're not the ones on the net playing shockwave games.
I suppose the answer I'm trying to make is, are you considering what the best value solution is that you are building your solution, or the cleverest?
I once got advised to write something not in one language, but another (that is, not using our standard programming language). The answer came back "because it will run faster". Had that system been the main input system for the business which was taking large volumes of transactions, building it for optimisation may have been a good point. However, it was estimated to receive low volumes, in which case, what really mattered was not speed, but how cheap I could build it and how easy it would be to maintain.
I've seen programs get optimised by developers without asking the question: could we just buy new PCs? If a system is used by a small number of people, replacing the PCs is cheaper.
I've met developers who hate 3rd party components, probably something to do with that part of it being fun, even though the component would be a lot cheaper. Now, 3rd party bits have the downside of not having code available and not being as maintainable (and so should be thought into the cost), but often cost a lot less to buy than build.
Who said anything about just being interested in a pay check? Being a professional means getting the job done for the client.
I count myself as a professional who does geeky stuff as and when I need to. If I can keep it simple I do. Doesn't mean I do it for the money. If I just wanted money, I'd become a commodity broker and retire after a few years.
Good IT Types are not necessarily mathematicians. A reasonable grasp of algebra and logic is important, but I'd hardly equate those two things with being a "mathematician".
All your other stuff doesn't matter that much. Plenty of computer jobs I've had have required very little lifting or plugging in - the networks department do it all.
Male geeks are terrible for ultra elegant solutions beyond what is required. Things abstracted to the nth degree for a system. Code optimized for a one-off run that's no hurry.
I've found women programmers better collaborators too. When the count of women drops, there's a general trend towards the documentation and standards going too.
I've worked mostly in IT departments and whilst I wouldn't favour a woman over a man in recruitment, I've noticed certain things about women I worked with.
Primarily, they are more professional than male programmers. They get the code built, it's generally better tested and better documented. They don't "play" with the systems, they use them as a tool.
Now, it may be that not "playing" has a small downsize. That by "playing", you learn the fine stuff that may help you optimize code better.
The thing is, for most of the time in most computer departments, code optimization is just not the issue in computing any more. Space is incredibly cheap. Buying a new machine is often a cheaper and simpler solution.
It shouldn't be all monk-like. Monk-like behaviour is fine when you are working for yourself. In an IT department, you want people talking to each other, sharing ideas, working out common strategies.
In departments where I've seen too many geeks get a foothold, these things go. Documentation ends up pisspoor. You end up with people writing stuff in their own choice of languages that no-one else supports, or deciding that they'll do things their own way for whatever reason.
Flexibility is good, but IT departments should be about collaboration, ensuring that what you create is an asset for everyone, that if you code something, someone else can pick it up and change it easily.
The thing is, just how much tweaking should we need anymore?
I know guys who tweak systems because it's interesting to them, beyond the requirement of the task at hand.
Things only need to be as fast as they need to be. If a report has to be generated overnight and takes 4 hours, it doesn't matter. Optimising it to 2 hours benefits no-one.
I'd also argue that "the subject" shouldn't be about stuff like optimization and hacking around. We should be using tools to deliver as much functionality as reliably, cheaply and quickly as we can, and with good maintainability. If the machine is too slow, buy a faster one.
As for slackers and hangers on, I know women who've been in software for 15-20 years and hate what is now happening, that geekdom has taken over, and chaos is happening in computer departments.
I said in another post (to back your anecdote). 3 of the best 5 programmers I've ever had work for me were women (incidentally, the top 1 was male, but the next 3 were female).
That is fucking bullshit. There were quite a lot of women in IT pre-bubble, and I never noticed the numbers shifting.
And to your point about "men who spend their entire adolescence in the basement working on computers are better at computers than those who do not", I would dispute that. The reason is that being an IT developer is about much more than clever coding.
I knew a technically clever male programmer. He could do amazing code optimizations. I once asked him why he did it, and he said "to make it faster" and then I said "to what end". He could only answer on the basis that it was a good thing. Women I know would optimize for one reason - because the run time was presenting the business with a problem.
Women programmers I know are generally more prone to do what gets the job done. They'll not go upgrading tools just for the sake of it.
Of all the people I managed as a project manager, I'd mostly rather pick non-geeky types (ie people who didn't spend their childhood stuck in their parents basement). Programming is more and more not about setting compiler options to squeeze 1% out, it's about maintainability, collaboration and cost.
It's also discouraging for business. It probably means the geeks are totally in charge of software development, and even less productive work will be done.
I work as a man, and of my top 5 all time developers (the ones who got the fucking job done instead of pissing about, the ones who delivered for my projects), 3 were women.
Not only that, they don't care about whizz-bang gadgetry as a rule.
The ones I've met are interested in delivering, not finding out how some bizarre API that takes off an unnecessary 1% of their runtime works.
IT departments are full of big kids now, not professional programmers. One male IT manager I know has to keep telling people the rules (like write only in the languages I tell you to, use certain common subroutines) and people keep on breaking the rules to have their own little geek fiefdoms.
Slashdot Mirror
So, whilst buying early is good, the most important less in investment is always buy low
I know there was the problem with the Sonny Bono act, but I could understand different interpretations of the USC in that case.
I've not been following too carefully, but what makes you say they'll go against Grokster?
But give someone a problem like "cure cancer" and the answer cannot be broken down. People have to try and fail, try and fail. And eventually succeed. One that knowledge is known, all that trial and error would have been worthless.
Unless drug research was done by public bodies, no progress would be made because no private research would happen.
If someone sent me a subpoena and I wasn't guilty, the first thing I'd do is contact my lawyer and explain the situation.
Apart from moral questions, it's not even productive. Find where people are good and work with their strengths.
That's because I'm male.
What about the damage you've done to the understanding and complexity of the code through optimising, and the subsequent increase in cost to every further change? Keep the code as simple and as close to the business requirements as is possible.
As for AMD, they only make faster processors because of the competition. Completely different metaphor (unless you are writing software that has to outrun a competitor's).
Like I say, most women I've met are more business orientated and for a massive amount of work in programming in business, that's the most useful thing.
I've been in IT since the mid 80s, and recall things we used to do for data, like playing around with packing multiple flags into a single byte as bits. That took people being more clever with the code. I haven't done things like that for years - storage is just so cheap.
The biggest problem I see in software is understanding of user requirements. The closer that programmers can be to that, the more chance of a better solution.
I avoid optimisation for its own sake. Optimisation often means more code, or harder to understand code, and that means more expensive code. Sometimes, it's the right thing to do, though.
I know women in IT who love what they do. They got into it through things like maybe mathematics. They are developers who right software.
However, they couldn't care two hoots about next years language unless it does something considerably more for them than what they've got now. They are interested in delivering the job for the business.
I'm glad you like the constant change. The constant change should be upwards. We should be seeing new 4GL tools that reduce the amount of code and closer to the business (thus raising understanding) giving us greater productivity. But most companies are just pumping out newer versions of programming languages with newer libraries. It's not helping productivity, and the changes to programming languages often introduce more risks.
The learning should be upwards. We should be learning more about our users and business, and the tools should be virtually standing still. That would improve productivity.
Incidentally, most of them work damn hard. They're not the ones on the net playing shockwave games.
I once got advised to write something not in one language, but another (that is, not using our standard programming language). The answer came back "because it will run faster". Had that system been the main input system for the business which was taking large volumes of transactions, building it for optimisation may have been a good point. However, it was estimated to receive low volumes, in which case, what really mattered was not speed, but how cheap I could build it and how easy it would be to maintain.
I've seen programs get optimised by developers without asking the question: could we just buy new PCs? If a system is used by a small number of people, replacing the PCs is cheaper.
I've met developers who hate 3rd party components, probably something to do with that part of it being fun, even though the component would be a lot cheaper. Now, 3rd party bits have the downside of not having code available and not being as maintainable (and so should be thought into the cost), but often cost a lot less to buy than build.
I count myself as a professional who does geeky stuff as and when I need to. If I can keep it simple I do. Doesn't mean I do it for the money. If I just wanted money, I'd become a commodity broker and retire after a few years.
The fact that there's a grammatical mistake, and therefore I'm not perfect doesn't mean that what I've said doesn't warrant discussion.
If I'm not mistaken, Nazi is a proper noun and therefore should be capitalised ;)
All your other stuff doesn't matter that much. Plenty of computer jobs I've had have required very little lifting or plugging in - the networks department do it all.
That will teach me not to preview.
Male geeks are terrible for ultra elegant solutions beyond what is required. Things abstracted to the nth degree for a system. Code optimized for a one-off run that's no hurry.
I've found women programmers better collaborators too. When the count of women drops, there's a general trend towards the documentation and standards going too.
Primarily, they are more professional than male programmers. They get the code built, it's generally better tested and better documented. They don't "play" with the systems, they use them as a tool.
Now, it may be that not "playing" has a small downsize. That by "playing", you learn the fine stuff that may help you optimize code better.
The thing is, for most of the time in most computer departments, code optimization is just not the issue in computing any more. Space is incredibly cheap. Buying a new machine is often a cheaper and simpler solution.
In departments where I've seen too many geeks get a foothold, these things go. Documentation ends up pisspoor. You end up with people writing stuff in their own choice of languages that no-one else supports, or deciding that they'll do things their own way for whatever reason.
Flexibility is good, but IT departments should be about collaboration, ensuring that what you create is an asset for everyone, that if you code something, someone else can pick it up and change it easily.
I know guys who tweak systems because it's interesting to them, beyond the requirement of the task at hand.
Things only need to be as fast as they need to be. If a report has to be generated overnight and takes 4 hours, it doesn't matter. Optimising it to 2 hours benefits no-one.
I'd also argue that "the subject" shouldn't be about stuff like optimization and hacking around. We should be using tools to deliver as much functionality as reliably, cheaply and quickly as we can, and with good maintainability. If the machine is too slow, buy a faster one.
As for slackers and hangers on, I know women who've been in software for 15-20 years and hate what is now happening, that geekdom has taken over, and chaos is happening in computer departments.
I said in another post (to back your anecdote). 3 of the best 5 programmers I've ever had work for me were women (incidentally, the top 1 was male, but the next 3 were female).
I could equally say that there's plenty of shallow men out there, interested in little more than:-
Cars
Toys. Including iPods and the like.
Babes/Porn Particularly with ludicrously inflated breasts.
Beer
Crap sci-fi movies and series
Maybe they're not too interested in you. Perhaps, because you show little interest in the things they might be interested in (eg Clothes).
Actually, there's plenty of bright, interesting women, but the way your carrying on, I think the real men are more likely to get a share than you.
And to your point about "men who spend their entire adolescence in the basement working on computers are better at computers than those who do not", I would dispute that. The reason is that being an IT developer is about much more than clever coding.
I knew a technically clever male programmer. He could do amazing code optimizations. I once asked him why he did it, and he said "to make it faster" and then I said "to what end". He could only answer on the basis that it was a good thing. Women I know would optimize for one reason - because the run time was presenting the business with a problem.
Women programmers I know are generally more prone to do what gets the job done. They'll not go upgrading tools just for the sake of it.
Of all the people I managed as a project manager, I'd mostly rather pick non-geeky types (ie people who didn't spend their childhood stuck in their parents basement). Programming is more and more not about setting compiler options to squeeze 1% out, it's about maintainability, collaboration and cost.
It's also discouraging for business. It probably means the geeks are totally in charge of software development, and even less productive work will be done.
I work as a man, and of my top 5 all time developers (the ones who got the fucking job done instead of pissing about, the ones who delivered for my projects), 3 were women.
The ones I've met are interested in delivering, not finding out how some bizarre API that takes off an unnecessary 1% of their runtime works.
IT departments are full of big kids now, not professional programmers. One male IT manager I know has to keep telling people the rules (like write only in the languages I tell you to, use certain common subroutines) and people keep on breaking the rules to have their own little geek fiefdoms.