5 ms·

The Ferengi Programmer

13 points by bdotdub 18y ago

ntoshev 18y ago
There are many ways to write a small piece of software so that it conforms to certain specs. Rules, even if arbitrary, tell a developer what is a "better way" and reduces the doubts he has about how to write that code. So developers, especially novices, like rules. Software engineering is fundamentally about trade-offs and it seems plain rules like IF context THEN follow_recipe are not expressive enough. Like a database engine, rules based optimizer will only take you so far, for better results you need to use cost based optimizer, and learning the costs associated with each option only comes with experience.
michael_dorfman 18y ago
I'd be more inclined to believe Jeff when he says he doesn't need the rules, if I had some evidence he actually knew them. From what I can see, the problem of "overly-rule-bound developers" is nowhere near the magnitude of the problem of "developer's who don't really have a clue."
- redrobot5050 18y ago
  Yeah. As codinghorror's userbase goes up, its relevance declines. I'm still waiting for a "Wiley Coyote and The Don't Repeat Yourself Rule" post or something equally nonsensical. Zed Shaw actually wrote a blog post about how these two guys were at a conference and he called him out on his shit. You can't talk tell everyone something like "real software is written by people who's income is directly proportional to their user base" when you've spent your whole life as a consultant to in house IT departments.
  - codinghorror 18y ago
    you know Zed worked at Bear Stearns, right.. on in house IT stuff? I was one of the people at CUSEC urging him to get the hell out of there. Ultimately BS went out of business while Zed was there, so I guess it's moot.
    - redrobot5050 18y ago
      Yeah, he was quick to point out he was razzing Atwood. And Its been been written that the Zed Shaw personality that writes online and the Zed Shaw personality that you'd meet in meatspace are complete opposites. But still..."Ferengi Programmer" metaphors are unclear at best, terrible at its worst. There's a way to highlight the danger you're talking about ("religious adherence to coding standards / design patterns without comprehension") without being so gimmicky and still be entertaining.
- codinghorror 18y ago
  > From what I can see, the problem of "overly-rule-bound developers" is nowhere near the magnitude of the problem of "developer's who don't really have a clue." The deeper problem is that developers who don't have a clue are immune to rules. Throwing a book of rules at a sucky programmer just creates a sucky programmer with a bruise where the book bounced off their head. So, who, exactly are we writing these rules for, again?
msg 18y ago
It's like human machine learning. Rules are what you use to program programmers. If your aims are limited and it's a good set of rules, why not. If you want to use your programmers to do something you don't know how to do, instead create an environment that evolves the right kinds of programmers and set them loose.
akeefer 18y ago
Following rules slavishly is a pretty easy target; of course you want to do X because you think it's the right idea, not just because someone else told you to do it. But at the same time, often the only way to develop the intuition and experience to know when to follow those rules (even if it's hard) and when to break the rules is to blindly follow the rules for at least a little while so that you get a feel for them. How do they fit with your personality or problem space? Which parts seem to add value or prevent mistakes? Which parts are getting in your way? Which parts add value some of the time but not if you have to try too hard to follow them? Any idiot can come up with a set of "rules" that other people should follow, but there are also plenty of incredibly intelligent, experienced people who have attempted to distill their knowledge for other people in that form. Dismissing them out of hand and then patting yourself on the back for it ("I'm an awesome programming precisely because I don't follow other people's rules") is not the way forward. To me, part of being a good programmer is being able to temporarily put aside your existing notions of what's good or bad, what will work and what won't, in order to try out someone else's way of working so that you can truly internalize it and hopefully learn something new. That applies not just to following simple "rules" about how to structure your code, but to trying out new styles of development, new programming paradigms or languages, new toolsets, etc. All of those require the ability to temporarily suspend your judgment about what works and what doesn't and to just try to do something "by the book" for a bit in order to hopefully come out the other side an even better programmer.

13 points by bdotdub 18y ago

There are many ways to write a small piece of software so that it conforms to certain specs. Rules, even if arbitrary, tell a developer what is a "better way" and reduces the doubts he has about how to write that code. So developers, especially novices, like rules. Software engineering is fundamentally about trade-offs and it seems plain rules like IF context THEN follow_recipe are not expressive enough. Like a database engine, rules based optimizer will only take you so far, for better results you need to use cost based optimizer, and learning the costs associated with each option only comes with experience.

michael_dorfman 18y ago

I'd be more inclined to believe Jeff when he says he doesn't need the rules, if I had some evidence he actually knew them. From what I can see, the problem of "overly-rule-bound developers" is nowhere near the magnitude of the problem of "developer's who don't really have a clue."

redrobot5050 18y ago
Yeah. As codinghorror's userbase goes up, its relevance declines. I'm still waiting for a "Wiley Coyote and The Don't Repeat Yourself Rule" post or something equally nonsensical. Zed Shaw actually wrote a blog post about how these two guys were at a conference and he called him out on his shit. You can't talk tell everyone something like "real software is written by people who's income is directly proportional to their user base" when you've spent your whole life as a consultant to in house IT departments.
- codinghorror 18y ago
  you know Zed worked at Bear Stearns, right.. on in house IT stuff? I was one of the people at CUSEC urging him to get the hell out of there. Ultimately BS went out of business while Zed was there, so I guess it's moot.
  - redrobot5050 18y ago
    Yeah, he was quick to point out he was razzing Atwood. And Its been been written that the Zed Shaw personality that writes online and the Zed Shaw personality that you'd meet in meatspace are complete opposites. But still..."Ferengi Programmer" metaphors are unclear at best, terrible at its worst. There's a way to highlight the danger you're talking about ("religious adherence to coding standards / design patterns without comprehension") without being so gimmicky and still be entertaining.
codinghorror 18y ago
> From what I can see, the problem of "overly-rule-bound developers" is nowhere near the magnitude of the problem of "developer's who don't really have a clue." The deeper problem is that developers who don't have a clue are immune to rules. Throwing a book of rules at a sucky programmer just creates a sucky programmer with a bruise where the book bounced off their head. So, who, exactly are we writing these rules for, again?

msg 18y ago

It's like human machine learning. Rules are what you use to program programmers. If your aims are limited and it's a good set of rules, why not. If you want to use your programmers to do something you don't know how to do, instead create an environment that evolves the right kinds of programmers and set them loose.

akeefer 18y ago

Following rules slavishly is a pretty easy target; of course you want to do X because you think it's the right idea, not just because someone else told you to do it. But at the same time, often the only way to develop the intuition and experience to know when to follow those rules (even if it's hard) and when to break the rules is to blindly follow the rules for at least a little while so that you get a feel for them. How do they fit with your personality or problem space? Which parts seem to add value or prevent mistakes? Which parts are getting in your way? Which parts add value some of the time but not if you have to try too hard to follow them? Any idiot can come up with a set of "rules" that other people should follow, but there are also plenty of incredibly intelligent, experienced people who have attempted to distill their knowledge for other people in that form. Dismissing them out of hand and then patting yourself on the back for it ("I'm an awesome programming precisely because I don't follow other people's rules") is not the way forward. To me, part of being a good programmer is being able to temporarily put aside your existing notions of what's good or bad, what will work and what won't, in order to try out someone else's way of working so that you can truly internalize it and hopefully learn something new. That applies not just to following simple "rules" about how to structure your code, but to trying out new styles of development, new programming paradigms or languages, new toolsets, etc. All of those require the ability to temporarily suspend your judgment about what works and what doesn't and to just try to do something "by the book" for a bit in order to hopefully come out the other side an even better programmer.