> I did not. You're responding to different people. My mistake. I know exactly how much overlap there is. I was a full-time developer— mostly back-end web dev

> I did not. You're responding to different people. My mistake. I know exactly how much overlap there is. I was a full-time developer— mostly back-end web developer but not exclusively— for 10 years before I took the 60 old credits I had going for a computer science degree and started my BFA. While I've done a little completely non-technical design, like branding and identity and print design, most of what I've done is technical, and still do straight dev work from time to time. I've had one foot in each world and am professionally experienced in both, but mostly work in game engines these days. The first programming book I read cover-to-cover, back in the late 90s, was Learning Perl by Larry Wall. He famously said the three most important characteristics of great developers are laziness, impatience, and most importantly for my point, hubris. I see his point— if you're overly conservative about estimating your capabilities, you probably won't attempt genuinely difficult challenges. That hubris helped me push myself, grow as a developer, and solve some cool problems. It also tends to make developers unwittingly look utterly cocky when talking to subject matter experts. More often than not, developers conflate understanding how computers interface with a problem with understanding the problem space itself, and since there is so much overlap, that happens with design more than anything else. I've got probably 10k hours under my belt contributing to FOSS, but unless it was a project I helped maintain, zero (0) percent of that is design work... Even though I could do the job from research, to planning, to implementation. I actually know quite a few hybrid designer/developers for whom that's also true. I've certainly tried, but I haven't in years. Why? Because pretty much every FOSS project is maintained by developers, and almost without exception, they think their interfaces and processes are great, if quirky and a little ugly... But it's no problem as long as users RTFM. In reality, they're just used to the shitty interfaces, and because they lack experience evaluating design, they think that means they're objectively good. That's why you see commits in many repost for user-facing FOSS tools saying things like "addressed UX criticism by implementing custom color themes" which is absolute nonsense. It's also why the only user-facing FOSS tools popular among non-developers are controlled by corporations or foundations with project managers and professional designers. Left to their own devices, developers make interfaces that are only tolerable to people with a working mental model of software, under the hood. The fact is, most developers that assume they know something about design only really know how designs are implemented technically, and for the actual design part, they're just winging it, mostly unknowingly mimicking designs they've seen. They tend to assume that design is mostly a matter of aesthetics and have no idea what the design processes entail, what problems design can and can't solve, or the tools designers wield to solve them. They build to satisfy their own use cases and aesthetic preferences without knowing how to evaluate their fitness for real use. Gatekeeping would be saying that you needed formal training to be a designer, or that you're not a designer unless you use certain tools or processes. I knew a self-taught designer that became the art director for a national magazine and much of his creative process involved sketching things out in hyper card on a decades-old Mac Classic he had in his apartment. However, making the assets that a designer would make without doing any of the work that makes it design is not design, just like cargo-culting 4 deep nested for loops with database calls in a WordPress template is not engineering, even if the end result doesn't seem much different to lay people.