11 ms·
Great Hacker != Great Hire (2004)
- greenyoda 6y agoDiscussion from 2008, with some comments by Paul Graham (pg): https://news.ycombinator.com/item?id=244621 https://news.ycombinator.com/item?id=244621
- killtimeatwork 6y agoOMG The PG comment from there is so condescending and self-aggrandizing it's offensive: > The difference is not so much where the software runs as what the goal of the company is. I'm interested in startups: companies that at least try to grow huge. Whereas the "small ISVs" he writes about are just ordinary small businesses that happen to write software. Since in the latter there's little scope for brilliance, you're not willing to trade other things for it. There's PLENTY of ISVs which write complex and ambitious software which would make the brain of an average FAANGer melt. Just look at anything related to computer graphics, geophysics, CAD, data compression etc. Not to mention that a lot of the unicorns are just technically bland web pages that happen to grow huge for reasons unrelated to technical difficulty (see Facebook, Whatsapp etc.). So maybe these unicorns need business brilliance, but I don't think they need technical brilliance all that much.
- adrianN 6y agoYou need some technical brilliance to make bland web pages that serve users at Facebook's scale. I don't know whether you need brilliant engineers right at the beginning when you haven't reached that scale yet.
- username90 6y agoPaul Graham made a store as a service product 1996, at the time it wasn't as easy to create a crud webapp. His views are probably biased by that.
- killtimeatwork 6y agoYeah I agree, web dev was not yet a solved problem in 1996 and maybe Paul just didn't update his biases since then.
- username90 6y ago> There's PLENTY of ISVs which write complex and ambitious software which would make the brain of an average FAANGer melt. Just look at anything related to computer graphics, geophysics, CAD, data compression etc. You don't think your attitude here is condescending and self-aggrandizing?
- username90 6y agoI guess people downvote since the bias against "web dev" is too strong. It isn't like computer graphics, geophysics, CAD or data compression are particularly hard spaces to work on for a software engineer. And if we talk about FAANG in particular, it isn't like they hire people who couldn't hack it in the other fields. I choose to work at Google over other more "pure" tech companies since Google had smarter coworkers and allowed me to work on more pure technical problems. But I bet that some of the people I worked with before would repeat what killtimeatwork said, thinking their company is somehow special just because they sell products instead of web services. Edit: About small more "pure" tech companies, what I learned is that they mostly sell shit. Success was more based on ability to bullshit customers than technical merit.
- killtimeatwork 6y ago> It isn't like computer graphics, geophysics, CAD or data compression are particularly hard spaces to work on for a software engineer. As a software eng. in those spaces, you're required to grasp heavy math (quaternions, Lie Algebras, you name it), find suitable numerical algorithms and implement them them bug-free in a hard-to-work-with low-level language such as C++ (because performance matters). Writing correct code is tough for multiple reasons, for example these numerical algos are not perfect and the glitches you see may be an algorithmic problem and nothing wrong with your implementation. Compare this with the usual backend and web dev, where you're usually writing trivial endpoints which just move data from one system to another. Of course, there are some ambitious roles in the FAANGs (the algos behind distributed databases don't figure out themselves), but they come into the picture later, once the startup is already scaling up.
- 6y ago
- deleted 6y ago[deleted]
- ghroberts 6y agoI find the quoted comment pretty mild. It is the small ISVs "he [Erik Sink] writes about". Around that time there was a market for tons of boring applications that solved a specific small problem. Of course there were interesting ISVs, too: For example, chess programs were driven and improved by small ISVs for a long time. By definition, those ISVs would attract hackers. But it wasn't the majority.
- vizzier 6y agohttps://news.ycombinator.com/item?id=244937 https://news.ycombinator.com/item?id=244937 As per the rule against this, somethings in 12 years truly never change.
- dang 6y agoAlso a thread from 2009: https://news.ycombinator.com/item?id=699569 https://news.ycombinator.com/item?id=699569
- lmilcin 6y agoIsn't it kinda obvious? Same way great person <> ideal spouse for everybody. Great hackers tend to stand alone. If you are master at something it also means everybody or almost everybody has less knowledge than you and this puts you in a kinda precarious situation. You can either slow down for the rest (ie. be ideal "team player") or do work at your own pace (ie. be a "great hacker" or "10x developer"). Or advance to management role... Great hackers tend to require a lot of organization to support them. Somebody needs to do the dirty work that the "great hacker" does not care to complete because he has already set his eyes on another idea. And there tends to be a lot of dirty work... Or they don't require any organization to support them at all. But then they don't scale and are limited by their own (sometimes considerable) output. This is also why you can't have a team full of rock stars and why these experiments tend to fail spectacularly. Either they assume other rockstars in their team are there to do their laundry or they just never cooperate at all and want to solve the problem on their own. "Great hackers" who can do both are worth their weight in diamonds but they are extremely rare. Ideally, if you are great hacker, you want to figure out what kind of person you are and what kind of environment suits your style of work. Likewise, if you are manager, you need to understand "great hackers" are not replaceable cogs and you always need to put more effort into setting up framework with which to extract value from them than with other members of your team.
- username90 6y agoIf you put an average coder with a shitty coder then the average coder will usually become frustrated. If you put a great coder with an average coder the same thing happens. Some can handle it, but it will always be a strain. It isn't more complicated than that. There is no reason to associate a lot of negative personality traits with it.
- zaptheimpaler 6y ago>We want the super-productivity, and we want the innate love of software development, but we don't want all the extra baggage. Instead: > > Hire people who care about users. > Hire people who understand the difference between a job and a hobby. In the same breath he wants people who LOVE their jobs and super-productivity, but yet also understand its only a job. You can't have the super-productivity that comes with intrinsic motivation if the environment is boring and lacks anything that might produce intrinsic motivation. There was a great article about Elon Musk about this from collaborative fund, which I can't find. People love that he's crazy enough to build spaceships and electric cars, but they wish he would just tone down the crazy when it comes to Twitter or whatever controversy he gets into. Its a fundamentally dehumanizing attitude - you DON'T get to pick the good parts of crazy without taking the bad too. You have to take or leave the whole person - warts and all. Most companies ultimately value more predictable and less productive over slightly crazy and more productive. I realized this is kind of my situation.. advice on what do is much appreciated :)
- pizza234 6y ago> Most companies ultimately value more predictable and less productive over slightly crazy and more productive. I realized this is kind of my situation.. advice on what do is much appreciated :) Are you considering yourself as "slightly crazy and more productive" (it's not certain from the wording)? If so, you may want to think in terms of time perspectives. Another way of viewing the dichotomy is "Most companies ultimately value (more predictable and less productive in the short term and more productive in the long term) over (slightly crazy and more productive in the short term and less productive in the long term). Thinking oneself as "more productive" doesn't motivate to build the personal and technical skills required in the long term, instead, it centers the focus on one's ego (I'm cool; if they don't hire me, it's because they're wrong). But I'm also skeptical of the entire concept, at least in some cultures. Excluding staff workers, there's a lot of mobility in American companies, to the point that it's quite common to change company every few years (say, 2 to 5). How "crazy" should one be to start disrupting productivity even before a couple of years?
- deleted 6y ago[deleted]
- arendtio 6y ago> Hire people who understand the difference between a job and a hobby. This line is critical and I think I disagree with the message. I myself have rarely been paid to code, but still do it in my spare time. So I think I understand what the difference between a job and a hobby is, but at the same time I see how much more productive I get, the closer my work comes to my hobby. Yes, it is important to understand that at work you sometimes have to do things which you aren't doing for the immediate fun. But at the same time the closer the hobbies are to the actual work, the more engaged the employee will be. You might think of it as a symbiosis of trying new things as a hobby and bringing the proven things to work while knowing exactly what you are doing.
- Raphmedia 6y agoHowever, if you're only there to exercise your hobby and get paid for it, you may get bored by the other parts of the career. Endless meetings, managing the client, managing the budget, thinking about deadlines, training new hires, working with a team, etc., are all part of the job. Yet, they don't involve writing a single line of code. We often see articles on HN of passionate programmers leaving the industry behind. The reason is rarely the code itself.
- arendtio 6y agoActually, I think working with a team is a core factor. If you enjoy working with your team there are a lot of things others can help you out with. However, you are right, many company cultures happen to struggle to offer a place were you enjoy delivering your best. But I think those companies aren't going to be changed by great hackers botton-up but have to be changed by good managers top-down.
- cbozeman 6y agoWhat this article really says is, "We want the smartest, most obedient workers who will slog through whatever bullshit is required to improve quarterly profits."
- arendtio 6y ago
- OldSchool 6y agoAnyone else see the irony in all of this hacker-bashing on this site called "Hacker News?" Not just in this particular discussion, but overall a shift away from talking about individual, inspired and sometimes entrepreneurial creativity toward how to pass a FAANG-style interview or have better standups and corporate culture.
- ludamad 6y agoHacker news has grown in readership and I assume this explains the shift in tastes. I see it more as commentary than bashing, but I do think the stereotype doesn't mean much beyond valid points than that the traits outlined had negatives. Oh a Great Hacker is one that is productive but won't touch Java? I'm not one then, but what does that really mean
- belval 6y agoIt's a 2004 article which really have to be read through the lenses of the time. Java in 2020 with Kotlin and Scala is pretty far removed from 2004 Java. Same goes for the Windows vs Linux part.
- ludamad 6y agoI'll admit during 2004 I indeed did not want to touch Java or Windows. However, I'd like to say if a project demanded 2004 Java I'd be up for the task now, if the business case was exciting
- PragmaticPulp 6y ago> Not just in this particular discussion, but overall a shift away from talking about individual, inspired and sometimes entrepreneurial creativity toward how to pass a FAANG-style interview or have better standups and corporate culture. Comparing hackers in an individual context is apples and oranges to talking about them in a company context. It's great when hackers use their knowledge and creative energy to create new things or startup new companies. It's not great when super-hackers use their assumed intellectual superiority to make life miserable for their team members and managers. There are plenty of real "hackers" who have the right interpersonal skills and self-awareness to be lead teams in a business context and get work done. Unfortunately, there are plenty of self-described "hackers" who use think their intellectual superiority excuses a lot of bad behavior in the workplace, from stonewalling projects unless/until they get their way to railing against the corporation. If these hackers want to go off and start their own companies then I'm all for it. As a coder-turned-manager, I don't want any self-absorbed hacker types on my team, though.
- RcouF1uZ4gsC 6y ago> Small ISVs don't need people like that I think this becomes a lot less controversial if we realize that the author is specifically talking about a small, independent software vendor. The issue has more to do with leverage. Most software companies are not able to turn a great hacker's ability into a lot of money. As such, the baggage associated with a great hacker is totally not worth it. However, if you can turn that into a lot money, then the baggage associated with them, is not an issue. Take for example John Carmack. It would be a waste of time to hire him to develop your enterprise CRUD app. But if you want to push the limits of gaming and interaction, he is awesome.
- proverbialbunny 6y agoThings have changed since 2004. Back then there was software engineer R&D teams, research engineers, and the like, that were ideal to push "rockstar devs" towards, due to their nature of liking to solve difficult problems above all else. Today we have data scientist and research scientist roles. While some data scientists are glorified data analysts, most of them do exclusive R&D work. This has since created a divide between two types of "rockstar engineers". One type falls to the left side of the Dunning Kruger Effect. They can't understand why everyone else is so stupid. They have a large ego, and they think they're better than everyone else. Then there is the other group, one who specializes in difficult tasks that require a deep domain knowledge. Because of this prerequisite so it can be hard to share work with others, unless they also specialize in that domain. While at first blush the two groups look similar, they're quite different. One advertises themselves as super, has a huge ego, but really they've just taken on too easy challenges. Then there is the other group, who secretly is quite anxious about their own abilities, because of the massive technical challenges they face and have seen. They learn healthy communication and team skills, because what they are doing is so complex they have no other choice. They may at first not appear like a team player, but it has more to do with the nature of their work. This is why it is encouraged that management push the rockstar types into more and more challenging R&D type technical roles, which has the nice side effect of shrinking a large ego. Today this means encouraging them move to research roles or data science type roles. No longer are they top dog when this happens. All of a sudden there is a world of challenge beyond what they can comprehend. It's like taking a straight A high school student and dropping them into a good university. Suddenly they're challenged to do more and go beyond what they knew was possible. And best of all, it gets them out of dev circles where team work is a stronger prerequisite. However, this assumes they're actually a rock star driven to be the best at something, not just the first group with a frail supersized ego.
- briantakita 6y ago> It's okay to be in awe of these great hackers. But as a practical matter, small ISVs would be much better off hiring professionals. I think this more of a matter of ensuring that an employee's objectives are in line with the company in a harmonious way. Rather than blaming a hacker for not falling in line with company practices as being "unprofessional", I would approach this as seeing any employee as a business entity within itself. Some business entities are flexible & willing to work withing your framework. Some business entities already have their own framework, which may or may not be compatible with your framework. A hacker has a brand, a product, & is otherwise also a professional with discipline & ethics. The problem that Eric seems to have had was that his company's framework was not compatible with his employee's framework. Treating a hacker as a business with the many of same considerations of which businesses to partner with or rely on would lead to a more logic based discussion where all considerations are more likely to be articulated without the need to denigrate a person who is incompatible with the company.
- Mauricebranagh 6y agoEric is I think missing the point, you need to hire people for the right team roles - almost all hires are hired as part of a team and there are multiple team roles (check out belbin) And there is a role for the "hacker" just that not all self described "hackers" are the real deal :-) Malwarebytes is a good modern example. Certainly I recall when I worked at British telecom we had a few in London Engineering Centre, including a former phreak (busted for hacking Prestel) some one who's first boss was Dyskaja
- Mauricebranagh 6y agosory reading that back i meant that Malwarebytes is a real hacker.
- derfnugget 6y ago> I'm not saying I am a great hacker, but I do sympathize with this fussiness. Nobody assumed you were. And by sympathize you mean putting forth the argument that "great hackers" are the worst hire an ISV can make? The author portrays himself as a coding by profession, 9 to 5 paycheck programmer, and also as the best possible hire because he has identified the users as being the primary goal. Weird. I assume that the way he writes software is similar to the way he is piggybacking on the passion and expertise of Paul Graham.