Reporting an error to a senior developer?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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

Check-list

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.