Earlier quoted context omitted.
One of my least favorite tendencies of software developers is assuming they can pull apart non-technical/mathematic problems involving human complexity, even at a societal scale, with a series of logical thought experiments like they’re debugging software, and that their “bug fixes” and doc updates would tidy everything up with people as effectively as it does with processes. As complex as software can be, it hasn’t…
As is true for many people, I have found myself in the terrible situation of having acted with the best of motives, only to find later that my actions were harmful to others. The question is always, what do we do when that happens? How to we look at ourselves in the mirror? This is an ethical, not moral issue. One choice is simply denial, but I do not like myself when I choose that. Another is not to act because ther…
Like a lot of developers my age, the first programming book I read all the way through was the brilliant Learning Perl by Larry Wall. Likely the most quoted passage from that book isn't about programming, but about programmers: "The three chief virtues of a programmer are: Laziness, Impatience and Hubris." The book was funny, and that passage was intended to be humorous commentary on the bravado a little beneficial Dunning-Krueger can give us when approaching a problem in unfamiliar space. It's a joke about starting a projects and not letting daunting tasks kill your optimism: it's not a set of maxims that developers should model their life philosophy on.
One invaluable thing I got from my formal design education was not trusting my assumptions about the needs, perspectives, motivations, and capabilities of other people, or the complexities of the systems in which they operate. In many ways, this directly opposes Wall's Laziness, Impatience and Hubris. This is why interface designers make better interfaces than developers. It's all about pushing back against your own perspective and trying to untangle the messy human element to see what people really need-- in the case of software, what they need to most effectively and efficiently solve their problems-- and how best to provide that for them.
But it's a yin/yang thing. A whole lot of problems in this world have only been solved because someone didn't realize they were trying to solve an insolvable problem, until they did it. But there's a real danger in operating under the assumption that we've got this pan-topic expertise that allows us to slice through any subject with a few quick swipes of our super duper ultrabrains using a few mental calculations based on a couple assumptions and approximate a couple of things about human behavior based on the way we understand it, intuitively. That's lost on a lot of developers and engineers-- especially younger ones. (And after working with developers as a designer rather than as a developer for a while, I understood how infuriating that could be.) When it comes to things like advertising, where people are so heavily peppered with them, and quite possibly have worked on their technical underpinnings, they assume that they "understand advertising" instead of understanding their conscious experience with advertisements.
There are lots of terrible odious things that happen in marketing and advertising and you'll rarely find someone as critical of them as me. As a developer, I've come close to quitting jobs in protest of putting in some creepy telemetry in things I developed, and successfully skewered those initiatives. However, the pushback against advertisements generally is misguided. It's a huge topic that people paint with a broad brush based on their experience with ads. If you're interested in my thoughts, I was pushing back against someone that said we simply could do away with advertisements in this over-long comment: