Something that I've come to realize only in the last couple of years: most programming arguments revolve around personal preference. There are of course optimiz

Something that I've come to realize only in the last couple of years: most programming arguments revolve around personal preference. There are of course optimizations that can be made to actually improve machine performance; these can be found reasonably simply through profiling. At the end of the day, most arguments revolve around "style". It's actually a very tricky subject. If you're working on SMe apps, including startups, most often a given project'style will flow from the lead (or the person/people who initiated the project). They may be good, they may be bad. Invariably, less experienced developers are hired and learn Ro code following this style. Eventually, those less experienced developers become experienced, and leave to persue other projects. And they take that style with them. Depending on the role they have, there is likely still a lead above them. And this is where the arguments begin. The lead had his/her style. The new dev has experience with another style, and it may or may not mesh with the new lead's style. And so the problem perpetuates. It can be very difficult to work with those devs in the early-middle stage of their career. If they are good people, they learn to be flexible, adopt the best parts of all the styles they are exposed to, and eventually become great leads. But many will not, are confrontational, and ultimately poisonous to the teams they are on. If I can quote my favorite philosopher, Ted "Theodore" Logan: "if the only true wisdom lies in knowing, then you know nothing"