18 ms·

The Wolf

178 points by filament 12y ago

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.
hartator 12y ago
I also feel it's wolves who make the best entrepreneurs. But everything is make against the entrepreneur wolf. Even accelerators may destroy the potential of a very strong vision that wolves can't explain. Steve Jobs was certainly a wolf.
- ams6110 12y ago
  Was he? I have't read his biographies but my general impression is that while Steve Jobs was certainly a visionary and an entrepreneur, he was not really an engineer. Did he write a lot of code? Did he really engineer anything? Or did he surround himself with excellent engineers who could create his visions?
  - yzzxy 12y ago
    He was probably the world's best incarnation of the "product manager" role. He conceived and designed (not necessarily visually or technically) most of apple's flagship products, including the Apple Store, which has the world's highest retail volume per square foot. And I can easily see that role being a great place for a Wolf.
  - lutusp 12y ago
    I worked around Steve for years, I couldn't stand him so I spent as little time in his company as possible, but I can say he wasn't an engineer or a serious coder. He was what is now called a "visionary", a catch-all phrase that can mean anything or nothing. When Bill Gates saw bad code, he would sit down and rewrite the code to shame the perpetrator. Steve didn't have that option. This is how he acquired a deserved reputation as a tyrant -- he could only fire people or humiliate them before their coworkers, but he couldn't outperform them. In the early days at Apple, and not to oversimplify, people like me coded the software, while Steve coded the customers. On the general topic of Steve Jobs, I highly recommend the Isaacson biography, excellent book, and one that openly acknowledges Steve's core malady -- pathological narcissism. http://en.wikipedia.org/wiki/Steve_Jobs_(book) http://en.wikipedia.org/wiki/Steve_Jobs_(book)
    - 12y ago
themodelplumber 12y ago
I was working as on a corporate dev team that hit a goldmine at one point, causing management to freak out and go on a hiring spree. They brought at least three wolves on board within a period of a couple months. One of them reminded me of the portrayal of Kameto Kuroshima in the 1970 film "Tora Tora Tora". He would think and think for hours on end, then he'd emerge from his cubicle (all sweaty and dramatic) with a Plan. At that point everything had to change because everyone knew his experience levels blew us all away. When he attended meetings, it was like he was five steps ahead of everybody else, and later I realized that it was because the meetings were usually called as a result of something he decided should change. I could easily see most of the people above him being fired if this guy ever got pissed. One of the other wolves was an experienced college professor who was brought in as a team lead, but who for all intents and purposes was an SVP in the organizational hierarchy. He was financially independent at a fairly young age and basically gave inspirational speeches and CS lectures instead of meetings. We were all freshmen to this guy, and he was light years ahead of our experience levels. I liked these wolves, if that's what they were--they gave me hope that somewhere an executive was really freaked out about making the right call at a critical time.
- S4M 12y ago
  Interesting explanation. Maybe you're not gonna be able to share that, but I would be curious to see some examples of what they did, that is so exceptional. Did they decide to rewrite some critical module using language/framework X, which resulted in a crazy performance gain? Did they completely change the architecture of something which made the whole company (or a whole group of devs) much more efficient?
  - themodelplumber 12y ago
    As I recall, they made the existing software architecture more scalable, maintainable, and available. This was no mean feat, either. Our clients were pretty huge, well-known companies. There was quite a bit of language & framework discussion to go along with all that. But I think their experience levels also just allowed them to accomplish more in less time. To us, they looked like superheroes. We'd get mental blocks trying to think through situations that they had long ago met and conquered. In a similar vein, I think if most of us here at HN went back to our first job, we'd be well ahead of the curve and probably considered "wolves" in a very short time.
rythie 12y ago
In my experience they mostly hate management, thinking they make poor decisions and don't understand the tech. They only want to talk to other very good technical people, which effectively means not communicating very few people. They probably are making good technical descisions that benefit the company, but never communicate this, so don't get the credit. They probably have an internal advocate (e.g. their boss) which communicates what they are doing and defends them.
gatehouse 12y ago
I'm guessing he has chosen the name from Mr. Wolf in Pulp fiction: (profanity warning) https://www.youtube.com/watch?v=wWmRTjLRMfU https://www.youtube.com/watch?v=wWmRTjLRMfU
- UweSchmidt 12y ago
  Was anyone else disappointed by that guy? "Please clean up the mess" is basically what he said.
  - swah 12y ago
    I think he was mostly there to calm down the house owner.
  - the_af 12y ago
    I think eliciting that kind of disappointment in the audience was part of the "point" of the character :) The Wolf also said the coffee was pretty good, by the way.
    - eurleif 12y ago
      I've never thought of him as disappointing before. My reaction to him was: "damn, that guy's effective".
    - coldtea 12y ago
      What dissapointment? That's a bizarro reading of the scene. The Wolf was put there to be impressive -- domineering, knowing how to handle this shit like he's done it 100 times, professional, etc. Not to mention the fact that Tarantino was a huge fan of Harvey.
      - dasil003 12y ago
        And of course Harvey was the reason that Reservoir Dogs got made and possibly the only reason Tarantino has a career.
bsaul 12y ago
I pity the new developpers just starting their career and reading those kind of articles without the minimum amount of skepticism and distance required. Please, if you don't have at least two or three years of actual programming in a real company, don't try to become a "10x" something, or "ninja" or "wolf" or whatever world of warcraft character a manager would like to describe people as. Just be a good employee. Do as being told, and as neil gaiman would say, just "make good art".
- x0x0 12y ago
  I would't call someone a wolf -- it kind of makes the caller sounds like a tool imo -- but I think I have seen different types of engineers along these lines. The sort of people who build projects, getting them to the point where a rough draft is useable then increasingly refining them until you have a 1.0 or maybe a 2.0, do not seem to be the sort of people who are good at taking a 2.0 to a 5.0. The latter need, and need a tolerance for, process which seems to kill the former. Also, the problem with doing as told is you are taking for granted that the person doing the telling is worth listening to. My advice to most new grads is don't do startups. Go to a company like google or fb for the first 2 or 3 years and get a solid handle on good software engineering practices, then go do startups.
- McDoku 12y ago
  It is either in your nature or it is not. We all need good soldiers.
  - tbrownaw 12y ago
    It requires: + At least moderate technical skill, which is acquired thru study and experience. + Significant domain knowledge (understanding of the problem being solved), again acquired thru study and experience. + Sufficient familiarity with the organization you're working in to know what you can and can't get away with, acquired thru social interaction. + Ability to find unexpected better solutions to things. Unless someone's figured out how to teach this, it just requires lots of practice with good feedback. The only "in your nature" here, is whether you find these things interesting enough to put in the required study/practice time.
idlewords 12y ago
The Wolf-not to be confused with the "Free Electron" from a few years ago, or whatever startup Mary Sue character Lopp comes up with next.
ianstallings 12y ago
I know a guy that could be described like this. He's a great programmer and he doesn't follow anyone else's rules but his own. And if you don't like it he'll tell you, politely, why you're wrong and why you should shove off because he's never going to do what you want him to. He has very little patience for meetings, paperwork, or typical processes that don't add anything to the software we're building. When I first worked with him close to 20 years ago, he was fired very quickly. Reason? Because he took our Windows machines and installed Linux on them. Now that might be cowboy to some but in his mind he was helping us. Windows was shit in his mind and he was saving us. Doing the right thing trumped the consequences in his opinion. I gotta say, he's had a tumultuous career, but he still manages to get paid more than I do and do whatever the hell he feels like. And he's made a lot of people a lot of money because of his ways.
- crimsonalucard 12y ago
  Switching jobs often gives you more opportunity to raise your salary.
  - oofabz 12y ago
    But it drops your political capital to zero because now you're the new guy.
    - count 12y ago
      Depends on if you were recruited or if you applied for the job. If someone is working to get you in, you come out of the gate with some political capital...
- k0 12y ago
  There is a level that some employees and consultants reach where "Seniority" is no longer relevant, whether the Consultant is brought into the company either as a Contractor or as an Employee. When I'm brought in it is because no one at the company knows how to fix something, install something, and/or scale something. It doesn't matter how long I have or haven't been with the company, I get it done. I have been fired/terminated because the "Manager" was afraid he'd lose his job or have me promoted above him. I could give two shakes if you've been at a company for 15+ years and have "Seniority" over me. I have vast, real-world experience...you have your very narrow problem set of experience that culminated in not knowing how to do something that resulted in bringing me in. The differences are rarely, if ever, spoken aloud, but are confirmed daily. Sorry, I'm feeling very wolfish today.
unclesaamm 12y ago
It's times like this that I love that I got a psychology major. I can whip up bullshit like this until managers are frothing at the mouths
- idlewords 12y ago
  Ah, you must be what I like to call a "Bull" — an essential factor to startup success!
simi_ 12y ago
Also a good read: http://steve-yegge.blogspot.co.uk/2008/06/done-and-gets-things-smart.html http://steve-yegge.blogspot.co.uk/2008/06/done-and-gets-thin...
tbrownaw 12y ago
This sounds like something that would come with a job title of "internal consultant" or "<whatever> at large" or such, and be at the top of the technical career track.
siliconc0w 12y ago
There was a guy at the last place we worked we jokingly referred to as "the wolf" (pulp fiction man cite your sources). It basically worked like the movie where you'd come over to his cubicle and describe your problem - he'd go "yeah yeah aight mmmmhm" point by point like an interpreter. And the first time this happen you think he isn't paying attention but when you are done he'd process for a bit and the reliably spit out a usually great solution that took in balance the effort required and the business needs.
hellbanner 12y ago
Are they talking about "good programmers"? Don't really see the difference between the two or understand the name "the wolf".
- JackMorgan 12y ago
  I've worked with plenty of "good programmers" who absolutely need a structure and process in order to feel comfortable turning on their machines in the morning. Some people need to feel like they have approval to do anything, and would never suggest a new framework or toolset ever. Most would recoil in horror at someone doing anything different from the Process. I'd argue these developers can do really good work in certain teams, but they need some hand holding.
robobro 12y ago
http://www.bryanthankins.com/techblog/2009/04/12/the-myth-of-the-solitary-programmer/ http://www.bryanthankins.com/techblog/2009/04/12/the-myth-of... http://www.codeproject.com/Articles/503542/TheplusMythplusofplustheplusLoneplusHacker http://www.codeproject.com/Articles/503542/TheplusMythplusof... http://www.safaribooksonline.com/library/view/team-geek/9781449329839/ch01.html http://www.safaribooksonline.com/library/view/team-geek/9781... Counter argument.

178 points by filament 12y ago

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.

hartator 12y ago

I also feel it's wolves who make the best entrepreneurs. But everything is make against the entrepreneur wolf. Even accelerators may destroy the potential of a very strong vision that wolves can't explain. Steve Jobs was certainly a wolf.

ams6110 12y ago
Was he? I have't read his biographies but my general impression is that while Steve Jobs was certainly a visionary and an entrepreneur, he was not really an engineer. Did he write a lot of code? Did he really engineer anything? Or did he surround himself with excellent engineers who could create his visions?
- yzzxy 12y ago
  He was probably the world's best incarnation of the "product manager" role. He conceived and designed (not necessarily visually or technically) most of apple's flagship products, including the Apple Store, which has the world's highest retail volume per square foot. And I can easily see that role being a great place for a Wolf.
- lutusp 12y ago
  I worked around Steve for years, I couldn't stand him so I spent as little time in his company as possible, but I can say he wasn't an engineer or a serious coder. He was what is now called a "visionary", a catch-all phrase that can mean anything or nothing. When Bill Gates saw bad code, he would sit down and rewrite the code to shame the perpetrator. Steve didn't have that option. This is how he acquired a deserved reputation as a tyrant -- he could only fire people or humiliate them before their coworkers, but he couldn't outperform them. In the early days at Apple, and not to oversimplify, people like me coded the software, while Steve coded the customers. On the general topic of Steve Jobs, I highly recommend the Isaacson biography, excellent book, and one that openly acknowledges Steve's core malady -- pathological narcissism. http://en.wikipedia.org/wiki/Steve_Jobs_(book) http://en.wikipedia.org/wiki/Steve_Jobs_(book)
  - 12y ago

themodelplumber 12y ago

I was working as on a corporate dev team that hit a goldmine at one point, causing management to freak out and go on a hiring spree. They brought at least three wolves on board within a period of a couple months. One of them reminded me of the portrayal of Kameto Kuroshima in the 1970 film "Tora Tora Tora". He would think and think for hours on end, then he'd emerge from his cubicle (all sweaty and dramatic) with a Plan. At that point everything had to change because everyone knew his experience levels blew us all away. When he attended meetings, it was like he was five steps ahead of everybody else, and later I realized that it was because the meetings were usually called as a result of something he decided should change. I could easily see most of the people above him being fired if this guy ever got pissed. One of the other wolves was an experienced college professor who was brought in as a team lead, but who for all intents and purposes was an SVP in the organizational hierarchy. He was financially independent at a fairly young age and basically gave inspirational speeches and CS lectures instead of meetings. We were all freshmen to this guy, and he was light years ahead of our experience levels. I liked these wolves, if that's what they were--they gave me hope that somewhere an executive was really freaked out about making the right call at a critical time.

S4M 12y ago
Interesting explanation. Maybe you're not gonna be able to share that, but I would be curious to see some examples of what they did, that is so exceptional. Did they decide to rewrite some critical module using language/framework X, which resulted in a crazy performance gain? Did they completely change the architecture of something which made the whole company (or a whole group of devs) much more efficient?
- themodelplumber 12y ago
  As I recall, they made the existing software architecture more scalable, maintainable, and available. This was no mean feat, either. Our clients were pretty huge, well-known companies. There was quite a bit of language & framework discussion to go along with all that. But I think their experience levels also just allowed them to accomplish more in less time. To us, they looked like superheroes. We'd get mental blocks trying to think through situations that they had long ago met and conquered. In a similar vein, I think if most of us here at HN went back to our first job, we'd be well ahead of the curve and probably considered "wolves" in a very short time.

rythie 12y ago

In my experience they mostly hate management, thinking they make poor decisions and don't understand the tech. They only want to talk to other very good technical people, which effectively means not communicating very few people. They probably are making good technical descisions that benefit the company, but never communicate this, so don't get the credit. They probably have an internal advocate (e.g. their boss) which communicates what they are doing and defends them.

gatehouse 12y ago

I'm guessing he has chosen the name from Mr. Wolf in Pulp fiction: (profanity warning) https://www.youtube.com/watch?v=wWmRTjLRMfU https://www.youtube.com/watch?v=wWmRTjLRMfU

UweSchmidt 12y ago
Was anyone else disappointed by that guy? "Please clean up the mess" is basically what he said.
- swah 12y ago
  I think he was mostly there to calm down the house owner.
- the_af 12y ago
  I think eliciting that kind of disappointment in the audience was part of the "point" of the character :) The Wolf also said the coffee was pretty good, by the way.
  - eurleif 12y ago
    I've never thought of him as disappointing before. My reaction to him was: "damn, that guy's effective".
  - coldtea 12y ago
    What dissapointment? That's a bizarro reading of the scene. The Wolf was put there to be impressive -- domineering, knowing how to handle this shit like he's done it 100 times, professional, etc. Not to mention the fact that Tarantino was a huge fan of Harvey.
    - dasil003 12y ago
      And of course Harvey was the reason that Reservoir Dogs got made and possibly the only reason Tarantino has a career.

bsaul 12y ago

I pity the new developpers just starting their career and reading those kind of articles without the minimum amount of skepticism and distance required. Please, if you don't have at least two or three years of actual programming in a real company, don't try to become a "10x" something, or "ninja" or "wolf" or whatever world of warcraft character a manager would like to describe people as. Just be a good employee. Do as being told, and as neil gaiman would say, just "make good art".

x0x0 12y ago
I would't call someone a wolf -- it kind of makes the caller sounds like a tool imo -- but I think I have seen different types of engineers along these lines. The sort of people who build projects, getting them to the point where a rough draft is useable then increasingly refining them until you have a 1.0 or maybe a 2.0, do not seem to be the sort of people who are good at taking a 2.0 to a 5.0. The latter need, and need a tolerance for, process which seems to kill the former. Also, the problem with doing as told is you are taking for granted that the person doing the telling is worth listening to. My advice to most new grads is don't do startups. Go to a company like google or fb for the first 2 or 3 years and get a solid handle on good software engineering practices, then go do startups.
McDoku 12y ago
It is either in your nature or it is not. We all need good soldiers.
- tbrownaw 12y ago
  It requires: + At least moderate technical skill, which is acquired thru study and experience. + Significant domain knowledge (understanding of the problem being solved), again acquired thru study and experience. + Sufficient familiarity with the organization you're working in to know what you can and can't get away with, acquired thru social interaction. + Ability to find unexpected better solutions to things. Unless someone's figured out how to teach this, it just requires lots of practice with good feedback. The only "in your nature" here, is whether you find these things interesting enough to put in the required study/practice time.

idlewords 12y ago

The Wolf-not to be confused with the "Free Electron" from a few years ago, or whatever startup Mary Sue character Lopp comes up with next.

ianstallings 12y ago

I know a guy that could be described like this. He's a great programmer and he doesn't follow anyone else's rules but his own. And if you don't like it he'll tell you, politely, why you're wrong and why you should shove off because he's never going to do what you want him to. He has very little patience for meetings, paperwork, or typical processes that don't add anything to the software we're building. When I first worked with him close to 20 years ago, he was fired very quickly. Reason? Because he took our Windows machines and installed Linux on them. Now that might be cowboy to some but in his mind he was helping us. Windows was shit in his mind and he was saving us. Doing the right thing trumped the consequences in his opinion. I gotta say, he's had a tumultuous career, but he still manages to get paid more than I do and do whatever the hell he feels like. And he's made a lot of people a lot of money because of his ways.

crimsonalucard 12y ago
Switching jobs often gives you more opportunity to raise your salary.
- oofabz 12y ago
  But it drops your political capital to zero because now you're the new guy.
  - count 12y ago
    Depends on if you were recruited or if you applied for the job. If someone is working to get you in, you come out of the gate with some political capital...
k0 12y ago
There is a level that some employees and consultants reach where "Seniority" is no longer relevant, whether the Consultant is brought into the company either as a Contractor or as an Employee. When I'm brought in it is because no one at the company knows how to fix something, install something, and/or scale something. It doesn't matter how long I have or haven't been with the company, I get it done. I have been fired/terminated because the "Manager" was afraid he'd lose his job or have me promoted above him. I could give two shakes if you've been at a company for 15+ years and have "Seniority" over me. I have vast, real-world experience...you have your very narrow problem set of experience that culminated in not knowing how to do something that resulted in bringing me in. The differences are rarely, if ever, spoken aloud, but are confirmed daily. Sorry, I'm feeling very wolfish today.

unclesaamm 12y ago

It's times like this that I love that I got a psychology major. I can whip up bullshit like this until managers are frothing at the mouths

idlewords 12y ago
Ah, you must be what I like to call a "Bull" — an essential factor to startup success!

simi_ 12y ago

Also a good read: http://steve-yegge.blogspot.co.uk/2008/06/done-and-gets-things-smart.html http://steve-yegge.blogspot.co.uk/2008/06/done-and-gets-thin...

tbrownaw 12y ago

This sounds like something that would come with a job title of "internal consultant" or "<whatever> at large" or such, and be at the top of the technical career track.

siliconc0w 12y ago

There was a guy at the last place we worked we jokingly referred to as "the wolf" (pulp fiction man cite your sources). It basically worked like the movie where you'd come over to his cubicle and describe your problem - he'd go "yeah yeah aight mmmmhm" point by point like an interpreter. And the first time this happen you think he isn't paying attention but when you are done he'd process for a bit and the reliably spit out a usually great solution that took in balance the effort required and the business needs.

hellbanner 12y ago

Are they talking about "good programmers"? Don't really see the difference between the two or understand the name "the wolf".

JackMorgan 12y ago
I've worked with plenty of "good programmers" who absolutely need a structure and process in order to feel comfortable turning on their machines in the morning. Some people need to feel like they have approval to do anything, and would never suggest a new framework or toolset ever. Most would recoil in horror at someone doing anything different from the Process. I'd argue these developers can do really good work in certain teams, but they need some hand holding.

robobro 12y ago

http://www.bryanthankins.com/techblog/2009/04/12/the-myth-of-the-solitary-programmer/ http://www.bryanthankins.com/techblog/2009/04/12/the-myth-of... http://www.codeproject.com/Articles/503542/TheplusMythplusofplustheplusLoneplusHacker http://www.codeproject.com/Articles/503542/TheplusMythplusof... http://www.safaribooksonline.com/library/view/team-geek/9781449329839/ch01.html http://www.safaribooksonline.com/library/view/team-geek/9781... Counter argument.