My Boss is a Butthead (but I don't want to hurt his feelings)

[jehugaleahsa]

Hello:

I had an hour-long discussion with my boss today. Last night, right
before I dozed off, I realized some of his code resulted in duplicate
processing. I tried to explain it to him and he kept saying, "I'm
afraid to say it's 'OK' to change it because everything I did was for
a reason." Well, I know better.

My boss' old code is written in some cryptic C file with Oracle
precompiler macros barfed all over it. Once I figured out how to
ignore 90% of the macro junk, it has just been an effort to keep track
of all the global variables.

I was looking at some code yesterday, converting it to pseudo code,
and I came out with this:

foreach customer, contract in table1, table2:
if (customer is in history):
isCustomer = true;
if (contract is in history)
isContract = true;
process(isCustomer, isContract);
else
isContract = false;
process(isCustomer, isContract);
else
isCustomer = false;
isContract = false;
process(isCustomer, isContract);

Just looking at the pseudo-code, you should see why I almost flipped
my lid. You can easily rewrite that is this:

foreach customer, contract in table1, table2:
isCustomer = (customer in history);
isContract = (contract in history);
process(isCustomer, isContract);

It doesn't take a master refactorer to figure that one out. (AND it is
impossible for there to be a contract without a customer) Now, how do
I tell my boss, who thinks this code is exceptionally difficult, that
he made some obvious mistakes?

He is very arrogant about how he got his code to work. I am not
impressed. I don't want to hurt his feelings by pointing out (there
are many more) his obvious mistakes and inefficiencies.

There is just too much . . . to ignore!

[Brette.Net]

On Aug 10, 12:05 pm, "[e-mail]" <[e-mail]>
wrote:

Hello:

I had an hour-long discussion with my boss today. Last night, right
before I dozed off, I realized some of his code resulted in duplicate
processing. I tried to explain it to him and he kept saying, "I'm
afraid to say it's 'OK' to change it because everything I did was for
a reason." Well, I know better.

My boss' old code is written in some cryptic C file with Oracle
precompiler macros barfed all over it. Once I figured out how to
ignore 90% of the macro junk, it has just been an effort to keep track
of all the global variables.

I was looking at some code yesterday, converting it to pseudo code,
and I came out with this:

foreach customer, contract in table1, table2:
if (customer is in history):
isCustomer = true;
if (contract is in history)
isContract = true;
process(isCustomer, isContract);
else
isContract = false;
process(isCustomer, isContract);
else
isCustomer = false;
isContract = false;
process(isCustomer, isContract);

Just looking at the pseudo-code, you should see why I almost flipped
my lid. You can easily rewrite that is this:

foreach customer, contract in table1, table2:
isCustomer = (customer in history);
isContract = (contract in history);
process(isCustomer, isContract);

It doesn't take a master refactorer to figure that one out. (AND it is
impossible for there to be a contract without a customer) Now, how do
I tell my boss, who thinks this code is exceptionally difficult, that
he made some obvious mistakes?

He is very arrogant about how he got his code to work. I am not
impressed. I don't want to hurt his feelings by pointing out (there
are many more) his obvious mistakes and inefficiencies.

There is just too much . . . to ignore!

You are between a rock and hard place. If it were me I would waste no
more time on it. I would put a comment in saying "Boss said one call
is better then two he does not know why, but he is boss" I would leave
there and move on.

PD

[Larry Smith]

You are between a rock and hard place. If it were me I would waste no

more time on it. I would put a comment in saying "Boss said one call
is better then two he does not know why, but he is boss" I would leave
there and move on.

Agreed but re-word it so he won't take exception in case he ever sees it
again. Time permitting, also clean up any obvious problems/inefficiences if
you're in the position to do so without asking him. Just make sure you don't
botch things up by accident. In any case, try to get used to this. You may
never like it but you'll be dealing with it for the rest of your career.
Believe me, most programmers in the real world write this type of code and
often much worse.

[jehugaleahsa]

I just had another hour-long discussion with my boss. I showed him
another problem that I found. After saying, "But . . . what about
this" a hundred times he finally started losing some of his
confidence.

I got him from, "Oh, I'm sure there is a reason" to "Actually, we've
never run this in production, but I tested it pretty thoroughly". So,
in short, my boss probably never even realized it, I probably found a
bug before it happened and my confidence level just got shot down 3
points.

At least now I can say, "Oh, it doesn't work? I just copied what was
already there."

BTW - I have to waste more time on it since I am converting it from C
to C#.

This is one of those cases where having a little training on what I am
working on would be helpful.

[jehugaleahsa]

Bosses should write their expectations in terms of tests, pre-
conditions and post-conditions.

[Nicholas Paldino [.NET/C# MVP]]

I hate to say it, but you are wrong in your refactoring.

In your boss' code, if the custom is not in the history, then the
contract can never be in the history. In your code, you can have a customer
in the history, and a contract not in the history. Now, it may be that the
data in the customer and contract tables will never produce that situation,
but as it stands, your code and your boss' code can potentially do different
things for the same data.

If you want your refactoring to match his, then you have to do the
following:

foreach customer, contract in table1, table2:
isCustomer = (customer in history);
isContract = isCustomer and (contract in history);
process(isCustomer, isContract);

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<je**********@gmail.comwrote in message
news:11**********************@x40g2000prg.googlegr oups.com...

Hello:

I had an hour-long discussion with my boss today. Last night, right
before I dozed off, I realized some of his code resulted in duplicate
processing. I tried to explain it to him and he kept saying, "I'm
afraid to say it's 'OK' to change it because everything I did was for
a reason." Well, I know better.

My boss' old code is written in some cryptic C file with Oracle
precompiler macros barfed all over it. Once I figured out how to
ignore 90% of the macro junk, it has just been an effort to keep track
of all the global variables.

I was looking at some code yesterday, converting it to pseudo code,
and I came out with this:

foreach customer, contract in table1, table2:
if (customer is in history):
isCustomer = true;
if (contract is in history)
isContract = true;
process(isCustomer, isContract);
else
isContract = false;
process(isCustomer, isContract);
else
isCustomer = false;
isContract = false;
process(isCustomer, isContract);

Just looking at the pseudo-code, you should see why I almost flipped
my lid. You can easily rewrite that is this:

foreach customer, contract in table1, table2:
isCustomer = (customer in history);
isContract = (contract in history);
process(isCustomer, isContract);

It doesn't take a master refactorer to figure that one out. (AND it is
impossible for there to be a contract without a customer) Now, how do
I tell my boss, who thinks this code is exceptionally difficult, that
he made some obvious mistakes?

He is very arrogant about how he got his code to work. I am not
impressed. I don't want to hurt his feelings by pointing out (there
are many more) his obvious mistakes and inefficiencies.

There is just too much . . . to ignore!

[Samuel R. Neff]

Being able to have reasonable and calm discussions about how things
are implemented is really important in any development shop. I would
say that is the main thing that needs to be fixed and probably from
both sides.

It sounds like you have some of the same issues I often do which is
starting out too negative. Instead of telling your boss what he did
wrong, start out by asking him about why it's implemented a certain
way and what can you learn from that method and should it be applied
elsewhere, things like that. If it's wrong, hopefully in discussing
it he'll realize and you'll come to a better solution together.

Always helps to start off positive and butter the other person up a
big first, especially if the other person is your boss. :-)

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

[Cowboy \(Gregory A. Beamer\)]

Syntactical errors are easy to spot, as they do not compile correctly.
Logical errors just corrupt data, if the database schema allows it. They
also only blow up on running code, which makes the nefarious.

Your refactoring leaves the possibility of a logical error. Let me show you:

Valid Logical possibilities for Process()

Customer Contract
False False
True False
True True

Your code

Customer Contract
False False
False True
True False
True True

You have to eliminate the False/True option, as Nicholas has stated. This
may not be possible, per your database, but it is wise to design libraries
so future logical errros cannot creep in. While you boss was very verbose,
he eliminated the possibility of a logical error.

You could also have a check for the bad condition, in the Process() routine
and throw an exception if processed that way. But, I would still fix the
code you are fixing. :-)

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
Co-author: Microsoft Expression Web Bible (upcoming)

************************************************
Think outside the box!
************************************************
<je**********@gmail.comwrote in message
news:11**********************@x40g2000prg.googlegr oups.com...

Hello:

I had an hour-long discussion with my boss today. Last night, right
before I dozed off, I realized some of his code resulted in duplicate
processing. I tried to explain it to him and he kept saying, "I'm
afraid to say it's 'OK' to change it because everything I did was for
a reason." Well, I know better.

My boss' old code is written in some cryptic C file with Oracle
precompiler macros barfed all over it. Once I figured out how to
ignore 90% of the macro junk, it has just been an effort to keep track
of all the global variables.

I was looking at some code yesterday, converting it to pseudo code,
and I came out with this:

foreach customer, contract in table1, table2:
if (customer is in history):
isCustomer = true;
if (contract is in history)
isContract = true;
process(isCustomer, isContract);
else
isContract = false;
process(isCustomer, isContract);
else
isCustomer = false;
isContract = false;
process(isCustomer, isContract);

Just looking at the pseudo-code, you should see why I almost flipped
my lid. You can easily rewrite that is this:

foreach customer, contract in table1, table2:
isCustomer = (customer in history);
isContract = (contract in history);
process(isCustomer, isContract);

It doesn't take a master refactorer to figure that one out. (AND it is
impossible for there to be a contract without a customer) Now, how do
I tell my boss, who thinks this code is exceptionally difficult, that
he made some obvious mistakes?

He is very arrogant about how he got his code to work. I am not
impressed. I don't want to hurt his feelings by pointing out (there
are many more) his obvious mistakes and inefficiencies.

There is just too much . . . to ignore!

[Smithers]

I feel your pain!

I once had a boss that could be described in the same terms you used to
describe yours.

Consider this (this is how I maintained my sanity) for how it might be
relevant to your boss:

I figured out that he truly didn't know what he was doing. He just "got the
damned thing to work." and was *afraid* to change anything because he would
be at a loss as to how it could be fixed. He also didn't want the blame if
something went wrong.

Armed with that knowledge, and with the fact that it's hard to argue with
success; plus a recognition that this might be the sort of situation that
calls for the manipulative truism: "sometimes it's better to ask for
forgiveness than for permission."... I learned to just go ahead and make
many of the changes. Granted, I did in fact have a high degree of
proficiency and confidence bolstered by extensive unit and system testing.
So my changes practically never had any problems. He was blissfully unaware
of most change. By the time he found out - if he ever did - the changes had
already been in production for a long time. He never once got upset about
this because his worse fear was not realized - and that fear was that he'd
get the blame for something going wrong (nothing went wrong). In fact, he
was periodically *happy* with some of the changes because he learned a thing
or two. Even after he figured out my game, he never called me on it. Even
so, he'd still squelch most proposals I made because, at the proposal state,
it was an unproven [to him anyway] approach.

In sum: (1) figure out what fear is driving your boss. Be sure you
effectively address those fears from his point of view. (2) know your stuff.
Don't propose something or do it behind his back unless you are 100% certain
of what you are doing - and that you can demonstrate in objective ways that
your solution is accurate, reliable, and understandable by your boss; (3) go
with the "it's better to ask for forgiveness than for permission" only as a
last resort - and only when you are absolutely sure of what you are doing
and that you can convince him later that it was the best thing to do - from
*his* point of view. After all, he is the boss. Ultimately if he fires you
for doing something that is demonstrably the right thing to do, you are
better off not working with him.

-HTH

-"Smithers"

<je**********@gmail.comwrote in message
news:11**********************@x40g2000prg.googlegr oups.com...

Hello:

I had an hour-long discussion with my boss today. Last night, right
before I dozed off, I realized some of his code resulted in duplicate
processing. I tried to explain it to him and he kept saying, "I'm
afraid to say it's 'OK' to change it because everything I did was for
a reason." Well, I know better.

My boss' old code is written in some cryptic C file with Oracle
precompiler macros barfed all over it. Once I figured out how to
ignore 90% of the macro junk, it has just been an effort to keep track
of all the global variables.

I was looking at some code yesterday, converting it to pseudo code,
and I came out with this:

foreach customer, contract in table1, table2:
if (customer is in history):
isCustomer = true;
if (contract is in history)
isContract = true;
process(isCustomer, isContract);
else
isContract = false;
process(isCustomer, isContract);
else
isCustomer = false;
isContract = false;
process(isCustomer, isContract);

Just looking at the pseudo-code, you should see why I almost flipped
my lid. You can easily rewrite that is this:

foreach customer, contract in table1, table2:
isCustomer = (customer in history);
isContract = (contract in history);
process(isCustomer, isContract);

It doesn't take a master refactorer to figure that one out. (AND it is
impossible for there to be a contract without a customer) Now, how do
I tell my boss, who thinks this code is exceptionally difficult, that
he made some obvious mistakes?

He is very arrogant about how he got his code to work. I am not
impressed. I don't want to hurt his feelings by pointing out (there
are many more) his obvious mistakes and inefficiencies.

There is just too much . . . to ignore!

[jehugaleahsa]

You people and your showing me the logical difference between the two
pseudo codes. That is why I am made the AND capital. :-P

What I was trying to say is that on the back end is that the data
prevents a contract from existing when a customer doesn't. So
technically that possibility is handled. :-D

I included the (isCustomer AND contract in history) bit anyway. Thanks
for you concern!

All of you have been very thoughtful and I thank you. I was able to
convince my boss after another hour-long discussion that his code
references a global variable that is no longer in context when a
method gets called. He replied, "Well, it has always worked and I have
tested it." Well, his idea of a test is about the same a college kid's
(it worked, so it must be right). It took me about 20 minutes to
convince him that it worked because the global variable was handled in
another section of code, so of course the method would always return
successfully. I explained that even though it will always return true,
what he really wanted was to make sure some thing else returned true
instead . . . he is still thinking about this one. He said he isn't
sure - I should look into it - he never *really* tested it in
production - and now I know he made a logical mistake.

I would say that fear is what drives his stance - that and arrogance.
He honestly thinks he is a superior programmer just because he has
been working in this system for so long. But like so many programmers
out there, he was never officially trained to program. He has a degree
in finance and has picked up programming over time. He holds a
definite superiority on how the system works and the business rules,
but he doesn't know how to program that well. He always says OOP, but
none of his code reflects that. He has no concept of resource
management or reducing code duplication. He makes common
inefficiencies by not simplifying code using logic. Lately he has
stopped writing code altogether and just dealt with runtime errors his
users call him up on. Now he primarily hands me and my partner his
projects, explains how the process goes and handles users (oh, and
complains about the other IT staff). My partner has been begging him
to rely less on the database returning errors during processing but to
rely on catching errors up-front in the interface - he can't seem to
grasp why we'd want to. Worst of all, neither of us are allowed to use
true OOP or even many nested function calls because "if something goes
wrong, I don't have time to go looking for the problem; I can't find
it tomorrow; I can't find it next week; I need to find it NOW". The
worst part is when he repeats himself. The fact the he worries more
about when the error happens than how to prevent it is really
depressing. If he knew how to program, tracking down nested function
calls wouldn't be such a chore, in fact it would make things easier
(debuggers are a wonderful thing).

Sigh . . . I need a more challenging job, surrounded by people with
talent and diverse skills. I am the only trained programmer at my job
and no one trusts what I have to say (I am also only 22 and that makes
me inexperienced and immature). :-( They just don't understand why I
would write a library for ADO .NET or for Crystal Reports or
Networking or Streams or LDAP . . . "Libraries keep your code layered
and saves us all time by keeping our code comformant and
maintainable! :'-( Nothing is worse than LDAP code intermixed with ADO
in a large project to make methods a lot longer than they need to be.
I do all of my project work at home now so they don't ask why I am
wasting their time. The funny thing is, 70% of the applications at
work use my libraries and are working very well. *But, let's not judge
things by their successes.*

My boss won't even give me a database with the data needed to test my
code. I told him flat out that I wouldn't write any more until he gave
me something to test against. He still hasn't done it. Both of the
DBAs at my work can't program so their triggers are usually the size
of a house. The one can barely manage user roles and thinks all data
issues are the application's fault. You would think after cleaning up
NULL fields for the 500th time, she would just run a script to clean
up the rest of the data and add a constraint. But, alas, I'm still
spending a half hour every week or so cleaning up the same error with
the one DBA. The same DBA makes changes to production and breaks our
applications regularly (thanks for the head's up). The best part is
that I somehow became the regional Crystal Reports guru (I hate
Crystal) and now I make them for stupid things like data issues on the
database. It is really not that helpful for users to look at 40 sheets
of blank records to tell the DBA that she needs to do some clean up.

I am just releasing some bad energy, just so you know. I plan on being
out of here is less than 3 years. Would it be a bad thing to put,
"Don't want to work under an untrained programmer" on my resume? I
have seriously considered something like that. I am hoping my next job
is as a code grunt at some faceless corporation. I can't totally get
away from stupid decisions directing what I do (that's what business
is all about) but as long as I have a little more freedom over how I
am allowed to write code, I will be happy. I had a professor who once
said she became a Software Engineer because she got tired of being
told what to do by her idiotic bosses. She is a wise woman.

Thanks again for all your insight, I appreciate it!

~Travis

P.S. - When I had finished posting this message the first time, I
neglected to close the window. I spent an hour talking to my boss and
he didn't notice the "My boss is a Butthead..." down in the corner the
whole time. He-he.

[Smithers]

<snip>

<<Would it be a bad thing to put, "Don't want to work under an untrained
programmer" on my resume? >>

Don't do that. It will make you look picky and negative. Plus it's not like
any potential head hunter will look at that and go, "oh, let's not place him
with client XYZ." They'll place you any way they can. That's how they make
their money. Plus you can figure out how good or bad things are during the
interview process. Remember, you are interviewing THEM. Are THEY qualified
to work with you?

You are basically screwed; the problem with your employer is NOT your
immediate boss or the DBA or any of the other incompetent techies you work
with. Rather, you can understand your boss et al as *symptoms* of the real
problem -- and that is senior management [over them] who is likely clueless
as to the potential value of information technology if it is done right.
They simply don't understand the enormous savings to be realized with IT
done right, and thus tolerate the rampant incompetence. There is no way they
are clueless about the bad state of affairs - even if they don't fully grasp
how bad it is. You would do well to try to educate them on the potential
value of changing things. Be sure to present your case to them in ways they
will understand and that are directly and immediately relevant to their
priorities for the business. If you cannot influence them, then get outta
there - your boss will *never* value your game. He may reluctantly agree
with your points from time to time; but overall you are a threat to his
comfort zone.

There are far more incompetent programmers out there than competent ones. If
you move around in the industry you will find that your immediate situation
is far more common than you might possibly have imagined. This is good news
for you though. All these idiots make it really easy for you to look like a
super star. All you have to do is show up and not make dumb and obvious
mistakes. That, by itself, will put you way ahead of most of them. Then if
you actually go beyond [avoidance of bad practices] and actually follow some
best practices and stick with the time-tested design fundamentals, you will
look like a super star by comparison. So you can *thank* the losers for
making you look so good. Of course the qualification here is that your
*perceived value* (which is likely very different than your *actual value*
in your situation) is ultimately determined by how your boss and/or senior
management *perceive* your skills. Don't be surprised if you are ultimately
*punished* or somehow penalized for being more competent than they. You are
an obvious and immediate threat to them and their ways of doing things. So
be careful about how you proceed to deal with them. You should leave ASAP,
IMHO.

Good luck.

[Enkidu]

Smithers wrote:

>
You are basically screwed; the problem with your employer is NOT your
immediate boss or the DBA or any of the other incompetent techies you work
with.

It's likely that the OP is Beavis to his boss's Butthead. Obviously not
a team player. He ought to get a clue, not be harassing his boss about
his boss's perceived deficiencies.

Cheers,

Cliff

--

Have you ever noticed that if something is advertised as 'amusing' or
'hilarious', it usually isn't?

[AlexS]

Don't shoot yourself in the foot. You are dealing with usual humans. Who are
mostly lazy, not very bright, arrogant, over-confident and full of fears and
prejudices.

You don't feel it probably yet as you are 22. When somebody will kick you in
the butt hard enough or back stab you, you'll get the knack of it, if you'll
survive.

Consider this as hands-on training in social sciences. Efficiency and
reliability are not the goals for most people - most people loose the
comfort and jobs in efficient environments. If people feel uncomfortable
with you, they'll kick you out forgetting you as soon as you are out the
door. And if your actions will threat their safety, including job safety,
you might be in for pretty unpleasant surprises. Use your brains not to make
code better, but to make other people make code better. I hope you can see
the difference.

As they say, "be simpler and people will join you"

<je**********@gmail.comwrote in message
news:11*********************@q3g2000prf.googlegrou ps.com...

You people and your showing me the logical difference between the two
pseudo codes. That is why I am made the AND capital. :-P

What I was trying to say is that on the back end is that the data
prevents a contract from existing when a customer doesn't. So
technically that possibility is handled. :-D

I included the (isCustomer AND contract in history) bit anyway. Thanks
for you concern!

All of you have been very thoughtful and I thank you. I was able to
convince my boss after another hour-long discussion that his code
references a global variable that is no longer in context when a
method gets called. He replied, "Well, it has always worked and I have
tested it." Well, his idea of a test is about the same a college kid's
(it worked, so it must be right). It took me about 20 minutes to
convince him that it worked because the global variable was handled in
another section of code, so of course the method would always return
successfully. I explained that even though it will always return true,
what he really wanted was to make sure some thing else returned true
instead . . . he is still thinking about this one. He said he isn't
sure - I should look into it - he never *really* tested it in
production - and now I know he made a logical mistake.

I would say that fear is what drives his stance - that and arrogance.
He honestly thinks he is a superior programmer just because he has
been working in this system for so long. But like so many programmers
out there, he was never officially trained to program. He has a degree
in finance and has picked up programming over time. He holds a
definite superiority on how the system works and the business rules,
but he doesn't know how to program that well. He always says OOP, but
none of his code reflects that. He has no concept of resource
management or reducing code duplication. He makes common
inefficiencies by not simplifying code using logic. Lately he has
stopped writing code altogether and just dealt with runtime errors his
users call him up on. Now he primarily hands me and my partner his
projects, explains how the process goes and handles users (oh, and
complains about the other IT staff). My partner has been begging him
to rely less on the database returning errors during processing but to
rely on catching errors up-front in the interface - he can't seem to
grasp why we'd want to. Worst of all, neither of us are allowed to use
true OOP or even many nested function calls because "if something goes
wrong, I don't have time to go looking for the problem; I can't find
it tomorrow; I can't find it next week; I need to find it NOW". The
worst part is when he repeats himself. The fact the he worries more
about when the error happens than how to prevent it is really
depressing. If he knew how to program, tracking down nested function
calls wouldn't be such a chore, in fact it would make things easier
(debuggers are a wonderful thing).

Sigh . . . I need a more challenging job, surrounded by people with
talent and diverse skills. I am the only trained programmer at my job
and no one trusts what I have to say (I am also only 22 and that makes
me inexperienced and immature). :-( They just don't understand why I
would write a library for ADO .NET or for Crystal Reports or
Networking or Streams or LDAP . . . "Libraries keep your code layered
and saves us all time by keeping our code comformant and
maintainable! :'-( Nothing is worse than LDAP code intermixed with ADO
in a large project to make methods a lot longer than they need to be.
I do all of my project work at home now so they don't ask why I am
wasting their time. The funny thing is, 70% of the applications at
work use my libraries and are working very well. *But, let's not judge
things by their successes.*

My boss won't even give me a database with the data needed to test my
code. I told him flat out that I wouldn't write any more until he gave
me something to test against. He still hasn't done it. Both of the
DBAs at my work can't program so their triggers are usually the size
of a house. The one can barely manage user roles and thinks all data
issues are the application's fault. You would think after cleaning up
NULL fields for the 500th time, she would just run a script to clean
up the rest of the data and add a constraint. But, alas, I'm still
spending a half hour every week or so cleaning up the same error with
the one DBA. The same DBA makes changes to production and breaks our
applications regularly (thanks for the head's up). The best part is
that I somehow became the regional Crystal Reports guru (I hate
Crystal) and now I make them for stupid things like data issues on the
database. It is really not that helpful for users to look at 40 sheets
of blank records to tell the DBA that she needs to do some clean up.

I am just releasing some bad energy, just so you know. I plan on being
out of here is less than 3 years. Would it be a bad thing to put,
"Don't want to work under an untrained programmer" on my resume? I
have seriously considered something like that. I am hoping my next job
is as a code grunt at some faceless corporation. I can't totally get
away from stupid decisions directing what I do (that's what business
is all about) but as long as I have a little more freedom over how I
am allowed to write code, I will be happy. I had a professor who once
said she became a Software Engineer because she got tired of being
told what to do by her idiotic bosses. She is a wise woman.

Thanks again for all your insight, I appreciate it!

~Travis

P.S. - When I had finished posting this message the first time, I
neglected to close the window. I spent an hour talking to my boss and
he didn't notice the "My boss is a Butthead..." down in the corner the
whole time. He-he.

[Jon Skeet [C# MVP]]

je**********@gmail.com <je**********@gmail.comwrote:

I just had another hour-long discussion with my boss. I showed him
another problem that I found. After saying, "But . . . what about
this" a hundred times he finally started losing some of his
confidence.

I got him from, "Oh, I'm sure there is a reason" to "Actually, we've
never run this in production, but I tested it pretty thoroughly". So,
in short, my boss probably never even realized it, I probably found a
bug before it happened and my confidence level just got shot down 3
points.

If he claims that he tested it pretty thoroughly, ask him for his unit
tests, and ask if he minds you adding one. Write a unit test that
fails, and then ask him to see if he can see a problem with your new
unit test.

Of course, at this stage it might be more profitable to spend your time
finding a new boss...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

je**********@gmail.com wrote:

I had an hour-long discussion with my boss today. Last night, right
before I dozed off, I realized some of his code resulted in duplicate
processing. I tried to explain it to him and he kept saying, "I'm
afraid to say it's 'OK' to change it because everything I did was for
a reason." Well, I know better.

My boss' old code is written in some cryptic C file with Oracle
precompiler macros barfed all over it. Once I figured out how to
ignore 90% of the macro junk, it has just been an effort to keep track
of all the global variables.

I was looking at some code yesterday, converting it to pseudo code,
and I came out with this:

foreach customer, contract in table1, table2:
if (customer is in history):
isCustomer = true;
if (contract is in history)
isContract = true;
process(isCustomer, isContract);
else
isContract = false;
process(isCustomer, isContract);
else
isCustomer = false;
isContract = false;
process(isCustomer, isContract);

Just looking at the pseudo-code, you should see why I almost flipped
my lid. You can easily rewrite that is this:

foreach customer, contract in table1, table2:
isCustomer = (customer in history);
isContract = (contract in history);
process(isCustomer, isContract);

It doesn't take a master refactorer to figure that one out. (AND it is
impossible for there to be a contract without a customer) Now, how do
I tell my boss, who thinks this code is exceptionally difficult, that
he made some obvious mistakes?

He is very arrogant about how he got his code to work. I am not
impressed. I don't want to hurt his feelings by pointing out (there
are many more) his obvious mistakes and inefficiencies.

If you plan on having a future in software development you better
get used to see a lot of not very good code.

There are many bad programmers. There are good programmers having
a bad day. And there are good programmers just being tired after
working 80 hours weeks.

The result is that a lot of code sucks.

If the project plan allows it then refactor it.

If the project plan does not allow that, then that code will
live for some more time.

Bad code is something you will have to learn to live with.

If your boss refuse to let you refactor just because it is his code,
then you will have to keep low profile, but start looking for a new
job. Not only to get a better boss, but also to get better job
security. If the department is general run that way, then
there will likely show up some severe problems in the future.

Arne

[Robbe Morris - [MVP] C#]

Arne, you are fired before being naive enough not to
think I'd discover this post and you airing company
"dirty laundry".

Signed... your old boss

Arne, you are not hired at your next job for the
exact same reason...

Signed... the new boss you could have had.

--
Robbe Morris
..NET PropertyGrid Control - ListBox, ComboBox, and Custom Classes
http://www.eggheadcafe.com/tutorials...d-control.aspx


"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk...

je**********@gmail.com wrote:

>I had an hour-long discussion with my boss today. Last night, right
before I dozed off, I realized some of his code resulted in duplicate
processing. I tried to explain it to him and he kept saying, "I'm
afraid to say it's 'OK' to change it because everything I did was for
a reason." Well, I know better.

My boss' old code is written in some cryptic C file with Oracle
precompiler macros barfed all over it. Once I figured out how to
ignore 90% of the macro junk, it has just been an effort to keep track
of all the global variables.

I was looking at some code yesterday, converting it to pseudo code,
and I came out with this:

foreach customer, contract in table1, table2:
if (customer is in history):
isCustomer = true;
if (contract is in history)
isContract = true;
process(isCustomer, isContract);
else
isContract = false;
process(isCustomer, isContract);
else
isCustomer = false;
isContract = false;
process(isCustomer, isContract);

Just looking at the pseudo-code, you should see why I almost flipped
my lid. You can easily rewrite that is this:

foreach customer, contract in table1, table2:
isCustomer = (customer in history);
isContract = (contract in history);
process(isCustomer, isContract);

It doesn't take a master refactorer to figure that one out. (AND it is
impossible for there to be a contract without a customer) Now, how do
I tell my boss, who thinks this code is exceptionally difficult, that
he made some obvious mistakes?

He is very arrogant about how he got his code to work. I am not
impressed. I don't want to hurt his feelings by pointing out (there
are many more) his obvious mistakes and inefficiencies.

If you plan on having a future in software development you better
get used to see a lot of not very good code.

There are many bad programmers. There are good programmers having
a bad day. And there are good programmers just being tired after
working 80 hours weeks.

The result is that a lot of code sucks.

If the project plan allows it then refactor it.

If the project plan does not allow that, then that code will
live for some more time.

Bad code is something you will have to learn to live with.

If your boss refuse to let you refactor just because it is his code,
then you will have to keep low profile, but start looking for a new
job. Not only to get a better boss, but also to get better job
security. If the department is general run that way, then
there will likely show up some severe problems in the future.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Robbe Morris - [MVP] C# wrote:

Arne, you are fired before being naive enough not to
think I'd discover this post and you airing company
"dirty laundry".

Signed... your old boss

Arne, you are not hired at your next job for the
exact same reason...

Signed... the new boss you could have had.

I think it is time for a little quiz !

Question 1:

What does it mean when lines in a usenet post are prefixed with '>' ?

a) It is an important line.
b) It is a quote of somebody else.
c) Nothing. Those characters are inserted randomly by the NNTP-server.

Question 2:

Who wrote the lines prefixed with '>' in a usenet post ?

a) The person mentioned in the first line of the message body.
b) The person in the FROM field.
c) Bill Gates.

Question 3:

What does top posting mean on usenet ?

a) Posting while eating pizza with lots of toppings.
b) Posting by top qualified person.
c) Posting reply above what is being replied to.

Arne

[Michael A. Covington]

People who object to top posting show their unawareness of its advantages,
or are still using Model 33 Teletypes.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Michael A. Covington wrote:

People who object to top posting show their unawareness of its advantages,

As a rather general concept people who prefer X over Y usually
does not see the advantages of Y.

But the mistake that happened here would probably not have
happened if there were not being top posted.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Arne Vajhøj wrote:

I think it is time for a little quiz !

Question 1:

What does it mean when lines in a usenet post are prefixed with '>' ?

a) It is an important line.
b) It is a quote of somebody else.
c) Nothing. Those characters are inserted randomly by the NNTP-server.

Question 2:

Who wrote the lines prefixed with '>' in a usenet post ?

a) The person mentioned in the first line of the message body.
b) The person in the FROM field.
c) Bill Gates.

Question 3:

What does top posting mean on usenet ?

a) Posting while eating pizza with lots of toppings.
b) Posting by top qualified person.
c) Posting reply above what is being replied to.

No quiz answers ...

:-(

Arne

[Mark Rae [MVP]]

"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk...

No quiz answers ...

Were you honestly expecting any...?
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Mark Rae [MVP] wrote:

"Arne Vajhøj" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk...

>No quiz answers ...

Were you honestly expecting any...?

Maybe an "Ooops" message.

Arne