It sounds like you have a commitment to excellence not shared by your peers. As sibling comment points out, good enough is good enough for most businesses. I like Paul Graham's quote from his book. "The goal of big companies is not to write quality software, but to suck less than their competitors."
My confidence as a software engineer comes from the gratitude of my users. Giving them something that makes them light up and say "I had no idea I needed this." I've worked in many organizations where layers of bureaucracy smother that joy. Having a direct line to my users is incredibly motivating.
Many comments touch on the "do it for the users" mentality and I'll add my own take. There's a book called "The Science of Drawing" by Harold Speed. It's a pretty rigorous dissection of drawing written in 1913. However, despite its clinical writing style, the author notes that the highest praise an artist can receive is "Oh." Not "It's beautiful," or "I really like it," but a raw and spontaneous emotional reaction. Dissecting art is only as useful as a means to produce more of it, the emotional communication is the actual core of the medium. Software is very similar in this way.
Thanks very much for the encouraging reply. This is rather helpful and deep advice.
> It sounds like you have a commitment to excellence not shared by your peers.
Just to be clear, my sentiment is one built up over time and experience and not directed at any one company or colleague. There are kernels of this everywhere though. I'm also a part of it all. I've definitely made things more complex than they've needed to be, but I do attempt to learn from that and revisit approaches.
> Giving them something that makes them light up and say "I had no idea I needed this." ... Having a direct line to my users is incredibly motivating.
This is a really good point, and thank you for saying that. Your advice here is very helpful. I have had the most fulfillment when having a direct user being able to use software I've worked on to do their job better.
> There's a book called "The Science of Drawing" by Harold Speed.
Thanks for this book recommendation! I'm going to check it out.
> the author notes that the highest praise an artist can receive is "Oh." Not "It's beautiful," or "I really like it," but a raw and spontaneous emotional reaction.
Even though it was not intended this way, one of the greatest complements I ever received on software that I personally and solely wrote was someone opening up my code and saying "where's the code?!" in a completely bamboozled way and also a way in which they were legitimately worried if it actually did anything. Haha. They were used to hodge-podge collections of code stuff into a single file doing absolutely everything under the sun. So when they opened up my code, they were legitimately bewildered that everything was modularized, componentized, etc., and for a half minute they were suspicious that there was even anything implemented. It was confusing to them that things were labeled simply as "do this specific thing" (as an abstract example), and it actually just did that specific thing rather than a block of spaghetti code doing something but god knows what.
My confidence as a software engineer comes from the gratitude of my users. Giving them something that makes them light up and say "I had no idea I needed this." I've worked in many organizations where layers of bureaucracy smother that joy. Having a direct line to my users is incredibly motivating.
Many comments touch on the "do it for the users" mentality and I'll add my own take. There's a book called "The Science of Drawing" by Harold Speed. It's a pretty rigorous dissection of drawing written in 1913. However, despite its clinical writing style, the author notes that the highest praise an artist can receive is "Oh." Not "It's beautiful," or "I really like it," but a raw and spontaneous emotional reaction. Dissecting art is only as useful as a means to produce more of it, the emotional communication is the actual core of the medium. Software is very similar in this way.