You use the compiler, yet you don't know how it works internally. You use SFML, although you don't know the libraries behind it and the interaction with the hardware. This concept is abstraction: Using things as a black box without caring about the implementation details. It's the same with FFT, you won't need to compute the integral or sum yourself. But you have to understand the different signal representations, in order to know what input and output mean.
Ah, to the contrary! In the end we're forced to learn about the things we're using one way or another. I'm aware of how compilers convert between C's high-level language into assembly code, and how different architecture has different machine commands and how one program won't work on another, because ignorance in coding is surely not bliss (not that knowledge thereforth brings much happiness: just better preparation).
Big endian, little endian. Subjects I'd gladly prefer to not have to deal with or remain ignorant of, but they form fundamental to the innerworkings of a machine. And likewise, if there's a problem with the FFT, how does one propose I diagnose it?
Copy-paste programming very rarely works. Lots of little cogs have to be internally shifted before things run together smoothly. If I feed in my noise, I have to know what to do with the output.
Frequency spectrum, straight forward to understand, yes!
But this mathematical function encoded into those funny symbols akin to another language: Chinese room problem. I don't understand them. I'd have to learn what each symbol means, even though I don't know their names or where to start. Ever tried to find the name of a song to which you don't know the lyrics or band name to? It's like that.
As soon as your signal contains the slightest bit of noise, min/max (and thus mid-point) become effectively useless. These metrics only take into account extreme values, which is not a very good representation of the signal.
Not true! Tis only supposed to be an average (you can't work out the 'pitch' of two competing noises, as it's a harmony and you're recording input wrong). Background noise should register less than the peak (noted by the max, which denotes most dominant noise source), and by approximating a fuzzy-logic area for the peak, you know when you've cross the main crest between a given frequency before searching for the mid-point.
Maybe it's slightly inaccurate. But if I wanted accurate, I'd not be a cheapskate and go out and buy the real thing. Or maybe I would become a music maestro and learn pitch-perfect hearing. But I'm musically and therefore pitch oblivious. I just want a tool that takes my voice, extrapolates what pitch it thinks I'm singing so then I can find the right note and manually script the music to each note, maybe in series, to form a song.
I won't discuss with you about that, since success at using libraries depends a lot on personal experience and motivation. What I can say however is that FFT is a very often used functionality (not only in scientific field, but by virtually all media-related applications, especially music players), so you can be optimistic that there are well-tested and optimized implementations out there. But you seem to have made your choice already without even looking at a single library, that's a pity 
Well, you'd think graphics, which is used in every piece of software, would have a straight-forward library for it. But alas, here we are at SFML, what is in effect an Indie development project, because other libraries fail to meet the tasks: licensing (main reason I use SFML is Laurent's permittance for commericialisation, although if I ever get lucky he can expect recompense for his efforts), implementation, or simply obtuse coding language.
But it doesn't. DirectX and it's copyright infringement rage-quit. OpenGL and the license-stranglehold minefield some libraries use or bad implementations.
FFT is no different. I'm lucky in that I was shown SFML and, later, Code::Blocks (the latter of which includes things like posix threads and cross-platform directory headers installed along with the IDE, both extremely useful).
Licensing and installing libraries installs dread and fear in a way it shouldn't (I've wondered why for years why people accept status quo of difficulty adding in libraries and haven't written programs that 'auto-configure' IDEs, compilers etc and the like to get them to work). Such that
losing the entire setup IDE is the main fear and not so much the codebase itself.
I was hoping to make a Code::Blocks only OS of Linux on a LiveCD that could be duplicated (with stuff like SFML etc added) so that if the IDE was ever lost, I could just run another copy of it. That way I could boot the IDE, and thus all libraries, from any machine, anywhere, ever.
(Custom LiveCDs however require tons of space just to modify, and a lot of time. Sigh.)
Why couldn't adding libraries be as simple as 'sudo apt-get SFML' or something for an IDE?
