4 ms·

I really like the idea and agree since I've met a couple of people who could meet that description. The problem always seems to be identifying the Wolves from

by adwf 12y ago

I really like the idea and agree since I've met a couple of people who could meet that description. The problem always seems to be identifying the Wolves from the Cowboys. ie. Telling the difference between a "10x" coder who will live outside the rules and get things done, versus a "10x" coder who lives outside the rules and leaves you with a humungous mess of undocumented, unmaintainable spaghetti code when he leaves. Resulting in potential negative productivity by the end. Does anyone know any reliable ways of telling the difference? Beforehand I mean; it's easy to tell in hindsight. Or is it better to avoid hiring both Wolves and Cowboys, but count your blessings if you accidentally get a Wolf anyway?

lutusp 12y ago
> Does anyone know any reliable ways of telling the difference? Beforehand I mean; it's easy to tell in hindsight. Sure, here are some: * Ask the opinion of people who have worked with the candidate. * Arrange for the candidate to explain some of his recent code and its workings to someone unfamiliar with his specialty. +1 if the listener comes away understanding the code. * Ask the candidate to write a short algorithm that solves an uncommon problem, see what kinds of methods and variable names he uses, and whether there are enough comments (not too many, not too few) and structural clarity that the code could be maintained by a third party. Most programmers don't want to be replaced, but the dangerous ones are those who think they can't possibly be replaced. Some of the latter group code in such a way that their personal belief becomes a self-fulfilling prophecy.
x0x0 12y ago
Spaghetti code isn't necessarily bad code. It's impossible to decide without understanding the business circumstances. Our job isn't to write code; it's to create business value. If the business value of doing a hack job really fast outweighs the cost of doing things in a maintainable way, it was the right thing to do. Finally, the problem with hiring a so-called wolf is you can't. Acting that way relies on having credibility within the org that you can only build by having a track record of delivering stuff for senior execs. And that you can almost certainly only create by working for a company for a long time.
- gknoy 12y ago
  Spaghetti code isn't necessarily bad code. .... understanding the business circumstances. Our job isn't to write code; it's to create business value. I'm not sure I agree. Superficially, that's true. However, I've frequently seen the "business circumstances" change dramatically from what had previously implemented. Sometimes it's a month later, sometimes a year later, but having a system where Someone Else can understand what's going on, and where there was a coherent design to deliver the business logic, has been critical to letting us change things easily, and know we did it right. Hacking something out can work, but I'd be very very wary of saying "As long as it's creating more business value, it's OK" -- because it makes it more expensive to deliver future/changed business value next time.
  - deleted 12y ago
    [deleted]
  - Schwolop 12y ago
    In my experience, the change in business circumstances is precisely what creates the spaghetti code in the first place. It's far easier to write a beautiful extensible system if you have solid unchanging requirements - when the reqs change in foreseen ways that extensibility looks like great foresight. When the reqs change unpredictably, often all that work on extensibility is wasted or even detrimental because the changes required are deeper or different to what the original system made possible. I think some of the art of software engineering is in the softer skill or predicting how requirements are likely to change in the future, and building in extensibility only where its likely to be needed (or is easy to get for free/cheap, which sometimes happens too.) It's like YAGNI vs pragmatism.
    - gknoy 12y ago
      some of the art of software engineering is in ... predicting how requirements are likely to change in the future, and building in extensibility only where needed I agree. I've definitely fallen into the trap of overengineering an extensible, multi-use solution for something that gets used once. I've also been blessed to be encouraged by my boss to go all-in on reusability on a different feature, which turned out to have really paid dividends now that pretty much every subsequent feature request has been able to be handled without hassle. It's definitely a skill I expect to continue to improve at over my career. :)
McDoku 12y ago
Spaghetti code sells the same alas. In the CF these are called fighting men. Average is that you train 8 guys and you will likely have 2 in the unit. Sometimes zero, sometimes three. See how they operate in the trenches. Or give them a restrictive position to see who disobeys intelligently. Keep in mind they like to eat, so feed them. Otherwise, well they get bored and sheep are tasty.
- McDoku 12y ago
  Let me clarify. I love good code, but many investors do not know the difference and are more interested in the pitch instead of the product. It does not mean I approve or code in that manner myself, but that I have come across hack jobs worth buckets and great code worth nothing. It is just a fact of life. Also yeah... wolves get bored and can be very destructive or just check out to other projects.
coldtea 12y ago
>The problem always seems to be identifying the Wolves from the Cowboys. ie. Telling the difference between a "10x" coder who will live outside the rules and get things done, versus a "10x" coder who lives outside the rules and leaves you with a humungous mess of undocumented, unmaintainable spaghetti code when he leaves. The problem is by-the-book, team-work friendly "soldiers" also tend to leave a mess of BS architecture decisions and crappy spaghetti code when they leave...
kirvero1 12y ago
From what I've seen, the difference with the depth of understanding of the organization- its mission, goals, capabilities, and failings, and commitment to work with the organization's interests in mind. The Cowboy is- consciously or not- out for himself, and imagines the organization to be something other than it is in order to be able to present himself with some technical problem that he wants to solve. The problem the Cowboy is solving for is more or less irrelevant in the context of a deep understanding of the needs of the organization. The Wolf is aware of the organization as it is, works to solve the most important problem the organization faces, using technology, whether or not others in the management or executive hierarchy understand. This situation can arise particularly in older organizations that are in the midst of making a major transition, or facing major competitive or existential pressures. Strong engineers are often able to see the new physics by which digital businesses need to operate by before others, and may need to make decisions in accordance with that physics. TLDR: the Cowboy solves deep technical problems that are irrelevant to the business. The Wolf solves deep business problems using technology.
jonstewart 12y ago
I think it's pretty rare to set out to hire a wolf, although a manager of a large, well-resourced team could do so just to shake things up. That would be tough, though, since it is very difficult to come in from the outside and perform as a wolf immediately. My own experience has been, instead, that a wolf emerges from the herd after 6–12 months. They've learned the culture, they've learned the personalities, they've learned the dividing line between the strictly forbidden and the mostly forbidden. Your juvenile wolf will show a propensity for solving long-standing hard problems that had long been deferred or inventing new trifles. A cowboy may act similarly, but generally gets into more trouble and has less substance behind his solutions. A kludge is a hack that works; a wolf is a cowboy who gets the kill. It is at this point that you must act to place new wolves in an environment where they can excel. I think customer-facing interdisciplinary teams work well, where success is demanded, glory is possible, market feedback is immediate, and they provide unique skills to the team. You can also place them on more seasoned technical teams, where the burden of management is a bit lighter. I am a wolf (it's been over a decade since I told my first manager I wanted to become "the wolf", a la Pulp Fiction). There are downsides. The more process-driven the management, the more battles you will have to fight. The wolf often wins, but not without injury. Corporate combat is exhausting and, worse, can become an end unto itself. Also, being always on the hunt often precludes working on a single large project for a sustained period of time. A wise wolf must remember to hunt big game instead of feasting on readily-available mice. In other words, it's easy for the wolf to become the asshole. Both proper management and self-awareness can keep this from happening.

by adwf 12y ago

lutusp 12y ago

> Does anyone know any reliable ways of telling the difference? Beforehand I mean; it's easy to tell in hindsight. Sure, here are some: * Ask the opinion of people who have worked with the candidate. * Arrange for the candidate to explain some of his recent code and its workings to someone unfamiliar with his specialty. +1 if the listener comes away understanding the code. * Ask the candidate to write a short algorithm that solves an uncommon problem, see what kinds of methods and variable names he uses, and whether there are enough comments (not too many, not too few) and structural clarity that the code could be maintained by a third party. Most programmers don't want to be replaced, but the dangerous ones are those who think they can't possibly be replaced. Some of the latter group code in such a way that their personal belief becomes a self-fulfilling prophecy.

x0x0 12y ago

Spaghetti code isn't necessarily bad code. It's impossible to decide without understanding the business circumstances. Our job isn't to write code; it's to create business value. If the business value of doing a hack job really fast outweighs the cost of doing things in a maintainable way, it was the right thing to do. Finally, the problem with hiring a so-called wolf is you can't. Acting that way relies on having credibility within the org that you can only build by having a track record of delivering stuff for senior execs. And that you can almost certainly only create by working for a company for a long time.

gknoy 12y ago
Spaghetti code isn't necessarily bad code. .... understanding the business circumstances. Our job isn't to write code; it's to create business value. I'm not sure I agree. Superficially, that's true. However, I've frequently seen the "business circumstances" change dramatically from what had previously implemented. Sometimes it's a month later, sometimes a year later, but having a system where Someone Else can understand what's going on, and where there was a coherent design to deliver the business logic, has been critical to letting us change things easily, and know we did it right. Hacking something out can work, but I'd be very very wary of saying "As long as it's creating more business value, it's OK" -- because it makes it more expensive to deliver future/changed business value next time.
- deleted 12y ago
  [deleted]
- Schwolop 12y ago
  In my experience, the change in business circumstances is precisely what creates the spaghetti code in the first place. It's far easier to write a beautiful extensible system if you have solid unchanging requirements - when the reqs change in foreseen ways that extensibility looks like great foresight. When the reqs change unpredictably, often all that work on extensibility is wasted or even detrimental because the changes required are deeper or different to what the original system made possible. I think some of the art of software engineering is in the softer skill or predicting how requirements are likely to change in the future, and building in extensibility only where its likely to be needed (or is easy to get for free/cheap, which sometimes happens too.) It's like YAGNI vs pragmatism.
  - gknoy 12y ago
    some of the art of software engineering is in ... predicting how requirements are likely to change in the future, and building in extensibility only where needed I agree. I've definitely fallen into the trap of overengineering an extensible, multi-use solution for something that gets used once. I've also been blessed to be encouraged by my boss to go all-in on reusability on a different feature, which turned out to have really paid dividends now that pretty much every subsequent feature request has been able to be handled without hassle. It's definitely a skill I expect to continue to improve at over my career. :)

McDoku 12y ago

Spaghetti code sells the same alas. In the CF these are called fighting men. Average is that you train 8 guys and you will likely have 2 in the unit. Sometimes zero, sometimes three. See how they operate in the trenches. Or give them a restrictive position to see who disobeys intelligently. Keep in mind they like to eat, so feed them. Otherwise, well they get bored and sheep are tasty.

McDoku 12y ago
Let me clarify. I love good code, but many investors do not know the difference and are more interested in the pitch instead of the product. It does not mean I approve or code in that manner myself, but that I have come across hack jobs worth buckets and great code worth nothing. It is just a fact of life. Also yeah... wolves get bored and can be very destructive or just check out to other projects.

coldtea 12y ago

>The problem always seems to be identifying the Wolves from the Cowboys. ie. Telling the difference between a "10x" coder who will live outside the rules and get things done, versus a "10x" coder who lives outside the rules and leaves you with a humungous mess of undocumented, unmaintainable spaghetti code when he leaves. The problem is by-the-book, team-work friendly "soldiers" also tend to leave a mess of BS architecture decisions and crappy spaghetti code when they leave...

kirvero1 12y ago

From what I've seen, the difference with the depth of understanding of the organization- its mission, goals, capabilities, and failings, and commitment to work with the organization's interests in mind. The Cowboy is- consciously or not- out for himself, and imagines the organization to be something other than it is in order to be able to present himself with some technical problem that he wants to solve. The problem the Cowboy is solving for is more or less irrelevant in the context of a deep understanding of the needs of the organization. The Wolf is aware of the organization as it is, works to solve the most important problem the organization faces, using technology, whether or not others in the management or executive hierarchy understand. This situation can arise particularly in older organizations that are in the midst of making a major transition, or facing major competitive or existential pressures. Strong engineers are often able to see the new physics by which digital businesses need to operate by before others, and may need to make decisions in accordance with that physics. TLDR: the Cowboy solves deep technical problems that are irrelevant to the business. The Wolf solves deep business problems using technology.

jonstewart 12y ago

I think it's pretty rare to set out to hire a wolf, although a manager of a large, well-resourced team could do so just to shake things up. That would be tough, though, since it is very difficult to come in from the outside and perform as a wolf immediately. My own experience has been, instead, that a wolf emerges from the herd after 6–12 months. They've learned the culture, they've learned the personalities, they've learned the dividing line between the strictly forbidden and the mostly forbidden. Your juvenile wolf will show a propensity for solving long-standing hard problems that had long been deferred or inventing new trifles. A cowboy may act similarly, but generally gets into more trouble and has less substance behind his solutions. A kludge is a hack that works; a wolf is a cowboy who gets the kill. It is at this point that you must act to place new wolves in an environment where they can excel. I think customer-facing interdisciplinary teams work well, where success is demanded, glory is possible, market feedback is immediate, and they provide unique skills to the team. You can also place them on more seasoned technical teams, where the burden of management is a bit lighter. I am a wolf (it's been over a decade since I told my first manager I wanted to become "the wolf", a la Pulp Fiction). There are downsides. The more process-driven the management, the more battles you will have to fight. The wolf often wins, but not without injury. Corporate combat is exhausting and, worse, can become an end unto itself. Also, being always on the hunt often precludes working on a single large project for a sustained period of time. A wise wolf must remember to hunt big game instead of feasting on readily-available mice. In other words, it's easy for the wolf to become the asshole. Both proper management and self-awareness can keep this from happening.