How to tell your boss that his programming style is really bad? [duplicate]

Question

I'm a student and in my spare time I'm working for a big enterprise as Java developer. The job is good, but the problem is, my boss writes very strange code. I don't want to complain, but some issues are in my opinion really strange. For example:

• he doesn't know any booleans. All boolean conditions are Strings called "YesOrNo" and then in the condition he uses if (YesOrNo == "Yes")

• there are a lot of very strange characters in method names and variables like é õ ô or è

• all loops are infinite loops in the style of for(;;). Then at the end of the loop the condition is tested and if the conditions is fulfilled break; is called.

I don't know if I should tell him that I think this isn't a good practice, since he is my boss and decides how and what to do. On the other hand some of his examples are really very weird.

Any hints how to cope with? And is this only me who thinks that's bad style?

Answer 1

Ask him to explain his code to you

Tell him you've never seen X programmed that way before, and ask him why he codes it that way. Show him the way you code it, and tell why you do it that way (best practices, better performance, less chance of errors, easier for other programmers to read/maintain, etc).

Be sure to prepare all your arguments in advance, and focus on why your method is best instead of why his method is worst. Afterwards, see if he still supports his method over yours.

If he is open to improvement, he will likely change his way of coding. If he still prefers to use his style of coding over yours, you are not likely to change his opinion.

Answer 2

Promote the use of automated static analysis and style checking tools like linters and bug finders (in whatever language you use). If everyone in the company starts using them (e.g., they're mandated before checkins), he is not singled out.

The reason I am suggesting this is that:

1) Folks generally take better to censure from automated tools than their coworkers or subordinates.

2) These tools cover a lot of issues that can be considered poor style.

3) You could possibly tweak the rules behind the scenes for his bad style beyond what is built into the tool. For example, enforce a certain style of variable.

4) Some people realize that their code is not so good and actually start paying more attention even on things not covered by the linters.

Quite a few well-respected companies (such as my own employer) force a lint check before check-in. The view is that bad style is technical debt. You could always use the "Well, if X and Y and Z are doing it, it's probably a good idea".

Answer 3

I think you should definitely not tell him anything like that straight. Such statements can easily cause a defensive reaction in him, which will almost surely close off any possibility for him to learn, and may even cause problems for you.

Instead, look for (and even try to create) opportunities to casually discuss coding style and idiom issues and mention him the "best practices" you know of. Of course, you must ensure first that what you suggest is really a widely known and accepted best practice.

Also, try to discuss the same issues with other team members as well. It is important to understand the (spoken or unspoken) "consensus" inside the team regarding coding style and quality. (If everyone else writes clean and high quality code, you have a very different case than if the rest of the group consists of Real Programmers who proudly write FORTRAN programs in any language.) They may also tell more of the historical background of the project and your boss' coding style, which helps you aim your efforts better.

Another way is to ask him to order Effective Java for you, because you feel you need it to become a better programmer. (In case you haven't read it yet, you do in fact need it.) Then you can talk to him about the wonderful solutions and practices in this book.

If he is open to improving himself, he will pick up your suggestions (and the book). If not, you can retreat without losing face and straining your relationship.

Answer 4

If your boss is cool guy, simply ask him: "Dude, WTF?"

Answer 5

In all instances where you think "mine is better" never tell someone you think that, show them.

I repeat, SHOW, do not tell.

Ya know that saying about actions, louder, words... it's true.

Answer 6

Here's my recommendation:

• State your case well.
• If your manager is not receptive* to your point of view, and you feel that you're right, seek greener pastures and don't make any excuses.

I recommend that you seek greener pastures for three reasons:

1. In the long run, it's harmful to a programmer's career to perpetuate bad practices. The perpetuation of bad practices begets bad habits.
2. A programming shop that isn't receptive to alternative points of view stifles imagination.
3. When you know that the you're perpetuating bad practices and your team isn't receptive to alternative points of view, your morale is bound to sink, and this will make your life miserable. So leave ASAP.

*Important Distinction: Expecting somebody to be receptive to your point of view is not the same as expecting somebody to yield to your point of view. I always appreciate people who consider my point of view, whereas I have little respect for people who are soft and yield to my point of view without sufficient reason or evidence to do so.

Answer 7

Exactly what position does your boss hold? Is he a developer, tech lead? How many other developers are there in the company? Does the company have coding standards and code reviews?

Its unlikely you'll get your boss to change his (IMHO) bad habits but you might be able to use a peer group or the company standards to influence him. If his code does follow standards and the peers are all the same then your options are limited.

Answer 8

Actions Speak Louder than words:

A different approach:

• You need to lead by example.
• Make sure the projects you do are the best you can do.
• You need to excel in terms of performance, fewer bugs, etc.
• Once you can demonstrate that your approach and style is better than your boss, unless s/he is very arrogant then I think that naturally that person will follow whatever works best.

Answer 9

I would just give him Pointers in small doses, when you see him doing something "bad"

"Hmm, check out this approach for that {Pointing at his screen}, I like to do it this way because of blah blah blah."

Do this No more than once every other day. It he doesn't take your suggestion never mention it again (for a few weeks). A few will stick. And he will slowly get better.

Answer 10

Ask your boss to compare to another way you've been taught. He may have a legitimate reason. You're not going to know until you ask. There may be some old coding standard she is trying to maintain or she just may not care. Don't give any indication you think the boss is automatically wrong. Oh, and do it privately. This is for your educational purposes.

Answer 11

It depends. If the code you are reviewing is brand new code then ask to have code reviews as it will help "bring you up to speed" and it will show you are interested in learning. The boss may find this helpful as it will demonstrate to him that you are looking to do the right thing. If this is old code that you happened to stumble across and are forced to maintain it, make it a point to do slow refactoring. A type declaration here and there while still completing the task at hand. Now the problem here is that the String YesOrNo may take on other values such as Maybe which can lead to broken code if you aren't careful.

Answer 12

Try to show him short pieces of sample code from reputable sites/places/book etc that accomplishes similar things.

Answer 13

The first thing I would do is, to find out how he reacts on critics. If I would be the boss - well I wouldn't do anything wrong, would I? - I would to prefer to be told right in my face, all at once but in a respectful way. Depending on the temperament and culture, your boss might be different.

But most of them need some respect. A good way to show, that you respect him is, what has been suggested before: You explain what you mean, but leave the decision to him: "This is my reason, but perhaps I've overseen something. After my explanation:"

if (YesOrNo == "Yes")
if (YesOrNo == "yes")
if (YesOrNo == "YES")
if (YesOrNo == "oui")
if (YesOrNo.equals ("Yes"))
if ("Yes".equals (YesOrNo)) // might be null

"what do you suggest?"

And you may ask a metaquestion before: "Mr. X, if I have found something in your code, which is commonly reported an improvable practice - how should I report it to you? All at once, or step by step? Or should I avoid mentioning it at all costs? Silently improve the code?"

It would depend on my relationship which wording I would choose, and which approach.

Answer 14

Your boss does not know how to program, and he should not do it. My experience told me that assuming that someone called boss is also more experienced or better than you is a fallacy. He may be better in other things, but the point of management and hierarchy is to delegate things to the most appropriate person. A boss is someone who had the chance of starting a business, or got into a management position eventually for his managerial skills, not necessarily for his programming skills.

I had a boss once who pretended I installed a computer while connected to a gasoline electric generator, because he claimed hackers could enter via the electric network while the machine was still unprotected. I quitted immediately. I learned a valuable lesson back then: the boss isn't always right, and sometimes quitting is the only valuable response.

So, to go back to your case, you may have a case where only looking for another employment (yes, crisis, yadda yadda... I know) may be the best cure. Don't waste your precious time.

Answer 15

I live in the industry where I can't find my boss mistakes. So better, I would generate the cases in which errors appears in the code and let him see the error, than I'll suggest him the required changes and about the possible reason [in your case you are sure about the reason.. :-D ] of the error. Any developer, whether good or bad, wll not accept the mistake until he see the bug.

Answer 16

I once had a big problem with a bosses style.

There's two problems with that. First off, I don't think I ever said it to his face, but I imagine he knew. He stayed professional, I didn't, IOW.

Second, there were reasons for what he did, and it just took me time to understand how overcomplex and nasty my this-is-the-right-way "solutions" were.

Of the three points in the question, diacritics aren't strange to everyone, and while I wouldn't use that for loop, I get irritated by the C family do...while syntax and how it (doesn't) fit with my indentation style, so I can maybe see where it comes from.

Even the boolean thing might have an explanation in terms of habits brought in from another language (which is no justification, of course).

Answer 17

I guess this might work -

1. Ask your manager to review your code which does not have any of the mistakes that he does.
2. Then see if your manager asks you why not do it "his" way
3. If he asks this question, you could ask him why that would be a better way.

By this way you get to know why he thinks his way is correct.

Answer 18

I've been there before. I was straight out of Uni and after about a year of working for a guy, I realised that I knew way more than him about programming, but it was his business, and he called the shots - and just didn't want to offend him anyway! I decided that the best way around it, was to discuss the benefits of having common coding conventions across the company that we should all stick too, and see how he reacted. Suprisingly, he thought it was a great idea, and asked me to draw up a list of standards, that we both then reviewed together, and finalised etc.

The important thing here is, that you are just a fallible as he is, and that just because some of his ways are odd/wrong, some of them will be better than your own.

From my personal experience however it didn't work. Despite spending 2 days researching and compiling a great doc of standards and coding conventions - he was already set in his ways, didn't really see the benefit in coding conventions, or writing code that put less strain on the server, that made our jobs quicker and easier, and cut costs.

In the end I left to find somewhere that took development a bit more serious. It wasn't all bad, as the research I did on coding conventions really helps to this day.