There are some aspects of software design that are quite difficult to teach and even more difficult to learn. Like elegance in design. I remember helping a colleague with a subroutine to randomly permute a list--just like shuffling a deck of cards. He had this enormous subroutine that generated random numbers then checked them against other numbers. I just shook my head. It's counter-intuitive--at least until you figure it out--but the best way I've found is to generate a list of random numbers, sort them, and then use the shifts so generated to permute the list. In the language we were working with (Interactive Data Language) it's a one-liner.
I don't remember having trouble coming up with this simply because I've worked with simulated random numbers for so long. I've also used sorting for a unique application: calculation of equivalent latitude. Check out the Wikipedia page (which I wrote). I think the algorithm for calculating equivalent latitude is the epitome of elegance and I've discovered a number of very similar tricks for quite different applications.
Not to say that I haven't created my share of bloated code. I remember once writing a piece of code to find local maxima in a gridded, two dimensional field. What I came up with involved dividing the data values into several ranges and using a domain-filling algorithm (not of my own design). Not very accurate and even less fast. A simple, gradient ascent algorithm is faster by far (I know because I eventually rewrote it) or what about just checking for a local maximum in the eight nearest-neighbours?? I recall having tried both at the time, but couldn't get either working. That's the other lesson: sometimes it takes patience to ferret out all the bugs in a piece of code. It also takes confidence in believing that a particular approach will work.
Another particularly embarrassing piece of bloatware I've written involved binning measurement locations from satellite data in the process of interpolating them to a regular grid. The program did work quite well, but I'm pretty sure the binning actually made the algorithm slower. I'm not certain of that since I haven't rewritten it yet. Meanwhile, the indices it generated were gigantic. (I'm still convinced that some type of binning can produce significant speed gains in nearest-neighbour type problems, but I haven't yet been able to come up with the goods.)