I work alone and don't have much of the complicity which arises in working with teams. Frankly, I'd rather have the complicity than the lack of peer reflection for ideas, inspiration, and even tension (butterflies have better wings with more tension out of the cocoon). But this is my station in professional life for now.
Along with this comes great freedom which allows me to investigate all kinds of ways of solving problems without anyone really to say 'no' to my ideas...I fall often or discover bad practices by engaging in them, but I get up and apply what I learned. Unfortunately, the freedom can cause liquidity in my design because I might fall into thinking "later I can change this". This kind of mindset in the past has caused me pain not only because I would apply Microsoft architectural guidances, resulting in brittle infrastructure, or I'd subtly fall into procedural programming that would be difficult to unravel when change came knocking.
Slowly learning and applying Test Driven Design principles seems to have also created a different mindset in my approach to domain problems, leading me to the Open-Closed Principle. Instead of designing with the assumption that I can change the code base when requirements shift, I now approach new problems with the mindset that my code, since tested and built as robustly as I know how, can NOT change. This is scary at first, but recently I enjoyed the value of this mindset when a potentially domain-shaking change came along in my current application. I didn't touch old code (except for perhaps some refactoring based on new insight...the tests still passed), but rather extended the way I accessed the module of my domain to incorportate the new functionality.
It only took about a week to get the new functionality built in to the domain and I DIDN'T SEND RIPPLES UP THE LAYERS like I used to.
Now I enjoy the challenge of digging around in my toolbox to accomodate this mindset and working alone is less risky.