There's definitely a huge ego thing in distinguishing yourself as a "real programmer" or perhaps a "software engineer," vs. "a <x> who programs" or "a weekend h

There's definitely a huge ego thing in distinguishing yourself as a "real programmer" or perhaps a "software engineer," vs. "a <x> who programs" or "a weekend hacker." In other words, a professional vs. an amateur. I don't think it reflects at all on the quality of the work, though, just on the attitude brought to the table. The professional is going to want to overengineer, more often than not, because surely, with all the vast knowledge and experience they've accumulated, tackling the business's requirements with a quick hack is beneath them when they could do a "real" long-term solution instead! Right? Coming at it from the "amateur" perspective instead is going to shift the perspective towards the opposite - the underengineered "good enough for now" solution that may ignore fundamental architectural problems until they've blown up into huge monsters. So for a startup or early-stage product, the amateur attitude is probably the more worthy one, and as the concept establishes itself into more refined forms, professionalism, process, and specialization can take hold. But the skills could easily be just as good from either angle - you just have to learn to "flip the switch" and use the right attitude for each situation. I've spent a long time obsessing over programming practice, and it's only been recently that I've managed to make myself back off. This conveniently started to happen only as I started pushing myself 100% to build a real, user-facing product, vs. some development tool or hack.