It's amazing how much confusion there is among otherwise highly-competent engineers around certain factors of two in engineering equations, particularly in the RF and signal processing domain.
For example, I’ve seen the following question in multiple engineering forums: “Why is a Single Side Band Noise Figure 3dB higher than a Double Side Band Noise Figure? This intuitively seems backward...” At least the questioner knew that the SSB noise figure is typically 3dB higher in spite of his intuition to the contrary.
Consider the consequences when someone decides to trust their intuition and applies the 3dB offset in the wrong direction, thereby making a 6dB error in the effective noise figure! An error like that in the noise budget of a receiver could easily be fatal to a project.
Another common confusion arises over one-sided vs. two-sided spectral density. I’ve known people to question why the two-sided noise density isn’t twice as high as the single-sided noise density; after all, doesn’t the term “two” mean twice as much? Of course, the truth is that the same noise power, when accounted for by integration over positive and negative frequency spectrum (two-sided noise spectrum), implies half the spectral density.
Unfortunately, I have seen an experienced contractor make a factor-of-two error in the noise spectral density equation used throughout a complicated radio receiver noise budget spreadsheet. It's perhaps understandable how this could happen, but it's not forgivable when it occurs in a professional context and millions of dollars of development investment are at stake.
Other factors of two occur in such areas as differential versus single-ended voltages, peak versus mean power in sinusoidal waveforms, power-matched potential difference versus Thévenin equivalent source voltage, complex envelope representation of modulated carriers, and many more. The best RF systems engineers not only recall these relationships reliably, but can clearly explain to their colleagues which way round they apply and why.
Few of us start our careers with a comprehensive grasp of all, but hopefully by the time we hold senior engineering positions, we get these things right with high reliability (but not infallibility).
I vividly recall making the mistake early in my career of relying on my memory of a text book equation for power spectral density of noise, and using it for some requirements analysis for a circuit block. I didn’t check whether the text book was using two-sided noise density throughout (it was) and multiplied the density I had by the one-sided bandwidth of my receiver. I was very properly chewed out by a senior engineer who reviewed my work. That guy did me a big favor, even though I found it painful at the time.
This illustrates one reason that well-organized development teams always hold timely reviews of each other’s work. Whether these reviews are formal or informal is less important than that they happen. It's essential to ensure that mistakes and unjustified fiddle-factors are not allowed to live long enough to do real damage.
The value of a bug caught early (especially a system-level bug) is very high to a development organization, and should be treated as such. “Measure twice and cut once,” is still good advice in today’s high tech world, and can generalized to mean: Hold a review before you commit.