5 ms·
BTW, I think you’ve misinterpreted “don’t know what they’re doing”†. I’m not talking about code, I’m talking about the business domain. (I thought it obvious fr
by hhas01 7y ago
BTW, I think you’ve misinterpreted “don’t know what they’re doing”†. I’m not talking about code, I’m talking about the business domain. (I thought it obvious from context, but clearly not.) And yes, a depressingly large number of working programmers today have zero interest in learning anything except how to write more code. But how can you write code that solves a user’s problem if you refuse to learn what that problem is and how it was arrived at?
And then you blame the users for “not speccing the job right” when they discover your “solution” not only fails to make their lives any better but often makes it even worse. I’ve worked a decade professionally as a user-turned-developer, so please don’t say this attitude isn’t cultural right down to the bone. I’ve seen it, I’ve dealt with it, I’ve walked out because of it. And looking around me that seems pretty much par for the course.
This is why I like a philosophy of reshaping your stock language into something that much better expresses the business concepts and processes you’re dealing with, then writing your solution in that. It forces you to learn the user’s job before you get underway, because you can’t fake understanding: your new “business language” either does the job or it sucks.
Building up that vocabulary is the first test of whether or not you understand what you’re doing; and until it proves you do you’ve no business proceeding or you’re just wasting everyone’s time (including your own), and giving this industry an even worse reputation for shafting the customer by giving them shit than it already possesses.
--
† Ironically for exactly the reasons I’m talking about: you’re unable to see anything that isn’t about coding. But the code is the least significant part of the overall puzzle; and until you understand the puzzle in its entirety you’re not fit to solve any of it.
TL;DR: I may be nuts, but I ain’t what’s broken.
- AnimalMuppet 7y agoNo, I got that you were talking (at least in part) about the business domain. I have had the privilege of mostly working on smaller projects (two to 20 programmers), where the connection to what the business is trying to do was pretty clear. Maybe I've also had the privilege of mostly working with grownups. Or, possibly, maybe you're too cynical. (Your experience has driven you to that cynicism; mine hasn't. I have no data on which of our experiences best reflects the wider world of programming.) But I agree that, if you don't know what the user needs, you probably can't code it. But I think you're overselling Lisp in this context. The kind of programmer you're talking about, given Lisp, won't develop a "business language" that matches the user needs. They will at best just develop a language that matches the product manager's feature request description, and at worst they'll just start hacking away in Lisp without developing any vocabulary at all. And I think you're misreading where I'm coming from. I can see a lot more than just the code. I totally get that delivering what the user needs is what counts. Just one example: In a hallway conversation, I said we should do X instead of Y because it would be better for the users. The better part of a decade later, I got reminded of that hallway conversation, because it turned out that a litigation-happy competitor had patented Y, and in a court case wanted to apply that patent against us, but couldn't because we didn't actually do Y. I said that the attorneys should say that, if our competitor had patented delivering a worse user experience, they were welcome to the patent on it.