Recently I've been working with a lot of code, TSQL, .NET, report design, etc. that has just made me scratch my head and say to myself "what were you thinking". Well, after reviewing my own work in the last five years, I feel like a schmuck. The farther back I go through the thing I've done, the more I think "who wrote this mess" - with at least some aspect of it.
It's easy to analyze or critique someone else's work. The reason its easy is that you're looking that work out of context. And by context I mean all of the other little things that drastically affect the work we do:
1) Dictated requirements: This has been discussed before on this blog, but really one of the worst things that make you cringe at your own code years later are requirements established by someone that has no idea what the requirements should be. One of my first questions when undertaking anything (even just designing a report) is to ask the business sponser "What business question/problem are you trying to answer/solve with this [report|tool|glob of code|process]." For those of you that ask that question, you know it isn't easy to get an answer. Often any tenacity you show on this front gets shut down by some personal or political agenda. You end up writing something you aren't happy with. That's life in the real world I guess.
2) "Patterns": Every organization does thing a little differently. Every so often a design or programming pattern gets established that really isn't the best approach, but it remains in place because it is the "standard". That pattern or standard continues on with a life of its own, surviving employees and managers. Before you know it you have a code base that new arrivals shake their head at, but its not so easy to just "undo". So the new person gets sucked into the bad patterns, and they live on.
3) "Habit": I'm guilty of this one. People will get into coding habits. Maybe they're use to writing queries using temp tables and never took to table-level variables or CTEs. Maybe the use IN where they should really be using EXISTS. Believe it or not these habits can be very hard to break. People are reluctant to try new things when they have a technique that works; convinces others to use a more efficient technique can be even more difficult.
4) "Deadlines": I'm sure we've all been burned by this. A deadline for a project is put in place regardless of what timeline is appropriate, and we end up cutting corners and writing code we swore we'd never write, just because some has decreed "It must be complete". Yes, this is silliness, but its reality.
So while there are legitimate times to ask "what were you thinking?", try to take it with a grain of salt. Try to understand what context whatever "piece" you're looking at existed in. If you find no logical reason why something should be written "oddly", go ahead and say "what were you thinking". But make sure you take the time to learn the context...