yeah, right... (i'm referring to the parting blurb in the article).
most of the remaining problems are in management:
how to play politics
how to lie
how to steal
how to cheat
how to get a raise
how to lie about yourself
how to steal credit from others
how to cheat the clock/schedule
how to survive upper management ax swinging "problems"
how to lie about other people
how to steal from the customer/client
how to cheat the regulators/analysts
the dude is dropping out from tech and going directly into management
w/o any grounding. that will only add to the problem; he will be like the
puppies before napoleon and squealer...
it is faster to have four keys, each corresponding to one of the bits of a
hex digit, that are pressable at the same instant (chording, like the
courtroom transcribers). in this way, w/ eight fingers on the home row, i
suppose a nice clean octet could be entered per duty cycle...
people who live near and around violent conflict are not happy when
other people incite more violent conflict, especially if those other people
can live far away and remain ignorant of the situation on a day to day
basis. it's that simple. forget about "duty" and other idealism.
think family and safety of infrastructure (like public transportation).
if this explanation is insufficient, you probably haven't done a good job
letting go of the idealism. work on it some more; it is not always necessary
to carry that monkey.
societal repression through loss of personal respect and dignity at the
hands of
intransparent authority
is not new either. novelty plays only a very
small part in
deciding
the merit (or demerit as the case may be) of the
situation. of course, everyone must decide for themselves, and some people
choose to weight novelty heavily in their process. perhaps it is those
people you are trying to influence.
it is not that people don't understand your standard,
they simply think it is irrelevant. when you understand
this w/o fear, you may begin to revise your standard.
that (nicely succinct) phrase applies not just to software, but to
the creators of software as well. no reflection, thus no control,
thus growth is a happenstance, thus death is misunderstood. and we
know what yoda sez about that...
hmm, i just read the regex explanation page linked by some poster above.
if that is representative of the forthcoming design (i dunno, i am a perl
ignoramus due to other pressing Problems:-) it seems to me that the only
thing that will be happening in 20 years time perl-wise will be "legacy
systems migration" w/ perl being the legacy system in question. why?
because, despite whatever elegance the expert may be able to glean from the
new regexp design, shoehorning proper grammar construction (and hence proper
grammar construction tools) into a dilletante programmer's already-exploding
head will result in mostly badly copied snippets from some google page that
works 90 percent of the time, fails 5 percent of the time w/ error, and fails
5 percent of the time w/o error.
this will be enough to "get a project rolling" straight into the ditches
from a maintenance standpoint. experts being more expensive than ever, the
wily cya-mindset hiring manager will avoid this scenario at all costs. so,
for those refining their perl chops, if you are not successful you will be the
source of these future headaches, and if you are successful you will be the
underling of a stressed not-so-wily ninny who wishes he/she had stuck w/ java
like the other ninny, and in projecting that latent wish (stemming from the
desire to be wily THIS time), he/she will make your life hell. that which you
know will be used to delete that which you know and love.
i read other comments stating things along the lines of "perl 6 design
represents a paring of inessentials". that sounds a lot like scheme if you
ask scheme heads (you can't beat "read" implemented in 64 bytes or less).
syntax is surface. if you want to parse, learn the parsing algorithms
beneath. attachment is the root of suffering.
wow, if i repeat after you, that is a high correlation (of something)!
but, as you point out, there is no guarantee that this would produce the
expected effect (presumably, learning the lesson "correlation is not
causation"). in fact, my scatterbrain might just desensitize to the message
completely and actually reverse my understanding of logic resulting in even
more gaffs and blunders!
(experiment for kids at home: say "New Jersy" 100 times out loud. when
you are finished, see how strange that sounds....)
we now return you to your regularly scheduled slashdot rantings...
i already found a bug and haven't even looked at the code in question:
separate QA and programming "teams". when the inherent reflection required of
Quality assurance is excised from the responsibilities of those w/ write
privs, well, it's no surprise that quality is not assured. in fact, it's
almost guaranteed that quality is censored.
please don't advise new programmers to study usloth or the misbegotten
practices used there. instead, they would do well to read zamm by pirsig,
tool about a bit on two wheels to have fun w/ the art of equilibrium, and move
the code about in their heads instead of through their fingers.
society is not a computer, but lawmakers should still emulate the mindset
of (good) programmers to the benefit of society. a good programmer and a good
lawmaker would understand the failure modes of their programs, the overall
architecture of what they have Wrought, and the acceptable workarounds (or
better yet bug fixes) to be applied. the merit in both positions lies in
accountability, vision and care for the Artifact.
if you are a good programmer first, consider branching into politics as a
generalization of your skillset evolution. if you are a politician first,
however, please stay away from computers.
the activity of assigning blame is rather pointless.
but having said that, it must also be observed that independence of
intention (what you're describing) is also pointless (in two ways): the
paycheck negates the independence, and lack of transparency in the process
subsumes the intention.
if you can see this and how it is inherent in the system, you can see why
self-respecting programmers working for usloth must harbor severe neuroses due
to the cognitive dissonance involved. one wonders if they would have a better
time killing that monkey, instead of helping to spread misery to the world.
it's true, the ego is a lion and must take the lion's share, but even the
lion falls to age if not to wisdom.
if you're running windows, you have already lost.
usloth is a marketing company; their products are spyware.
this may be unpleasant to acknowledge, so forget about the names
of things, and categories, etc. look at the behvior: software
running outside your purview that transmits arbitrary personal
information to someone else.
if you are willing to accept this behavior, that's fine. but if not,
install free software and, once you have
regained your dignity, help others do the same.
but the subject is people (who happen to type at computer keyboards to
(sometimes) produce useful artifacts). and people is something you seem to
not include in your analysis. there is logic and there is nuance, and there
is the art of conveying each through the other. you can ignore the OP's
points as you wish but by doing so you put at risk your own growth.
not only quick to judge, but very judgemental as well, eh?
can you apply these ablities to yourself, i wonder?
here's another one to add to your mental profiling masterplan: "usloth".
i use it on occasion, so you might as well plonk me now to save yourself the
trouble later. (that is, unless you are quick to judge but slow to act.:-)
i agree w/ you generally; these "elites" are a strange sort.
their circle is dot-sized, enforced by a bought-out court.
what do they know of the suffering of those around?
what do they care of the ignorance that so abounds?
concentrate power for inevitable abuse.
delegates cower to preserve the livelihood noose.
but "elite" isn't so bad if the elitism fits.
e.g., the most elite hackers don't proprietize bits.
their elitism flows from a practiced philosophy.
(they're really good at it, probably better than you and me.)
let us aspire to be elite in that same mode,
to write the right stuff even if it's
lame code.
most management is very relevant to the bottom line: the more management,
the smaller the number on the bottom line. ask any business what is the
largest expense? answer: payroll. now figure out management's fraction.
most of that number is overhead; most payroll spent on management finances
internecine turf wars and behind-closed-doors politicking, rather than
anything actual useful to the customer/client (i.e., products/services). "to
manage" is interpreted as "to dictate" rather than "to support", and from
there flows lots of problems, and to there flows lots of (wasted) money.
the best thing programmers can do is to learn to self-manage and go
independent (not so easy, but not so hard on a small scale, either).
hopefully at that point their ethics as developed from actually doing work
evolve into something better than that found in all the overhead they have
replaced. before anyone jumps all over this assertion, consider the pov that
programming is already a form of management. the trick is to apply
code-specific skills more widely, that's all.
what are code-specific skills?
reading source:: understanding a process (for example a "business initiative")
writing source:: implementing a process
writing documentation:: explaining the process to the Board
writing/tuning the build procedure:: what does the vp of operations do?
fixing bugs:: is low market share a bug?
refactoring code:: squeezing the suppliers, 'nuff said
anyway, these are not a direct-mapping but hopefully the less literal-minded
will get the picture. anyway, good luck to all ethical programmers!
Slashdot Mirror
yeah, right... (i'm referring to the parting blurb in the article).
most of the remaining problems are in management:
the dude is dropping out from tech and going directly into management w/o any grounding. that will only add to the problem; he will be like the puppies before napoleon and squealer...
it is faster to have four keys, each corresponding to one of the bits of a hex digit, that are pressable at the same instant (chording, like the courtroom transcribers). in this way, w/ eight fingers on the home row, i suppose a nice clean octet could be entered per duty cycle...
people who live near and around violent conflict are not happy when other people incite more violent conflict, especially if those other people can live far away and remain ignorant of the situation on a day to day basis. it's that simple. forget about "duty" and other idealism. think family and safety of infrastructure (like public transportation).
if this explanation is insufficient, you probably haven't done a good job letting go of the idealism. work on it some more; it is not always necessary to carry that monkey.
engineering w/o management is art, so it is said. art is certainly fun for the artist...
societal repression through loss of personal respect and dignity at the hands of intransparent authority is not new either. novelty plays only a very small part in deciding the merit (or demerit as the case may be) of the situation. of course, everyone must decide for themselves, and some people choose to weight novelty heavily in their process. perhaps it is those people you are trying to influence.
it is not that people don't understand your standard, they simply think it is irrelevant. when you understand this w/o fear, you may begin to revise your standard.
shhh, don't tell my yeast bud friends (or is that friend, singular?)...
you are almost completely right. include blurb on temporality to be completely right.
alternatively, you can mention human "or" equivalence to logical "xor".
that (nicely succinct) phrase applies not just to software, but to the creators of software as well. no reflection, thus no control, thus growth is a happenstance, thus death is misunderstood. and we know what yoda sez about that...
that would be called "premature attaculation". :-/
hmm, i just read the regex explanation page linked by some poster above. if that is representative of the forthcoming design (i dunno, i am a perl ignoramus due to other pressing Problems :-) it seems to me that the only
thing that will be happening in 20 years time perl-wise will be "legacy
systems migration" w/ perl being the legacy system in question. why?
because, despite whatever elegance the expert may be able to glean from the
new regexp design, shoehorning proper grammar construction (and hence proper
grammar construction tools) into a dilletante programmer's already-exploding
head will result in mostly badly copied snippets from some google page that
works 90 percent of the time, fails 5 percent of the time w/ error, and fails
5 percent of the time w/o error.
this will be enough to "get a project rolling" straight into the ditches from a maintenance standpoint. experts being more expensive than ever, the wily cya-mindset hiring manager will avoid this scenario at all costs. so, for those refining their perl chops, if you are not successful you will be the source of these future headaches, and if you are successful you will be the underling of a stressed not-so-wily ninny who wishes he/she had stuck w/ java like the other ninny, and in projecting that latent wish (stemming from the desire to be wily THIS time), he/she will make your life hell. that which you know will be used to delete that which you know and love.
i read other comments stating things along the lines of "perl 6 design represents a paring of inessentials". that sounds a lot like scheme if you ask scheme heads (you can't beat "read" implemented in 64 bytes or less). syntax is surface. if you want to parse, learn the parsing algorithms beneath. attachment is the root of suffering.
you must die, period. (so must everyone.)
what matters is what you do before you die.
chiu` hom nai khong duoc ngu? ngong. chiu` ngai` mai khong duoc di ve^`. dai. qua', o^ng dinh, dai. qua'!
wow, if i repeat after you, that is a high correlation (of something)! but, as you point out, there is no guarantee that this would produce the expected effect (presumably, learning the lesson "correlation is not causation"). in fact, my scatterbrain might just desensitize to the message completely and actually reverse my understanding of logic resulting in even more gaffs and blunders!
(experiment for kids at home: say "New Jersy" 100 times out loud. when you are finished, see how strange that sounds....)
we now return you to your regularly scheduled slashdot rantings...
i already found a bug and haven't even looked at the code in question: separate QA and programming "teams". when the inherent reflection required of Quality assurance is excised from the responsibilities of those w/ write privs, well, it's no surprise that quality is not assured. in fact, it's almost guaranteed that quality is censored.
please don't advise new programmers to study usloth or the misbegotten practices used there. instead, they would do well to read zamm by pirsig, tool about a bit on two wheels to have fun w/ the art of equilibrium, and move the code about in their heads instead of through their fingers.
this means:
the politicians have won!
that is, they have succeeded in dragging everyone down to their level. let us all muck about in our own spit, what a wonderful world.
society is not a computer, but lawmakers should still emulate the mindset of (good) programmers to the benefit of society. a good programmer and a good lawmaker would understand the failure modes of their programs, the overall architecture of what they have Wrought, and the acceptable workarounds (or better yet bug fixes) to be applied. the merit in both positions lies in accountability, vision and care for the Artifact.
if you are a good programmer first, consider branching into politics as a generalization of your skillset evolution. if you are a politician first, however, please stay away from computers.
the activity of assigning blame is rather pointless.
but having said that, it must also be observed that independence of intention (what you're describing) is also pointless (in two ways): the paycheck negates the independence, and lack of transparency in the process subsumes the intention.
if you can see this and how it is inherent in the system, you can see why self-respecting programmers working for usloth must harbor severe neuroses due to the cognitive dissonance involved. one wonders if they would have a better time killing that monkey, instead of helping to spread misery to the world. it's true, the ego is a lion and must take the lion's share, but even the lion falls to age if not to wisdom.
if you're running windows, you have already lost. usloth is a marketing company; their products are spyware. this may be unpleasant to acknowledge, so forget about the names of things, and categories, etc. look at the behvior: software running outside your purview that transmits arbitrary personal information to someone else.
if you are willing to accept this behavior, that's fine. but if not, install free software and, once you have regained your dignity, help others do the same.
outtakes from the "Great Unseen Movies" vault...
"woah, you were the one who hacked the IRS db?!"
"no, actually, i had to find and fix that bug. damn EBCDIC."
"oh, well... never mind."
but the subject is people (who happen to type at computer keyboards to (sometimes) produce useful artifacts). and people is something you seem to not include in your analysis. there is logic and there is nuance, and there is the art of conveying each through the other. you can ignore the OP's points as you wish but by doing so you put at risk your own growth.
i can relate.
ratpoision, emacs, and rxvt is all i really need to have fun w/ computers.
viva diversita! (ymmv, flames to /dev/null).
not only quick to judge, but very judgemental as well, eh? can you apply these ablities to yourself, i wonder?
here's another one to add to your mental profiling masterplan: "usloth". i use it on occasion, so you might as well plonk me now to save yourself the trouble later. (that is, unless you are quick to judge but slow to act. :-)
i agree w/ you generally; these "elites" are a strange sort.
their circle is dot-sized, enforced by a bought-out court.
what do they know of the suffering of those around?
what do they care of the ignorance that so abounds?
concentrate power for inevitable abuse.
delegates cower to preserve the livelihood noose.
but "elite" isn't so bad if the elitism fits.
e.g., the most elite hackers don't proprietize bits.
their elitism flows from a practiced philosophy.
(they're really good at it, probably better than you and me.)
let us aspire to be elite in that same mode,
to write the right stuff even if it's lame code.
most management is very relevant to the bottom line: the more management, the smaller the number on the bottom line. ask any business what is the largest expense? answer: payroll. now figure out management's fraction. most of that number is overhead; most payroll spent on management finances internecine turf wars and behind-closed-doors politicking, rather than anything actual useful to the customer/client (i.e., products/services). "to manage" is interpreted as "to dictate" rather than "to support", and from there flows lots of problems, and to there flows lots of (wasted) money.
the best thing programmers can do is to learn to self-manage and go independent (not so easy, but not so hard on a small scale, either). hopefully at that point their ethics as developed from actually doing work evolve into something better than that found in all the overhead they have replaced. before anyone jumps all over this assertion, consider the pov that programming is already a form of management. the trick is to apply code-specific skills more widely, that's all.
what are code-specific skills?
- reading source
:: understanding a process (for example a "business initiative")
- writing source
:: implementing a process
- writing documentation
:: explaining the process to the Board
- writing/tuning the build procedure
:: what does the vp of operations do?
- fixing bugs
:: is low market share a bug?
- refactoring code
:: squeezing the suppliers, 'nuff said
anyway, these are not a direct-mapping but hopefully the less literal-minded will get the picture. anyway, good luck to all ethical programmers!