Allow me to clear the situation. I was talking with my professor about a piece of software that I had developed. While we were discussing, I wanted to say something like
I don't want to sound too cocky, but my code is way much more efficient than what we have right now.
But I didn't because I thought "I don't want to sound too cocky" is too informal. What is a formal way of stating such a phrase?
To say the same thing, you can say
I hope it won't be considered presumptuous to say this, but... or
I don't want to sound presumptuous, but...
Synonyms that you can substitute here for presumptuous are
impertinent, overconfident, arrogant, bold, insolent, impudent, and of course the less formal sounding "cocky".
To sound deferential, but not say precisely the same thing, you could say
When I compared the code performance, I was surprised to see the degree of improvement my code achieved.
Wording it either way would leave you open to discussing the possibility that your code or your testing may be flawed, while making your point about its apparent improvement.
While we often think that our idea/viewpoint/product is far superior to others we encounter, the needs of the creator or other users may be divergent from our own, or what we think theirs are. We may view precision as the primary criterion, while they think ease of use is paramount. And they may be the deciders.
One approach to acknowledge that another viewpoint may be more controlling is
I may be wrong [mistaken/off-base/not fully aware of all the issues], but it seems that my approach may get us closer to a solution.
Even if you are dead certain that their method sucks compared to your elegant solution, you have a better shot at being heard if you suggest that you may not be correct.
:)
Don't just assert; support the assertion.
"Testing with the Arcane Blivit dataset indicates that this implementation improves performance of the Deeble function by 20%, which improves our overall performance on that dataset by 3%. I'd be glad to repeat the experiment with other datasets to make sure this isn't an atypical result." Or explain why the new version is easier to maintain, or handles necessary cases that weren't previously addressed, or whatever else its advantage is. If you can't explain in a few sentences why yours is better, you don't understand it well enough to make the assertion in the first place.
Then, if you're told no, politely try to understand why the answer is no. Don't argue -- listen more than you speak.
In other words: If you don't want to come across as arrogant, don't be arrogant.
If you wanted to preserve the exact structure of your phrase and only change the word "cocky", you could say this:
I don't want to sound too forward, but my code is way much more efficient than what we have right now.
That said, I would highly recommend changing the way you said this in general, but others have given plenty of advice in that regard.
With all due respect, I would like to say that ....
Given the context (discussing your code with your professor) you could opt to support your assertions, and just start your sentence with "I'm sorry but..." and top it off with "that's what my tests showed anyway".
Something along the lines of:
I'm sorry, but I've tested both versions. Mine outperformed what we had so far by n%. Of course, if you see anything wrong with my method of testing, I'm open to suggestions.
This phrasing still boils down to your saying: My code is, I think, more performant (which, incidentally, is perfectly fine: not too informal and not cocky at all), and shifts the topic of the discussion to how to better test performance. The latter is a classic debating trick: by changing the subject, if the opposing party then focussses on the new topic, too, will make it seem as though your initial statement (of your code being the better approach) is agreed upon.
Note:
I am a developer, and I've had these which code is best discussions more than I care to mention. I found that shifting the topic to how code is tested avoids those rage-filled-foam-at-the-mouth shouting matches quite well. If my code comes under scrutiny, I don't take offence, even if I felt my code was the better option. I was always able and prepared to defend my work, by suggesting using stuff like unexpected input, sudden loss of network connection, stack overflow and the chances of infinite recursion or data corruption.
Since you're talking to a professor, I take it you're still learning to code: TMTOWTDI (There's More Than One Way To Do It) is something to keep in mind. Give the same challenge to 10 programmers, and you'll see anywhere from 5 to 10 different approaches come back. The best code doesn't exist. It's always the best code in this case, so discussing various approaches is as much a part of programming as testing, flowcharts, debugging, refactoring and writing the actual code.
It's often said that programmers only spend 20% of their time actually programming. So if you don't feel confident challenging existing code, I'd suggest, without wanting to be arrogant or patronizing, you go ahead and dace that "fear" head on. Challenge the code. The worst that can happen is you get an edgy response, briefly pointing out one or two things you've overlooked. That's not bad: that's how you learn.
The best that can happen is that your professor says: "Well, you know what: You're right, I didn't see that", which is a nice thing to hear.
What I'm saying is: Sod the fear of sounding cocky, you have nothing to lose and everything to gain.
n programmers and you'll see at least n+1 different approaches come back." Definitely agree with your analysis.
Commented
Jan 9, 2014 at 16:18
First of all, I suggest avoiding the phrase "I don't want to sound x, but..." or any variation thereof, because in conveys that you are x, and (even worse) aware of it. Therefore you did the right thing by swallowing down your comment, it would not have helped you since it has the tendency to steer the discussion away from a rational argument.
So you need to convey that you might be wrong, but you are convinced that your solution is superior and offer a rational way to settle the matter. Something like:
"I believe my code is a more efficient solution than the existing approach. If you allow me, I will present some benchmarks to prove it."
"Can I suggest in all modesty that . . ."
Personally I wouldn't say straight up that it's a better solution. I would let your code do the talking for you.
Humbly speaking, "way much more" sounds overly idiomatic. Perhaps your code halves the typical run time and uses fewer shared system resources than the current implementation.
You could rephrase your statement as a question, perhaps:
If we used this alternative approach, would it be more efficient?
In business contexts I have found this to be by far the best approach to tell someone about an improvement without hurting their feelings. I think psychologically it's different, because they are telling themselves, rather than you telling them.
"I do hope that this approach improves upon the existing efficiency of the existing code."
"Do you think that by going about the solution in this fashion offers more than just a theoretical advantage over the existing code?"
I don't want to sound too cocky, but my code is way much more efficient than what we have right now.
This does sound arrogant, and begging to be belittled and dismissed. If a student of mine addressed me in this fashion, I would bite my tongue and listen to his/her code but it had better be damn good for me to take the solution seriously.
There's nothing wrong in being polite and deferential, it's also a sign of intelligence and humility. In your case I would say to the professor:
I'm not being boastful when I claim that my code, judging by its performance and its test results, is extremely efficient. However, I'd really appreciate hearing your input/considerations/criticisms on the matter.
same as Keshlam
Ultimately all these formulas dont make any sense. If you dont want to contradict you shut up, and if you want to sound cocky you'll use the meaningless formulas mentioned above.
But if you want to be just honest just say it, or explain it:
As mentioned by @ollym, let your code do the talking.
Although the current program is excellent, I believe I may have implemented a few improvements...
If you're proud of your accomplishment, you can be open about it and invite the professor to share in your joy:
I am proud to report that my code runs much faster than the current version. Would you like to take a look?
Whether this is appropriate depends on the circumstances, of course. If the professor is teaching you how to write faster code, then naturally the professor will be glad to hear your news. If you and others are working on the software together, then adding an improvement to the software will be welcomed by all. On the other hand, if you are competing with the author of the current version and have no intention of collaborating, it might be best to hold silent in that conversation and celebrate your victory somewhere else.
The appropriate phrasing really depends on what you want your listener to do with the information: celebrate with you? feel ashamed and defeated? get angry? check to see if you're right? put your code into the next version? There are clear and formal ways to do all of these things.
On the other hand, saying, "I don't want to sound X, but ..." says pretty clearly that you're about to say something X. Even this can be turned to your advantage with humor, though. "I don't want to sound cocky, but my code totally left yours in the dust!" This amplifies the cockiness so much that it will likely be heard playfully.
When trying to be humble about one's opinions, I often find the words 'believe' and 'appear' to be quite helpful. I also personalize the opinion, so that if I might be found incorrect, it is no more than that… an error in my perception.
In your case, I would have approached the topic like this:
It appears to me that this method might be superior to that one.
Also, you might consider the Socratic method. That would entail asking directed questions so that the other finds themselves arriving at your solution by themselves:
What would happen if you did that this way?
Could you even remove that outer loop altogether if you did that this way?
I find that this approach lends itself well to learning on both sides. I sometimes learn that I'm not necessarily as smart as I believed myself to be and at other times, someone else may benefit from my observations.
"Not to toot my own horn, but ..."
