Re: Check a radio button

So what makes you think that if you bang your head against the wall, things
will get better sometime in the future? You've just confirmed that you'd
seen no good changes in the last 40 years. There will always be good
programmers and bad programmers.

Isn't it a sign from above that it's time to relax and let things be? And
express some gratitude for the job security that you have?

If I was teaching first graders, I would never consider a question "what is
2 times 2" a ridiculous one. You've got more skills, which is only natural
after 40 years. Some people who ask questions are probably making their
first steps in MFC. No real reason to tell them how ridiculous their
questions are.



"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:up6v53pd6i0c5ndmodq89qorvmpco7qiut@xxxxxxxxxx
I answer intelligent questions constructively. But people who make
ridiculous statements
are not likely to get useful help. They are more likely to be told their
question is the
wrong question to ask.

Statements about writing code from scratch without using wizards, not
using control
variables, and a large collection of other questions which are based on
poor programming
practices are likely to get comments that I think they deserve.

The problem is that I *DO* end up dealing with this code; it gets handed
to me with a list
of problems, and I usually end up fixing the problems by rewriting the
code to follow
reasonable practice. Unbounded blocking operations in the main GUI
thread, attempts to
emulate sequential programming in an asynchronous event-based systems,
refusal to use
mutexes because "they are too complicated" (they are the simplest of the
synchronization
primitives), writing multithreaded code without a clue about
synchronization, I get all of
these. Most of the bad code results from a failure to exercise common
sense. Writing
code for a PDP-11. Following K&R examples for coding style. Writing bad
FORTRAN in C++.
Using GetDlgItem when it is not only not required, but not even sensible.
Arguing that
adding a member variable increases the size of a structure and pretending
this argument
even makes sense. Compounding kludges on top of kludges that add to the
complexity of
code without actually contributing anything to the solution. Believing
that everything
must get better and absolutely nothing must change. I see EXACTLY the
same mistakes being
made today that I saw being made forty years ago, thirty years ago, twenty
years ago, a
decade ago, for the same bad reasons, and frankly I'm tired of seeing
them. I'm tired of
people who think that "it works" is the sole necessary justification for
outrageous code.
Who think that if you put enough global variables and externs in, and make
everything
public, and include everything everywhere, as long as it compiles, it must
be good code.

The notion that you can bash it with a hammer until it fits is no longer
viable as a
programming paradigm.

My first memorable encounter with a truly bad programmer was someone who
was writing
synchronization primitives for our operating system project. We needed to
write two
functions, P(sem) and V(sem). He designed the interface as being PV(sem,
int) where an
int value of 1 meant P(sem) and an int value of 0 meant V(sem). Why?
BECAUSE IT SAVED
TEN INSTRUCTIONS. This was on a machine that had 8MB of physical memory
and 4GB of
virtual memory. He added gratuitous complexity for the wrong reason. I
couldn't even
imagine why someone would think this way. Yet I see it happening again
today. Forty
years later.

I've watched products fail because of bad decisions, bad coding practices,
and compounding
of kludges resulting in unmaintainable code. I no longer have patience
with bad
decisions, no matter who makes them. I no longer have patience with
fabricated excuses
for making bad decisions, or ex-post-facto rationalizations for making
them. Programming
is hard enough without adding gratuitously bad decisions to the process to
make the
problems even worse. We struggle every day with massively complex
problems, and the
secret of success is to make sure the ONLY problems we have are the ones
along the way to
the solution, not ones we introduce based on erroneous assumptions and bad
practice.

joe
On Thu, 31 May 2007 20:29:46 -0700, "Ashot Geodakov"
<a_geodakov@xxxxxxxxxxxxxxxxxx>
wrote:

Comments:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:6jtu53h53c5eqd0fhljqsq3t4mr7m6qgu5@xxxxxxxxxx
As I said in an earlier post, it is bad to become an enabler. It is
better to educate
people in what they have to do in order to do the job right, not just
roll
out something
that gives the illusion that it works this week, but is actually a time
bomb waiting to
detonate. The problem is one of attitude adjustment. Someone who wants
changes without
change is living in a dream world.

If you think that educating someone can be achieved by ridiculing them,
you
are wrong. It only discourages people who need help to come and seek help
in
this newsgroup.

Back when I was in elementary school, our teacher loved to pick on a
student
and make him or her a laughingstock of the entire group. As the result,
the
grades fell not only for that student, but for the entire group. Everyone
became too anxious not to screw up, thus killing the initiative.

There are too many products, good and bad, out there for you to worry
about
someone's education level. Chances are, you'll never deal with the code
that
the person who asked the question writes. Why not to just give a straight
answer to a straight question?

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm


.