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?

  • 5
    @Roflcoptr: Ah, those accented characters are legit in French, so I wouldn't worry as long as you can understand what the symbol names are. If he starts using only French words and you don't speak French, ask for a translation, maybe? Commented Feb 9, 2011 at 14:57
  • 27
    @Frustrated: even when programming is done in French it's considered bad style to use accented letters in variables or methods names. Commented Feb 9, 2011 at 15:32
  • 4
    @Niphra, identifiers can contain unicode characters and it is not bad style to use them. It MAY however give encoding problems, but that does not make it bad style as such.
    – user1249
    Commented Feb 9, 2011 at 18:36
  • 7
    @Roflcoptr: If all else fails, you could just collect some of your favorite examples and submit them to TheDailyWTF.
    – oosterwal
    Commented Feb 9, 2011 at 20:45
  • 3
    @Niphra From which authority was that? I'm French and I do most of my programming in English, but if I have to do it in French I won't hesitate to use accents.
    – zneak
    Commented Feb 11, 2011 at 15:26

18 Answers 18


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.

  • Good idea +1 from me Commented Feb 9, 2011 at 15:46
  • 1
    Whenever another dev does something strangely on my team, I ask for their reasoning because it could possibly be performance or business rules related. Its hard as a developer to admit there are some things you don't know and that there is no universally correct solution. Commented Feb 10, 2011 at 0:59
  • 7
    About the only time I keep up with Programmers is when I see an interesting question linked from the Stack Overflow homepage. Most of the time, it's an outstanding question or answer from you. Not sure I understand why you might ever have cause to be worried about such things as not being respected by your colleagues, even those older or with more experience. I'm consistently impressed by your professionalism, outlook, and ability to articulate your opinions; another +1 from me. Commented Feb 10, 2011 at 4:25
  • Why not just say it. The fact that he's the boss shouldn't change anything in a healthy team (I assume there's no problems to share negative feedback with peers). Especially if YesOrNo vs boolean is a real situation and not just some grotesque imaginary example. Seriously, in my opinion one doesn't even have to be super polite in such extreme cases of incompetence.
    – KolA
    Commented Aug 20, 2019 at 8:28
  • 1
    @DanielKaplan 100% agree with that! Starting the conversation with curiosity instead of immediately trying to push an agenda is the way to go. The whole "focus on why your way is good over why their way is bad" is only advice for once you've already established that their code is poor in the first place, and you are trying to convince them that there are better ways to accomplish it.
    – Rachel
    Commented Mar 10, 2022 at 15:55

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".

  • 8
    Good idea, although if there are loads of issues found by the analysis, it may again trigger a defensive reaction in the boss, so he may even declare "this tool is crap, stop using it!" So it is worth being careful when introducing the tool, possibly switching off the majority of its checks in the beginning :-) Commented Feb 9, 2011 at 15:01
  • +1 Great advice. I am a big fan of StyleCop for this exact reason.
    – Job
    Commented Feb 9, 2011 at 15:05
  • @Péter Török: That comes down to expectation management. You have to say "A lot of our code was written before this new awesome tool so there will expect many issues and it's OK."... some tools allow you to suppress different things so it could be used to suppress/ignore all issues except Severity-1 issues in OLD code and only used rigorously on NEW code. Commented Feb 9, 2011 at 15:09
  • 5
    @Roflcoptr: No proper IDE is far a bigger problem than the code style issues.
    – Kramii
    Commented Feb 9, 2011 at 15:43
  • 2
    @Roflcoptr: There are pretty good linting tools for C, C++, Java, and Python, and I would assume that there are such for other tools. You don't need an IDE for these although IDE integration does help.
    – Uri
    Commented Feb 9, 2011 at 15:59

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.

  • +1 I totally and absolutely second the suggestion for reading Effective Java. I have read both editions from top to toe, and it's (in my humble opinion) the one book every Java coder must learn thoroughly. Commented Feb 10, 2011 at 3:58
  • Effective Java Solution is really nice - innovative :), not sure in small budget teams though.
    – PathToLife
    Commented Jun 13, 2021 at 0:08

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


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.

  • How? I can't manage to do that. I always tell and expect people to just believe and trust me, because I don't know how or don't have the energy or time to explain something. Commented Apr 7, 2016 at 18:34

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.

  • Upvoted, particularly for the important distinction to being receptive to and yielding to someone's PoV. An underrated distinction well explained. Commented Jan 23, 2012 at 18:15

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.


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.

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.

  • 2
    Instead of giving 'pointers' to your boss, phrase it as "My professor said to do it another way, which one is better?" Don't let your boss think you're assumption is the boss is wrong.
    – JeffO
    Commented Feb 9, 2011 at 15:55
  • 6
    @Jeff, non-academics frequently take almost offense to that kind of arguments.
    – user1249
    Commented Feb 9, 2011 at 18:37
  • I agree with Thorbjørn. People can read between the lines (often even when there's nothing written between the lines), and "weasel words" can sometimes cause more offence than saying what you mean directly (but as carefully and non-judgementally as possible). Of course this is easier said than done.
    – user8709
    Commented Feb 9, 2011 at 19:29
  • @Thorbjørn Ravn Andersen , @Steve314 - you have to assume if you hire college students they are going to get conflicting information between what they've been taught and how you do things. Being blunt doesn't get you far with superiors.
    – JeffO
    Commented Feb 10, 2011 at 17:37
  • @Jeff, in the context of this answer, I would consider any "my professor said...." approach to be sneaky and weasel like.
    – user1249
    Commented Feb 10, 2011 at 18:52

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.

  • No way. There's no reason to code as his boss is doing. His boss is clearly a bad programmer. Commented Feb 10, 2011 at 10:31

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.


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

  • It's way too easy for him to find counter-examples. Lots of code, even on reputable sites/books, is an absolute abomination. People claim things like "oh, this is just an example!" but don't stop to realize what their example is actually demonstrating: bad practices. Commented Feb 10, 2011 at 4:21

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.


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.


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.


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).


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.


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.

  • +1: From my personal experience however it didn't work... He was already set in his ways...: First of all, it's extremely difficult to change a mature adult's behavior. Second, in most cases, it's doubly difficult to change your boss's behavior. This is why if you have a fundamental disagreement with the way things are being run at your current workplace, you should simply move on.
    – Jim G.
    Commented Feb 10, 2011 at 15:41
  • Yes I agree, learning about coding conventions will help you for the rest of your life.
    – C.J.
    Commented Feb 16, 2012 at 19:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.