I'm a junior programmer working in a programming project. I'm fairly new to the programming language being used, as well as the overall structure of the program project (it existed before I started working on it).

As a result of my inexperience, I've had to repeatedly ask a senior developer for help. This developer has also had to correct my code multiple times, as a result of silly errors on my part. I can tell that there's a good chance he's getting somewhat annoyed.

Now, I've found what I think is a large bug in an area of the program that he's working on. It doesn't really affect what I'm doing, as I've been assigned small tasks elsewhere in the code. I brought up that my compiler is giving me errors at those lines, but he seems to believe it's an error with my computer setup. I've researched the error and done further testing, and I'm almost certain it's a problem with his code.

As for while it compiles for him and not for me, his compiler seems to be fine with these errors (apparently the compiler is an exception). When I fix the bugs in the copy of the program I download to my computer, the program runs fine.

My question is whether or not I should bring this up to him again and explain my reasoning. I feel like it may be better to leave it, and just stick to doing what I was assigned in the project. Is it a good idea to keep pushing this, especially given my current predicament?

  • 6
    How come the code compiles for him but not for you? He maybe right here, if anything, you can ask him for help to fix your computer setup.
    – Masked Man
    Oct 28, 2017 at 5:59
  • 13
    Side note: It seems like a terrible idea for people working on the same project to be using different compilers. If I were you, I'd opt for what everyone else is using or speak to my manager if it's not clear which compiler is the "correct" one. That should indirectly solve your problem and is a much better solution than trying to "fix" a problem in his code that doesn't seem like a problem to him. Or will the bug cause issues no matter which compiler is used? Oct 28, 2017 at 9:04
  • 9
    What's all this about different compilers? Doesn't your company insist that everyone uses the same tools? If not, why not?
    – Mawg
    Oct 28, 2017 at 9:19
  • 7
    "I have no idea what compiler will be used in the final project". Find that out. Don't assume. Checking assumptions takes time, but it's worth doing. What language is this? I assume it gets compiled at run-time. Oct 28, 2017 at 12:02
  • 3
    Leave it alone; there's absolutely no positive outcome for you.
    – pmf
    Nov 2, 2017 at 13:20

9 Answers 9


I brought up that my compiler is giving me errors at those lines, but he seems to believe it's an error with my computer setup.

At this point you should full stop and make sure your computer is configured exactly like his is.

If the error continues then ask for more guidance.

My question is whether or not I should bring this up to him again and explain my reasoning.

No. You've already been told what the problem is. It's time to listen, fix your computer and get back to the things that are within your area of responsibility.

Is it a good idea to keep pushing this, especially given my current predicament?

Let's say someone who reports to me said the software wouldn't compile. After investigating I find that they aren't using the right tools so I tell them to fix the machine to bring it into compliance.

If that person then came back to me and insisted that the program should compile using the wrong tool set then we'd have a "nice" talk about how programmers, of all people, should understand how to follow directions. If it happened a third time I'd fire them.

I'd highly suggest that before you raise this issue again you fix your computer. Then educate yourself as to why they have targeted this specific compiler/configuration. There are quite a few reasons to use one compiler over another - before you understand why the others have been excluded there is zero reason to insist that they be used.

I will happily listen to someone tell me I'm wrong. However, what I won't abide is someone claiming something is wrong before they have bothered to spend time understanding the problem or the reasons for the choices that have already been made.

  • 5
    If I found out that rather than choosing the tools as instructed, that person was busy trying multiple other tools just to "prove" that the tools I instructed to use (and ones that the rest of the team has no problems with) were the "wrong" choice, I would fire them right away. I strongly suspect OP has some strange motivations behind this whole fiasco.
    – Masked Man
    Oct 30, 2017 at 17:16
  • 1
    @MaskedMan: I agree. This sounds like some serious passive aggressive behavior.
    – NotMe
    Oct 30, 2017 at 17:17
  • This answer is definitely in contention for my bounty.
    – Neo
    Nov 3, 2017 at 17:29
  • 3
    The idea that you would "fire someone right away" detracts from this answer IMO as it's really not on-topic.
    – Chris
    Nov 3, 2017 at 18:13
  • 1
    The whole answer is not off-topic but I think that talking about firing seems melodramatic and unnecessary to answer the question posed.
    – Chris
    Nov 6, 2017 at 22:20

If the project currently only works correctly on a specific version of a specific compiler, then it would be reasonable to expect that same compiler will be the one used in the final release too, unless that compiler becomes unsupportable at some point in the future - otherwise perhaps there are some good reasons which you are unaware of for using this particular compiler.

Assuming that you are able to get this project working by changing your compiler and using the correct config/flags, this isn't really a "bug" as-such - however it is an indicator of a potentially fragile project configuration, which might emerge as a potential risk to the project in the future - however that doesn't seem to be the case right now; it sounds as if there's no reason to worry about this yet.

The constructive next-steps you could take would be to first fix your development/test/build environment using the correct tools and configuration, then capture those initial set-up procedures in the form of some documentation, (if it doesn't exist already) - for example, a Readme, private Wiki page, OneNote page, etc.

While you're fixing your development environment, keep note of all the one-time steps which you're unlikely to remember in a few months time. For example: "Install [Tool] [Version] into [Folder]", or "Create an Environment Variable called [Name] set to [Value]", or "edit [Configuration File] and change [Line] to [Something else]", etc.

If such documentation already exists but happens to be incomplete/inaccurate, then you could put this experience to good use by editing the documentation to add missing information or to clarify any instructions which you found difficult to understand or follow yourself. This information will be valuable to developer(s) joining your project in the future (or even yourself if you happen to find yourself needing to reinstall your O/S).

While mature projects usually end up having a simple one-step-build process, new and incomplete projects often require other clunky/messy procedures until somebody has time to streamline the process. In reality, this kind of thing takes time to refine, and is usually low-priority compared with fixing real bugs and implementing new functionality. Until then, it's useful to keep project configuration docs up-to-date so that new developers can jump straight into the code and be productive more quickly.

  • 2
    In general, this answer is completely correct, in this specific case, I wouldn't jump to the conclusion "initial set-up procedures for this project are not sufficiently documented". The OP seems to have some strange motivation for proving a "bug" in the senior developer's code, given that he has tried the code on multiple compilers and multiple computers (?!) instead of ... uhm, just doing his work. It sounds as though he has installed all those additional compilers of his own accord, even though he may have been instructed to use one that the senior developer and rest of the team uses.
    – Masked Man
    Oct 28, 2017 at 12:09
  • 2
    I work on a high-performance code that is targeted for Intel platforms. On the target we compile with the Intel C++ Compiler (ICC) because that generally gives more performance than GCC on those machines. Since the scientists working on it do not an ICC license at their institute, we build it with GCC on our workstations. The side effect is that we are forced to refrain from using proprietary C++ additions without an #ifdef. In order to get around from bugs where it builds on one machine but not the other, we always run compilation tests on neutral grounds, i.e. Travis CI. Oct 28, 2017 at 12:56
  • @MaskedMan You're right, I assumed the OP had essentially just been experiencing frustration from being thrown into the deep end with an undocumented project, but now you mention it, I agree that the whole question does sound a little inauspicious without having any requirement or reason to use those other compilers. Oct 28, 2017 at 13:14

The problem is elsewhere: as you say on your PC it is not compiling, but on his system everything is working fine.

In all companies I've ever worked, there was a central build server: everybody has a programming environment on his/her own PC, but when modifying a piece of source code, this gets entered into a central versioning system, the central build server is then retrieving the last versions of all pieces of source code and tries to compile. If this works, then everything is OK. If not, then there is a problem.

So that might be a valuable approach for your issue: "Sir, we have the situation here that something is working on one PC but not on the other one. Instead of arguing which PC is right, let's use this situation for setting up a central build server, and in future, if ever we encounter such a situation again, that system will be the judge of who's right."

Good luck


Look for a fix that works on both setups

A general principle in situations like this is the Scout Rule:

Leave the code in (at least) the same, or (preferably) better shape than when you found it.

So your senior colleague has their development environment set up in a specific manner. There can be many reasons for that, some possible ones good and very valid, some unnecessary and maybe even harmful.

Good reasons for this setup may include that...

  • It expedites development, debugging and/or deployment
  • It includes functionality that is not present in other setups
  • It deals with backwards compatibility that is required for interoperability with other modules
  • Changing to another setup may require extensive work to ensure that the rest of the code still works as intended (*).

Bad reasons for this setup may be...

  • Laziness or otherwise irrational resistance to keep up the development environment to date ("It works fine for me, I won't touch it!")
  • Prejudice against newer versions as "Untried, therefore unsafe".
  • "We have always done it this way"

What you can do here is ask your senior colleague: "How come you are using that? Is there a specific reason?". And they will tell you. Maybe their reason will be — in your opinion — good and valid, or it will be — again in your personal opinion — a bad reason. But do note that most likely they feel that the reason is valid.

What would make the least bit of fuss is if you make a change that works on both setups, provided that you do the change correctly. For that you need to go through a...


If you want to use the Scout Rule, and "fix" a problem that is not directly related to your work, it is usually appreciated if you do it. But only if you make sure that what you do is actually better. As such you must make sure that...

1. My changes will not break things

The road to hell is paved with good intentions

The first thing you need to do is make sure that your fix does not actually break anything. The usual safeguards — no compiler errors, code review, automated tests — will help you there. Avoid checking a Scout Rule Fix into the main development track, instead use side branch of the code and get the change tested before anything else.

2. My changes will not make things more confusing or add unnecessary complexity

This point is rather self explanatory. It is a virtue to keep the code simple and maintainable. If your change means that it becomes harder to read, build or deploy the code, then it is best to leave the change out. But if it can be added with no change to the complexity of the code, nor the build and deploy process, then it is OK.

3. My changes will improve things

Just like the senior developer thinks that their setup works for them, so you may fall into the same trap. And while an improvement for you is indeed reason enough to affect a change, you may wish to ask others too "Is this worth it?". If they agree that this is an improvement, then go ahead.

(*) I have have had code break from just upgrading to a new sub-version of a development kit... not even the minor version but the sub-version.

  • 2
    This answer is definitely in contention for my bounty.
    – Neo
    Nov 3, 2017 at 17:29

To improve the chances of him accepting your input, don't start out with a plain "I have found a bug in your code". Take it from the side, and ask him to sit with you and go through the code, so that you can understand the logic.

Explain what and why you think is wrong, and listen to his answers. There are two possibilities:

  1. you are right, and he will understand the bug without being "annoyed" by your "bold" statement.
  2. you are wrong, and you have put the effort of understanding the code with him without claiming it was bugged.
  • This is basically what I was going to say. Ask the senior developer to walk you through the relevant code bit by bit. Frame it like you're just trying to learn from it but remain critical. As this answer says, you'll walk away with either a better understanding of why you were wrong, or the senior developer concluding that there is indeed an issue in the code and fixing it. The one thing I would add to this answer is a general tip about always using the same 'build environment' as the other people on your team, to prevent false positives.
    – Cronax
    Nov 6, 2017 at 15:35

The first thing to do is to make sure you know the exact language rules for the software. Typically, as languages and their standards evolve new features are added. Sometimes particular compilers have features beyond any formal standard. What language features are permitted to be used is usually a decision for the senior developers, but may be affected by marketing issues if customers need to be able to compile the code. "Can we use language extension X?" is a legitimate question for you to ask.

If you plan to disagree with the senior developer on what features should be used you need very solid reasons why it absolutely has to be the way you are proposing. If it is just a matter of opinion and preferences the senior developer's opinion wins.

After you find out the intended set of language features, you next need to make sure your compiler supports all the features the rules permit. That may require installation of a different compiler, additional libraries, or setting compiler flags to enable features that are disabled by default.

If the code fails to compile with a compiler and configuration that supports all the features that are permitted in the program, then you have an issue to discuss, in those terms, with the senior developer.


I'm going to veer a tiny bit off topic here and focus obsessively on one small thing you said...

silly errors on my part

There is a fix for this. UNIT TESTS! For every significant function you write, why not have a set of unit tests which know the expected output for a given input. While you write these tests, you'll start thinking about weird edge cases in the inputs. Heck, for a few key functions you might even write the tests first and watch them slowly turn from red to green as you implement your fn.

This approach will help a lot with those "silly errors", because you're explicitly checking for them instead of just throwing code over the wall for QA.

Find out what kind of unit test framework your group is using. If there isn't one (I'm wailing and gnashing my teeth here), ask for some time to find and instrument one. There are a lot of good ones with similar names (nUnit, jUnit, xUnit, ...)

You won't be sorry.


It's pretty clear that developers have different set-ups on their machines, and the world is perfect if the solution builds on their own machine.

Obviously, this is hogwash and relies on at least one person to build and deploy the solution in their own view of the world.

The answer is to standardise by using a Jenkins build server or something similar to that.

We have one for our major solutions. Every few minutes, it grabs the latest code files from the source code manager (TFS in our case) and then attempts to build the solution. If the build fails, everyone in the team gets automatically emailed and whoever broke the build is implicitly named and shamed.

Obviously, the compiler options and environment on the Jenkins server is vanilla and is geared toward a completely valid/true build.

This removes any ambiguity caused by people referencing local copies of source/dlls out in the wild and you won't deploy a solution that references a piece of code that lives on someone's development machine.

Using a build server like this levels and standardises the playing field and ensures complete consistency in the end result.

  • It's pretty clear that developers have different set-ups on their machines, and the world is perfect if the solution builds on their own machine. Obviously, this is hogwash and relies on at least one person to build and deploy the solution in their own view of the world. +1
    – Neo
    Nov 6, 2017 at 15:28

Fact is, you already reported the problem to this senior developer. What you are really asking is not how to report it, but how to convince him to make a change.

You have done your responsibility. You reported what you think is an error. He is the senior developer, he decided you were wrong and the code is right, so that's it. Now there are two possibilities: Either he is right, or he is wrong. If he is wrong, he is either not very senior, or he is boneheaded and not accepting anything from a junior developer. In either of these cases, persevering will not get you anywhere.

Instead of finding an error in the code, where its your opinion against his, figure out if this leads to the software misbehaving in some way. That's something that can be checked objectively and may have to be fixed. If you can't figure out how this error leads to the software misbehaving, then either there is no error, or it is unimportant.

You must log in to answer this question.