The technical stack is one thing to me. I view design, the frontend, backend, databases and all the languages, tech, and tooling behind a product as one canvas rather than a stack that requires you to choose what to specialize in. I often bounce between multiple layers during a day of work to avoid the natural fatigue that comes from staring at the same thing for too long.
I prefer to work alone or with a team where each person owns a different part of the system. Collaboration gets in the way quickly. When teams get large, days full of meetings, time estimates, and rigid processes become necessities. They eat up all the time (and joy) that's left for people to actually make things.
I find planning, wireframing, and figuring out the little details of a new feature up-front to be a waste of time. I prefer a few back-and-forths to figure out the big picture with the people I'm working with (usually on a DoneDone ticket), then getting right to building. It's motivating to build on the real thing earlier in the process. You often get to the finish line more efficiently and produce something better.
I use as few tools as possible and try to build my own, specific to what I'm working on. I'm an advocate for writing code generators to generate the tedious, yet trivial, parts of a codebase (Documentation, ORMs, CMSs, API wrappers, etc.).
I believe coding is as much like writing or making music as it is engineering. Writing code is a creative process. You find an idea might strike you when you're doing something totally unrelated. You can do it your own unique way and create something just as valuable as someone who goes about it differently.
I prefer concreteness over abstraction in code. I avoid leaning too heavily on interfaces, abstract classes, generics, and similar concepts. I find the mental cost-of-carry outweighs the rarely-manifested promises of reuse, swappability, and elegance almost every time. Abstraction should be a last resort.
I think there is too much emphasis on (and idolization of) automated testing and TDD. There is too little emphasis on other “practices” that have a larger impact on ensuring safe code—like what to test, naming things well, proper encapsulation, and simply having less people churn on a product.