Respecting other professions.<p>By that, I mean getting over any mentality that accountant are simply bean counter, sales peoples are just talentless people riding on charisma, etc...<p>All those stupid tribal mentality will hinder the programmer's ability to think about the project holistically, and propose the right technical tradeoff.<p>I had the luck of working in a company that not only had very good dev team and CTO, but also a very smart CEO and non-tech teams. As a result the sales & business decision were done with technical possibilities (and limitations) in mind, while the technical choices were done with business problematic in mind. That was by far the best codebase I've seen, because there was a lot of smart, 'out-of-the-box thinking' kind of technical stuff in it where it mattered, and also lot of technical simplicity or even 'cowboy coding' when it also mattered.<p>I believe that there is a continuum where the most limiting thing you can do for your tech skills is to identify yourself with your technical stack. Don't be a 'Javascript programmer', or worse, a 'React programmer'. I fact try to not even think of yourself as a 'programmer', because that will push you into thinking that 'problem-solving' implies a programming exercise, of course only with your usual tools.<p>That's often the case, but the most elegant solution to a problem is to not even have a problem in the first place, and that requires programmers to think about the project and the objectives in a level possible only when thinking (or listening) in term of added value in the business, sales problematic, financing issues, legal issues, and so on. By working with those 'non-technical' teams, you can acquire by osmosis their way of thinking, and be able to argue technical issues way more efficiently, while also being able to cut corner when it makes sense.<p>Reading everything I've written above, you might be tempted to think that I see programming only as a mean to an end, and don't care about code quality. I do like "programming for programming sake", like reading SCIP, playing with data structures, looking up esolangs, or more pragmatically thinking deeply about the dataflow of an application and what are the most appropriate data structures.<p>What I don't like however, is when programming become self-masturbating in a way that are neither enlightening, nor impactful. I've once joined a company that was obsessive about linting, improving their CI/CD processes, and following 'best practices' in the most jarring way. Some devs even wanted to switch libraries for a newer one based on the number of Github stars. The business side of things was basically burning down due (in part) to a lack of appropriate features in the product, but it's wasn't really a problem as long as Typescript was configured to be as strict as possible, and linters too, that will surely means something about quality I guess. Somehow, the company folded 6 months after.