OMG 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.
You 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.
> 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?
I 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.
> 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.
> 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).
None of that is particularly hard though. Quaternions and lie algebras sound esoteric but are simple to work with, C++ is standard basically anywhere that cares about performance including a large part of Google, and finding suitable algorithms and implementing them bug free is the absolute minimum of what is expected of people.
Now, the work people do at Google isn't that hard either, but it isn't like your average engineer could easily do the job. At Google it is expected that a typical mid level engineer can design and build systems to handle millions of QPS, be fault tolerant to prevent errors from propagating and bringing all of Google at once, know how to write distributed scripts to do operations on user data like migrating it without bringing down the service, know how to debug errors in distributed systems, track it between servers and try to find its origin, create useful health metrics for servers so you can see what is going on since you have thousands of them at once and you can't look at them individually, etc. In practice the end result is that they just copy data between servers, but copying data at reasonable cost to the right places on live servers when you have many thousands of servers all over the world is hard.
And that is just the typical boring backend job, a significant part of Google is only low level libraries, algorithmic performance, machine learning, databases, compiler optimizations for C++, video encodings, etc etc. I've worked on both at Google and I wouldn't say that one is harder than the other, however working on algorithms and libraries is more fun and less stressful than backend work so I prefer it. Also the team working at the more "fun" stuff wasn't that much better either, I don't think the people working at backend would have a terribly difficult time doing those jobs either. After all Google does interview and hire everyone as if they would work on interesting technical stuff, so everyone knows at least the basics of maths and algorithms.
> 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.
You talked about the typical FAANG engineer though. They aren't geniuses but they are still pretty smart. You shouldn't underestimate them.
> and finding suitable algorithms and implementing them bug free is the absolute minimum of what is expected of people.
That was perhaps true in 1990. Currently, most people just call a library that does what they want and don't know or care what kind of an algorithm is implemented behind the scenes - let alone implement the algorithm themselves.
I 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.
Isn'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.
If 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.
I meant it as mutual i.e. neither suffers. And I meant mediocre coders as in average, "not exceeding expectation".
Suffers implies something destructive and I would hardly call working with ordinary men being destructive even though obviously the outcome might be better if all coders are great, even thought that is hardly realistic for most setups, especially bigger.
I think it is a little bit more than putting together coders of very different skills.
It is not just that the difference in skills causes frustration but also that frustrations over long period of time also influence the developer.
For example, if you have observed, over long period of time, that people are generally slow and unreliable, that your products tend to work better, that you can think up better designs without bothering to talk to your team,
... wouldn't that influence your character and the way you typically interface with other developers?
It is not that he/she became a great developer suddenly. This must have taken years.
Ye doing it yourself without outsourcing even the tiniest bit to your teammates is usually way more smooth and easy - keeping collaboration on a higher level.
I just can't seem to share the plan in my head in a good way. Probably becouse it is very fuzzy until it is done.
This is why I hate Scrum where tasks are supposed to be broken down and shared between the team members and the last person touching the issue has to ensure everything works together ...
You're not the only one. I work with quite a few above-average and bright guys. Even something as simple as "you make this module, you make this module, I make this module and they all communicate through this core interface" is far from trivial. In something like Scrum, the emphasis seems to be more on "everyone works on this little piece of this module", which bloats the communication overhead required and I get into the same problem you describe: implementation details need to be made concrete much faster, as now people need to know them to proceed instead of a general idea what data they'll be getting.
NB: I know this is not specific to Scrum, and Scrum does not enforce this. Yet I can't help but feel there is some sort of correlation.
Is it? Often times I feel Scrum was more invented as a way to centralize communication under the lofty goal of increasing its quality, and decreasing the quantity of communication (make all activities central to reduce decentralized meetings with loads of people). Which to me says the opposite of making communication cheap.
In practice, I feel the opposite tends to happen too. Not only does the quantity increase, but the quality of these centralized activities is questionable at best, and high quality decentralized activities slowly disappear due to the increased overhead. In tight knit teams, I find many of the centralized activities are unnecessary, since we deal with them as we go anyway. If we don't, someone will end up blocked for a day if not multiple days. The only exceptions being large design choices and assuring everyone works towards the same goal. If you need to sync on that every day in your average CRUD webapp dev team, I highly question how tightly knit the team is.
Ye having Jira-tickets for everything and stand ups are a form of centralization. Things are not supposed to go under the radar.
I am in a team of 5 right now where stand-up style meetings is kinda fine due to few members in the meeting, though.
I would like some readme-style changenotes.txt instead of tickets for a release. There is not way you dig down the ticket pile anyway after the sprints are done so the traceability is quite overrated. The tickets are lost like a friends scream for help in your Facebook feed when the march continue.
This resonates. I find it to be the worst when the piece of work is something substantially new in the team - like developing a new application, different from other projects the company has done.
> Even something as simple as "you make this module, you make this module, I make this module and they all communicate through this core interface" is far from trivial.
Yup. So the other day, we had to develop a completely new GUI app based on customer's initial wishlist, and we wanted to split the work along those lines - and I really agonized over that, because at the early stage none of this is stable. Especially not the "core interfaces" - which tend to stabilize somewhere close to MVP. So here I am, trying to wring out some sense out of a superposition of 20 different design ideas in my head, and I'm being asked to split work. We ended up splitting the project into big subdomains, and designing interfaces along those subdomains - becoming a poster child of Conway's law - and I hated it. But we made it work.
I could derive two lessons from that project.
One, design isn't going to be perfect up front - everything will end up being repeatedly redesigned as the project progresses, so there will be opportunities to fix bad decisions. So you may as well pick the least bad split and get the work going.
Two, actually, if you instead let a single person mull over that design in their heads for two weeks instead of forcing them to "just split work already" on a project that took a year to get to MVP, maybe this would have saved a lot of redesigns down the road.
> This is why I hate Scrum where tasks are supposed to be broken down and shared between the team members
You're not the only one who feels like that about Scrum. I feel it (the constant haggling) saps me of internal motivation to experiment and improve things.
> This is why I hate Scrum where tasks are supposed to be broken down and shared between the team members
If that doesn't work, perhaps you could talk about it in sprint retrospective? In the last team we used SCRUM, but understood that each dev had the modules/parts they knew best (for me it was user-facing parts and installer), where they'd do most of the changes and bug fixes.
> 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.
IMO if you are leaving stuff unfinished, you're probably not great and probably don't love the work. You're just chasing a high and not caring about the consequences.
Tho, there are quite a few pros in that category. Consider themselves great, believe that they have more passion then everyone else, but they are fast because other people have to finish their work and do all time consuming parts and do the hard parts.
I'd argue it may be the opposite. They are seen as pros because they don't spend the time finishing things, often despite the fact they are perfectly capable of finishing the job. They are getting 80% of the merit doing 20% of the job, while leaving others do the remaining 80% for 20% of the merit. They have more time to gather more merit, chase knowledge and ideas, experiment, which ends up opening doors.
It isn't too far from how consultants tend to function, why job hopping is lucrative, etc.. There just isn't enough incentive to stay for the dirty work as long as others, be it the managers, the employers or the coworkers, don't hold the ones leaving the mess accountable.
Now, we have assumed we are talking about great developers.
It is true that sometimes it is difficult to tell one from the other, if you are a manager and you squint your eyes a little bit. Sometimes mediocre developer masking himself as a great developer is able to create a distortion field when he never finishes anything and relies on help from others to achieve his perceived fantastic output.
No, we are not talking about that kind of person.
What I mean is a person that is truly great developer. The organizations will frequently try to make good use of this person.
One strategy is to get that developer to work on green-field projects only. He will design/write the code but once it is in prod it is going to be outsourced to another team and the star developer moves to another exciting project.
Another strategy is to offload as much non-critical work as possible. Junior developers to write to spec? Testers? "Devops" engineers (as much as I hate that term)? These are all possible way to keep the perceived star developer with only hardest problems.
Now, I don't say it is a good practice -- it is just something I have noticed over the years. Good developers have much more say in what they are going to be working on and in what capacity and this means taking interesting tasks and leaving mundane to more junior members.
> Now, we have assumed we are talking about great developers.
I think you're the one making that assumption, not "we". I'm merely talking about the guys who are seen as pros, but might just be "good" or "above average". They gain the benefit of accumulating a lot of knowledge and experience, while someone with more talent might have made better use of it.
I also believe you're assuming a little much about organizations, especially in the direction "mediocre perceived as great". Often, it is also a great developer perceived as mediocre because they don't have the skills to sell themselves well. Considering many managers don't even have a technical background, let alone a developed one, and how many environments don't allow the great developer to shine without playing office politics, I highly question the idea of "organizations will find a way".
Given what you said, despite the difference in perspective, what we are saying doesn't differ a lot. I just don't believe a developer who avoids politics and tends to hang around to do the dirty work in a large enterprise app can get very far, or at least leaves a lot up to fate (despite maybe having a ton of talent). Nor do I believe "plays office politics well" should be a requirement for someone to be seen as a great developer.
Depends on what you define as "the dirty work". Actually making it run is something the developer should be responsible for. Shepherding JIRA tickets through the different workflows, keeping builds straight, deploying to various environments and coordinating testing are also things that developers shouldn't (but are too often expected to) be wasting time with. There's a reason why lawyers hire paralegals to do things that don't require a law degree.
>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 :)
> 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?
Whether people love their job is up to the employer.
Sure you want people who have 'a passion' for the technical domain to begin with but that's not the same as loving the job, which is very much down to the atmosphere, environment, compensation, etc.
A passionate software engineer badly paid and treated like shit won't love his job...
A good manager should be good at hiring, good at choosing who works under them, choosing the team that cultivates that environment. This is why most companies look for a culture fit more than a skill fit, because it's easier to beef up a good hire's skills than it is to get someone to have healthy communication, empathy, and team working skills towards their employees.
(Technically, team working skills are optional. Not all projects need it as unusual as that sounds. If they have good communication skills, then they can work well with other teams, which is what specialists need to know as they're often a team of one or two. Eg, I'm a data scientist and most of my career I've been a team of one.)
This becomes especially true with various mental health issues. Take for instance, ADHD - I've found employers love the intensity and focus I can have sometimes (leading to extreme productivity), yet when it comes to the fact that some days I just can't focus or have an intense weekend to blow off steam and am useless on Mondays, they throw a hissy fit.
They seem to think that if I can be 200% focused some of the time, why can't I be like that all of the time?
Employers also seem to tend not to value the notion that employees have different strengths. There are some coders I know who seem to savor working hard on what I would call the "boring stuff", and there are those who can intensely work on a new problem and come up with novel approaches, but they're not going to be as good at doing assembly-line work. Both have their place, but employers want the best of both across the board, which is impractical except when you have the occasional wizard.
I used to work with a guy just like this. He slogged through crap code happily. He did his job and went home. Sadly, the first company I worked with him at fired him. "He wasn't competent, blah blah blah." He did a fine job, people just didn't like that his mentality was different than theirs. I tried to explain to them that the one person who would actually work on their horrendous software was the one they let go. Was he a superstar? No probably not, but he was good and liked his job and went home to his family at the end of the day. A lot of people don't realize a great employee comes in many forms.
This is the part that came very very quickly when I started managing people. I had people who are useless on tech but can pick up the phone and get it sorted,no matter what's the problem.On the other spectrum there were detail obsessed people that would take ages, but when I open that file I know it shows reality. Personally,I find this extremely interesting during the management meetings,where CEOs need have to listen to all of and often make decisions upon given info. I often find myself in a situation,where I can only think ' oh shit, didn't even think about it', while I'm sure other do too. To expect the same office drone functionality from everyone is insanely stupid.
Imagine that you have two employees with complementary skills (one excels where the other sucks, and vice versa) working on the same project. They will probably enjoy it a lot, because from the perspective of each, they can do the "easier" part (easier for them, than is). And the quality will probably be high, because each is working on what they know best, and what they enjoy.
However, from the average manager's perspective...
What happens if one of these two takes a vacation, and you decide to put in the sprint something that the other one sucks at? (Planning? What planning? This is Agile!)
What happens if you later decide you could save some money by moving one of them to another project, and leaving the other one to handle it all?
I’m in a different, somewhat awkward, but good position where my company champions work/life balance. The pace is slower than I expected and I have ADHD. I struggled at first especially since I want to respect other’s WLB. Sometimes I’d do a weeks worth (or more) of work in a day or two, but I try to spread that work back out so that it seems like things are more consistent. Some days I just can’t/won’t? focus on work. I think it’s because it’s not engaging? Does anyone “have it all,” ie working on interesting things at a challenging, yet decent pace? Has anyone been in a similar position? Do you have any advice?
ADHD here as well. Best thing I've found is when facing tasks of little or no interest, think about the projects/tasks that excite you/you prefer that are on your list, and think of how you'll get to those the sooner you finish the boring stuff.
Also, in terms of focusing, what's helped me is to find a single, non-lyrical, instrumental, ambient track, and just put it on loop for the whole work day. It's been easier to think/less distracting to not hear and process language or have to find the next track that I'm in the mood for, and I believe in some way it helps my mind stay focused on my thought processes related to my work through patterns the mind makes with the looping of the track.
From the employer side: The unfortunate reality is that anything resembling "heroic effort" work becomes difficult for teams to manage. It becomes impossible to plan around an employee who may or may not be able to contribute on a given day. Eventually, it becomes clear that relying on an employee to maybe or maybe not put in a couple of heroic days to catch up each week isn't as good for the team, as a whole, as someone who puts in steady and predictable work, even if the overall pace is slower.
I don't mean to detract from your personal issues. However, I would suggest that you work on finding a position that allows you to average out your productivity better over the course of a week.
This is one reason I hate Scrum. Companies that (I've worked for) have really tried to implement it don't understand that sometimes you just won't be as productive. It's always, "Well you committed to it...." They can't (or don't want to) understand those miracles they want their employees to perform comes at a cost. It means those people are less productive at times while they are exploring an idea or they are just exhausted. If they just want someone to do the minimum set each sprint, that's fine, just don't expect anyone to walk on water when you need to be saved.
Estimates are by nature probabilistic. Saying "two weeks on average" means something like: 20% it is one week, 60% it is two weeks, 20% it is three weeks. And that assumes you are already pretty good at estimating! Most people are not.
This is by sleight of hand changed into a commitment to make it in two weeks, 100% sure. Then, 20% of time, developers are blamed for not fulfilling their committments or not estimating correctly. But they did!
If the most important thing for you is getting your commitments done with as high probability as possible, have a three-week sprint, but estimate only for two. Even this will fail once in a while, but less often. And maybe let developers work on the tasks of their choice in the remaining time. Autonomy, yeah!
"Two weeks on average" literally means it could be less but just as often it could also be more. If it is always two weeks or less, then it is not two weeks on average. What if it is always exactly two weeks, not a day more or less? No, that level of precision simply does not happen in real life.
Many leaders nowadays are very insecure, and that leads to an intense desire for control. It's sick, and sad, that this has happened over the past few decades.
If the company has to advertise it during the interview, there is a higher chance than not it is bullshit. The #1 rule of marketing is advertise your weakness.
LOL... WC, they mean diversity of skin color, not diversity of beliefs, personality, etc.
They want the kind of diversity that doesn't require any thinking to consider. You look at the photo, you see a white woman, an Asian man, a Black transgender person, and a Native American non-binary... <whatever I'm supposed to define them as>.
That's the diversity they want.
But what they really want, is for the public to leave them the fuck alone. The above is just how they get it.
> 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
Both are not exclusive. Your job can be interesting and fulfilling and yet be only a job meanwhile your heart is at home with family and friends.
> People love that he's crazy enough to build spaceships and electric cars
He does not build any of that. His employees do. Volkswagen or Volvo also make electric cars without needing a grab attention CEO. For each Elon or Jobs there are a million similar guys that fail misserably. Survivor bias is a thing.
Elon Musk is not CEO of SpaceX. He is CTO and is in the trenches building the rockets. He is fully cognizant of the whole machine and he expects his engineers to be also. That way the design can be changed without regard to departmental infighting, etc. The best part is no part and always trying to get little improvements. Not something NASA can do with specs fixed in place for manufacturing in 40 different states 5 years in advance.
Of course he does not "build" the whole thing, but he has a vision that inspires people and the technical chops to lead from the front lines. And the endurance to put in productive 80-100hr work weeks for decades.
>And the endurance to put in productive 80-100hr work weeks for decades.
That's called drugs.
I am not being flippant, I think there's a whole other segment not fully touched on by this article that needs to be addressed in this subthread. More hours is not always better, and folks who can sustain this typically are using some sort of substance to do so. Whether that substance is as mild as caffeine in the 10 shots of espresso they have a day or they're railing lines of coke in between high-stress meetings, they aren't doing this off their own natural energy, and it takes a serious toll on their physical and mental health which they may not even be aware of.
I speak this from experience. I'm one of those people who was known as a "super-hacker" doing "80-100hr work weeks", and what most people didn't realize was I was downing between 20-30 shots of espresso a day. I actually ended up hospitalized at one point due to severe dehydration caused by constant mass intake of caffeine and not enough fluids. It almost caused me to have renal failure, and basically was the wake up call that represented a turning point in how I thought about work-life balance. It certainly helped advance my career and gave me a mythical reputation, but it was in no way healthy, and it ultimately didn't serve the interests of my team at that company, only the interests of the executive leadership who profited off my extra hours of work for which I was not compensated fairly.
> In the same breath he wants people who LOVE their jobs and super-productivity, but yet also understand its only a job.
Yeah, it's a sentiment that I'm not sure was meant to be taken literally rather than rhetorically. Consider who the essay is written towards -- ISVs in 2004. What about an ISV requires super-productivity? In fact, the author states this literally:
> 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.
For what it's worth, it's fascinating to look at this essay with 2020 lenses on. I have two observations:
1) The traditional ISV, while not dead, has at a lot of its traditional role usurped & cannibalized by players higher up the value chain. This somewhat relates to my next point.
2) The rise of growth and data science roles as a fusion of marketing and technology along with the enormous growth of tech as a whole (hard tech and soft tech) means that archetypical average social media literate hacker founder archetype of today is quite interested and capable of interacting with users today.
And of the three "sins" the essay points out, that's probably the most cardinal one -- for the vast majority of businesses, if you have high enough margins and an employee who's good enough at growth to add double digits to your bottom-line, are you going to whinge about their predilection to fuss about interesting projects and tools? No, you're going to raise a ton of cheap VC and let them go to town.
I used to rant a lot. At times it was perceived as an attack on someone's work, when it wasn't meant to be. Then, I'd apologize, assuming it was ok.
I was experienced, and I thought I was being paid to mentor and oversee as part of my work.
I thought that others would understand and sympathize that I ranted because I was under a lot of stress. They didn't.
They would tell others, and they would not confront me about it, which eventually resulted in a hellish working environment and semi-isolation. I believe at least one was even being unethical in their reaction to me speaking my mind, causing problems for me, probably with the best intention to wear me down, to get rid of the toxicity in their work environment "for the good of the whole".
I now try to think about what I say, even when being direct would solve a problem more quickly. Sometimes that means that when I'm on calls, others will run over me. To get over that, I also try to act and believe that the other person is more qualified. I don't do that with everyone, and it's not appropriate for speaking with young children, but it's usually good.
Aside: Consulting and mentoring share some things in common. One thing that is gold for a consultant is to be sitting in a meeting and have the client repeat your ideas, word for word, back to the execs. and claim the idea as their own. To outright 'steal' the idea and get all the credit. It means that the client actually listens to you and thinks your ideas are good [0]. The same mechanism is true with mentoring. If your mentee nearly parrots your ideas, you're gold. If they continue to do bull-headed things, you're sunk; you must how you mentor as it's clearly not working [1].
[0] This means you can raise your rates without fear, btw.
[1] To be clear, mentoring is a lot more than just this. Whole books have been written about mentoring, read them.
"[1] To be clear, mentoring is a lot more than just this. Whole books have been written about mentoring, read them." Probably a lot of bad books about mentoring have been written as well. Could you recommand the good ones?
This is why Agile's Retrospective is so awesome to have on your team. Agile doesn't work for a lot of the work I do (data scientist) but if there is anything worth grabbing and incorporating into other PM frameworks is the restrospective. If done right, it would have prevented this issue and other team community communication related issues. I highly recommend it. That and a time machine would be nice.
Had a recent data science experience where the exploratory part of the project was shoehorned into a micromanaged scrum framework. Apparently they discarded their task tracker entirely the same week I left.
Me too. I'm currently working on an Agile engineering team, due to it being a startup, so they like to group people together. (We got a data engineer, an infrastructure engineer, a consultant of all things, a firmware engineer, a hardware engineer, and a jack of all trades.)
This at first bothered me a lot, due to Agile micromanagement, but after a few months the company realized my work load is nothing like engineering, and because I have to become the domain expert on a topic to solve the challenges at hand, I end up knowing best what the next steps should be. After realizing this the company has since put me in the team lead meetings (which is excessive imo) and has personally requested that I make my own epics, issues/pbis, and do my own refinement. The only downside remaining is the company wants presentations every two weeks, but now I'm in control to slowly grow my pbis into whatever time span I want (within reason), allowing me to present as often as I want. Responsibility comes with rapport.
Getting the work done should be enough, though it only works when management has some technical oversight. If they do not, or squeeze the sand out of their hand, they lose that edge.
> 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...
Dan Pink wrote a book about this [0] in which he postulates, people are motivated by three fundamental things:
- Autonomy: The urge to be in control
- Mastery: The desire to get better at something
- Purpose: The yearning to do what we do
So, if managers took care of these three for their reportees, according to Dan Pink, they'd be inherently motivated to be doing their best work.
Note that, mastery (great hax0r) and purpose (care about users) need to align (especially true for a small company), which is what TFA may be alluding to in as many words?
It is exactly due to such thinking code becomes bloated, full of frameworks, zillion of 3rd party libraries for something that could be implemented with bearable codebase by just having a little more experienced crew that is not afraid to "just do it".
Yes, people described are hard to manage but this doesn't mean that there is something wrong with them. It means that they need competent managers that they will respect (Oh and they are there - I had a PM once and we were late on project and people were working into the night, he came to the dev. team, pulled the code and started debugging the issues, testing,... It was not his job (anyway, quite frankly, how many PMs you know that are able to fully use/test the product if you ignore the coding/debugging part). But he never had any issues with engineers ever. This action echoed for a years and he had an endless respect from anyone technical around. But people like this are not found by looking at nice graphs of jira tickets and burndown charts)
As far as I am concerned the whole post comes down to: "B people hire C people, C people hire D people,...". And if what you have are D people (not only engineering), you cant hire A people. They prove D people cant work with them. Or vice versa.
An advice:
Find company with A people. Ignore the rest. And they are there, just not advertised as aiblockchainnosqlserverlessiot (pun intended) companies.
George Bernard Shaw: “The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.”
So just be crazy and if you love to code, dont care for the money. It is not the money that makes you happy, it makes happy someone else. Find the company with the code and people that will make YOU happy. And dont crave for social respect from people who dont understand what you are doing by allowing them to drag you to their level and compete with you on "I have a better car" (or "we make loads of money") basis. That is their play and you dont need to play along.
> It is exactly due to such thinking code becomes bloated, full of frameworks, zillion of 3rd party libraries
Ironically, much of the codebase bloat I've seen in recent years has come from super-hackers who want to gain experience with all the new frameworks and services on the market.
A prime example is hiring a front-end wizard to rebuild sites in React, just because React is the new hotness. That engineer gets to put "Replaced legacy website with all-new React codebase" on their resume and pivot into the next job.
At my previous employer, one of the teams had a front-end that had become an unholy conglomeration of React and Angular, simply because the engineers were afraid their skills would fall behind if they didn't keep up with React. It was a mess.
Ironically, hiring developers who care more about getting the job done tends to choose the path of least resistance forward, which means sticking with frameworks, languages, and services that may not be the trendiest, but they get the job done.
Do you ever feel like this is a sort of paradox? You feel like you need to be up to date with the new hotness to stay relevant in the market, yet often the most productive use of your time would be to use some boring old well-trodden thing. It gives me anxiety.
There ought to be a recognized set of ethics & principles that are involved with making good software, like with any Profession. Following the hype or silver bullet solution for it's own sake should not be one of those principles.
Superstars are necessary when you just get started and you don't really care too much who's doing that magic thing that pulls off the whole ship a few hours later. However,at some point the superstars need to go and be replaced by more common people. This isn't unique to the software world.
It seems to me you have hold of a false dichotomy.
I love cooking, but I very rarely cook food just to cook and then throw it away. That I am cooking for people is part of my intrinsic motivation.
I feel the same way about software. I definitely also enjoy tinkering. But a lot of the motivation for me is in creating things for people to use. So I make sure to take jobs where the mission is one I can get behind and where I can develop empathy for the audience. I also find teamwork intrinsically motivating.
For me that makes for a pretty clear separation between intrinsically motivated coding on the job and intrinsically motivated coding at home. If I'm just fucking around with something cool to explore it, that's hobby time, because I'm not looking to help users or my team. But my days are still full of intrinsically motivated work because I'm there to fight for the users.
I think you misunderstand, or at least are taking the quotes a bit too far in either direction.
You can certainly have a passionate person who understands that at the end of the day user value is paramount even at the cost of some beauty. The author just wants to make sure you hire someone who can ship, not just passionately rewrite the codebase when a long weekend rolls around.
> 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.
However, 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.
Actually, 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.
What this article really says is, "We want the smartest, most obedient workers who will slog through whatever bullshit is required to improve quarterly profits."
Anyone 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.
Hacker 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
It'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.
I'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
> 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.
> 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.
The internet isn't the domain of nerds and spergs anymore - it's a trillion-dollar industry that the whole world depends on. We have to shed this outdated, toxic, antisocial culture if we want to move forward.
(I think diversity is going to be an important part of the transition away from nerd culture. Women and minorities tend to be more well-adjusted.)
I have noticed this, too. The hacker and creativity bashing started in open source projects, which were taken over by corporations. Now that a sufficient number of "open" source developers are in the pockets of said entities, mailing lists are censored, conference speakers are censored and dissidents are silenced.
HN is one of the rare places where free thinking is still allowed (probably thanks to pg), but the new ideology is spreading fast.
On the bright side, this may be a good time to found a startup.
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.
Things 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.
> 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.
Eric 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
> 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.
107 comments
[ 3.5 ms ] story [ 155 ms ] thread> 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.
You don't think your attitude here is condescending and self-aggrandizing?
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.
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.
None of that is particularly hard though. Quaternions and lie algebras sound esoteric but are simple to work with, C++ is standard basically anywhere that cares about performance including a large part of Google, and finding suitable algorithms and implementing them bug free is the absolute minimum of what is expected of people.
Now, the work people do at Google isn't that hard either, but it isn't like your average engineer could easily do the job. At Google it is expected that a typical mid level engineer can design and build systems to handle millions of QPS, be fault tolerant to prevent errors from propagating and bringing all of Google at once, know how to write distributed scripts to do operations on user data like migrating it without bringing down the service, know how to debug errors in distributed systems, track it between servers and try to find its origin, create useful health metrics for servers so you can see what is going on since you have thousands of them at once and you can't look at them individually, etc. In practice the end result is that they just copy data between servers, but copying data at reasonable cost to the right places on live servers when you have many thousands of servers all over the world is hard.
And that is just the typical boring backend job, a significant part of Google is only low level libraries, algorithmic performance, machine learning, databases, compiler optimizations for C++, video encodings, etc etc. I've worked on both at Google and I wouldn't say that one is harder than the other, however working on algorithms and libraries is more fun and less stressful than backend work so I prefer it. Also the team working at the more "fun" stuff wasn't that much better either, I don't think the people working at backend would have a terribly difficult time doing those jobs either. After all Google does interview and hire everyone as if they would work on interesting technical stuff, so everyone knows at least the basics of maths and algorithms.
> 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.
You talked about the typical FAANG engineer though. They aren't geniuses but they are still pretty smart. You shouldn't underestimate them.
That was perhaps true in 1990. Currently, most people just call a library that does what they want and don't know or care what kind of an algorithm is implemented behind the scenes - let alone implement the algorithm themselves.
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.
As per the rule against this, somethings in 12 years truly never change.
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.
Suffers implies something destructive and I would hardly call working with ordinary men being destructive even though obviously the outcome might be better if all coders are great, even thought that is hardly realistic for most setups, especially bigger.
It is not just that the difference in skills causes frustration but also that frustrations over long period of time also influence the developer.
For example, if you have observed, over long period of time, that people are generally slow and unreliable, that your products tend to work better, that you can think up better designs without bothering to talk to your team,
... wouldn't that influence your character and the way you typically interface with other developers?
It is not that he/she became a great developer suddenly. This must have taken years.
I just can't seem to share the plan in my head in a good way. Probably becouse it is very fuzzy until it is done.
This is why I hate Scrum where tasks are supposed to be broken down and shared between the team members and the last person touching the issue has to ensure everything works together ...
NB: I know this is not specific to Scrum, and Scrum does not enforce this. Yet I can't help but feel there is some sort of correlation.
That's why work in small, tightly knit teams, on the same feature. That's why refinings, plannings, standups, etc.
In practice, I feel the opposite tends to happen too. Not only does the quantity increase, but the quality of these centralized activities is questionable at best, and high quality decentralized activities slowly disappear due to the increased overhead. In tight knit teams, I find many of the centralized activities are unnecessary, since we deal with them as we go anyway. If we don't, someone will end up blocked for a day if not multiple days. The only exceptions being large design choices and assuring everyone works towards the same goal. If you need to sync on that every day in your average CRUD webapp dev team, I highly question how tightly knit the team is.
I am in a team of 5 right now where stand-up style meetings is kinda fine due to few members in the meeting, though.
I would like some readme-style changenotes.txt instead of tickets for a release. There is not way you dig down the ticket pile anyway after the sprints are done so the traceability is quite overrated. The tickets are lost like a friends scream for help in your Facebook feed when the march continue.
> Even something as simple as "you make this module, you make this module, I make this module and they all communicate through this core interface" is far from trivial.
Yup. So the other day, we had to develop a completely new GUI app based on customer's initial wishlist, and we wanted to split the work along those lines - and I really agonized over that, because at the early stage none of this is stable. Especially not the "core interfaces" - which tend to stabilize somewhere close to MVP. So here I am, trying to wring out some sense out of a superposition of 20 different design ideas in my head, and I'm being asked to split work. We ended up splitting the project into big subdomains, and designing interfaces along those subdomains - becoming a poster child of Conway's law - and I hated it. But we made it work.
I could derive two lessons from that project.
One, design isn't going to be perfect up front - everything will end up being repeatedly redesigned as the project progresses, so there will be opportunities to fix bad decisions. So you may as well pick the least bad split and get the work going.
Two, actually, if you instead let a single person mull over that design in their heads for two weeks instead of forcing them to "just split work already" on a project that took a year to get to MVP, maybe this would have saved a lot of redesigns down the road.
You're not the only one who feels like that about Scrum. I feel it (the constant haggling) saps me of internal motivation to experiment and improve things.
If that doesn't work, perhaps you could talk about it in sprint retrospective? In the last team we used SCRUM, but understood that each dev had the modules/parts they knew best (for me it was user-facing parts and installer), where they'd do most of the changes and bug fixes.
I've only seen one case of some one who IMHO was not just suited as a developer and this is with support and a proper PIP process.
IMO if you are leaving stuff unfinished, you're probably not great and probably don't love the work. You're just chasing a high and not caring about the consequences.
It isn't too far from how consultants tend to function, why job hopping is lucrative, etc.. There just isn't enough incentive to stay for the dirty work as long as others, be it the managers, the employers or the coworkers, don't hold the ones leaving the mess accountable.
It is true that sometimes it is difficult to tell one from the other, if you are a manager and you squint your eyes a little bit. Sometimes mediocre developer masking himself as a great developer is able to create a distortion field when he never finishes anything and relies on help from others to achieve his perceived fantastic output.
No, we are not talking about that kind of person.
What I mean is a person that is truly great developer. The organizations will frequently try to make good use of this person.
One strategy is to get that developer to work on green-field projects only. He will design/write the code but once it is in prod it is going to be outsourced to another team and the star developer moves to another exciting project.
Another strategy is to offload as much non-critical work as possible. Junior developers to write to spec? Testers? "Devops" engineers (as much as I hate that term)? These are all possible way to keep the perceived star developer with only hardest problems.
Now, I don't say it is a good practice -- it is just something I have noticed over the years. Good developers have much more say in what they are going to be working on and in what capacity and this means taking interesting tasks and leaving mundane to more junior members.
I think you're the one making that assumption, not "we". I'm merely talking about the guys who are seen as pros, but might just be "good" or "above average". They gain the benefit of accumulating a lot of knowledge and experience, while someone with more talent might have made better use of it.
I also believe you're assuming a little much about organizations, especially in the direction "mediocre perceived as great". Often, it is also a great developer perceived as mediocre because they don't have the skills to sell themselves well. Considering many managers don't even have a technical background, let alone a developed one, and how many environments don't allow the great developer to shine without playing office politics, I highly question the idea of "organizations will find a way".
Given what you said, despite the difference in perspective, what we are saying doesn't differ a lot. I just don't believe a developer who avoids politics and tends to hang around to do the dirty work in a large enterprise app can get very far, or at least leaves a lot up to fate (despite maybe having a ton of talent). Nor do I believe "plays office politics well" should be a requirement for someone to be seen as a great developer.
Depends on what you define as "the dirty work". Actually making it run is something the developer should be responsible for. Shepherding JIRA tickets through the different workflows, keeping builds straight, deploying to various environments and coordinating testing are also things that developers shouldn't (but are too often expected to) be wasting time with. There's a reason why lawyers hire paralegals to do things that don't require a law degree.
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 :)
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?
Sure you want people who have 'a passion' for the technical domain to begin with but that's not the same as loving the job, which is very much down to the atmosphere, environment, compensation, etc.
A passionate software engineer badly paid and treated like shit won't love his job...
You do need an employer who cares about their employees, treats them fairly, supports and encourages a great atmosphere etc.
You absolutely need enthusiastic, motivated and pleasant employees too though. Employees create the atmosphere as much as the employer.
Now you could flip this and say a good employee should be good at hiring, but IMHO that’s kinda just the same thing.
(Technically, team working skills are optional. Not all projects need it as unusual as that sounds. If they have good communication skills, then they can work well with other teams, which is what specialists need to know as they're often a team of one or two. Eg, I'm a data scientist and most of my career I've been a team of one.)
They seem to think that if I can be 200% focused some of the time, why can't I be like that all of the time?
For some it's all take take take.
However, from the average manager's perspective...
What happens if one of these two takes a vacation, and you decide to put in the sprint something that the other one sucks at? (Planning? What planning? This is Agile!)
What happens if you later decide you could save some money by moving one of them to another project, and leaving the other one to handle it all?
Also, what if one of them asks for a raise?
Also, in terms of focusing, what's helped me is to find a single, non-lyrical, instrumental, ambient track, and just put it on loop for the whole work day. It's been easier to think/less distracting to not hear and process language or have to find the next track that I'm in the mood for, and I believe in some way it helps my mind stay focused on my thought processes related to my work through patterns the mind makes with the looping of the track.
I don't mean to detract from your personal issues. However, I would suggest that you work on finding a position that allows you to average out your productivity better over the course of a week.
This is by sleight of hand changed into a commitment to make it in two weeks, 100% sure. Then, 20% of time, developers are blamed for not fulfilling their committments or not estimating correctly. But they did!
If the most important thing for you is getting your commitments done with as high probability as possible, have a three-week sprint, but estimate only for two. Even this will fail once in a while, but less often. And maybe let developers work on the tasks of their choice in the remaining time. Autonomy, yeah!
"Two weeks on average" literally means it could be less but just as often it could also be more. If it is always two weeks or less, then it is not two weeks on average. What if it is always exactly two weeks, not a day more or less? No, that level of precision simply does not happen in real life.
They want the kind of diversity that doesn't require any thinking to consider. You look at the photo, you see a white woman, an Asian man, a Black transgender person, and a Native American non-binary... <whatever I'm supposed to define them as>.
That's the diversity they want.
But what they really want, is for the public to leave them the fuck alone. The above is just how they get it.
Both are not exclusive. Your job can be interesting and fulfilling and yet be only a job meanwhile your heart is at home with family and friends.
> People love that he's crazy enough to build spaceships and electric cars
He does not build any of that. His employees do. Volkswagen or Volvo also make electric cars without needing a grab attention CEO. For each Elon or Jobs there are a million similar guys that fail misserably. Survivor bias is a thing.
Of course he does not "build" the whole thing, but he has a vision that inspires people and the technical chops to lead from the front lines. And the endurance to put in productive 80-100hr work weeks for decades.
That's called drugs.
I am not being flippant, I think there's a whole other segment not fully touched on by this article that needs to be addressed in this subthread. More hours is not always better, and folks who can sustain this typically are using some sort of substance to do so. Whether that substance is as mild as caffeine in the 10 shots of espresso they have a day or they're railing lines of coke in between high-stress meetings, they aren't doing this off their own natural energy, and it takes a serious toll on their physical and mental health which they may not even be aware of.
I speak this from experience. I'm one of those people who was known as a "super-hacker" doing "80-100hr work weeks", and what most people didn't realize was I was downing between 20-30 shots of espresso a day. I actually ended up hospitalized at one point due to severe dehydration caused by constant mass intake of caffeine and not enough fluids. It almost caused me to have renal failure, and basically was the wake up call that represented a turning point in how I thought about work-life balance. It certainly helped advance my career and gave me a mythical reputation, but it was in no way healthy, and it ultimately didn't serve the interests of my team at that company, only the interests of the executive leadership who profited off my extra hours of work for which I was not compensated fairly.
Yeah, it's a sentiment that I'm not sure was meant to be taken literally rather than rhetorically. Consider who the essay is written towards -- ISVs in 2004. What about an ISV requires super-productivity? In fact, the author states this literally:
> 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.
For what it's worth, it's fascinating to look at this essay with 2020 lenses on. I have two observations:
1) The traditional ISV, while not dead, has at a lot of its traditional role usurped & cannibalized by players higher up the value chain. This somewhat relates to my next point.
2) The rise of growth and data science roles as a fusion of marketing and technology along with the enormous growth of tech as a whole (hard tech and soft tech) means that archetypical average social media literate hacker founder archetype of today is quite interested and capable of interacting with users today.
And of the three "sins" the essay points out, that's probably the most cardinal one -- for the vast majority of businesses, if you have high enough margins and an employee who's good enough at growth to add double digits to your bottom-line, are you going to whinge about their predilection to fuss about interesting projects and tools? No, you're going to raise a ton of cheap VC and let them go to town.
I used to rant a lot. At times it was perceived as an attack on someone's work, when it wasn't meant to be. Then, I'd apologize, assuming it was ok.
I was experienced, and I thought I was being paid to mentor and oversee as part of my work.
I thought that others would understand and sympathize that I ranted because I was under a lot of stress. They didn't.
They would tell others, and they would not confront me about it, which eventually resulted in a hellish working environment and semi-isolation. I believe at least one was even being unethical in their reaction to me speaking my mind, causing problems for me, probably with the best intention to wear me down, to get rid of the toxicity in their work environment "for the good of the whole".
I now try to think about what I say, even when being direct would solve a problem more quickly. Sometimes that means that when I'm on calls, others will run over me. To get over that, I also try to act and believe that the other person is more qualified. I don't do that with everyone, and it's not appropriate for speaking with young children, but it's usually good.
[0] This means you can raise your rates without fear, btw.
[1] To be clear, mentoring is a lot more than just this. Whole books have been written about mentoring, read them.
This at first bothered me a lot, due to Agile micromanagement, but after a few months the company realized my work load is nothing like engineering, and because I have to become the domain expert on a topic to solve the challenges at hand, I end up knowing best what the next steps should be. After realizing this the company has since put me in the team lead meetings (which is excessive imo) and has personally requested that I make my own epics, issues/pbis, and do my own refinement. The only downside remaining is the company wants presentations every two weeks, but now I'm in control to slowly grow my pbis into whatever time span I want (within reason), allowing me to present as often as I want. Responsibility comes with rapport.
Dan Pink wrote a book about this [0] in which he postulates, people are motivated by three fundamental things:
- Autonomy: The urge to be in control
- Mastery: The desire to get better at something
- Purpose: The yearning to do what we do
So, if managers took care of these three for their reportees, according to Dan Pink, they'd be inherently motivated to be doing their best work.
Note that, mastery (great hax0r) and purpose (care about users) need to align (especially true for a small company), which is what TFA may be alluding to in as many words?
[0] https://www.youtube-nocookie.com/embed/KgGhSOAtAyQ
It is exactly due to such thinking code becomes bloated, full of frameworks, zillion of 3rd party libraries for something that could be implemented with bearable codebase by just having a little more experienced crew that is not afraid to "just do it".
Yes, people described are hard to manage but this doesn't mean that there is something wrong with them. It means that they need competent managers that they will respect (Oh and they are there - I had a PM once and we were late on project and people were working into the night, he came to the dev. team, pulled the code and started debugging the issues, testing,... It was not his job (anyway, quite frankly, how many PMs you know that are able to fully use/test the product if you ignore the coding/debugging part). But he never had any issues with engineers ever. This action echoed for a years and he had an endless respect from anyone technical around. But people like this are not found by looking at nice graphs of jira tickets and burndown charts)
As far as I am concerned the whole post comes down to: "B people hire C people, C people hire D people,...". And if what you have are D people (not only engineering), you cant hire A people. They prove D people cant work with them. Or vice versa.
An advice:
Find company with A people. Ignore the rest. And they are there, just not advertised as aiblockchainnosqlserverlessiot (pun intended) companies.
George Bernard Shaw: “The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.”
So just be crazy and if you love to code, dont care for the money. It is not the money that makes you happy, it makes happy someone else. Find the company with the code and people that will make YOU happy. And dont crave for social respect from people who dont understand what you are doing by allowing them to drag you to their level and compete with you on "I have a better car" (or "we make loads of money") basis. That is their play and you dont need to play along.
Ironically, much of the codebase bloat I've seen in recent years has come from super-hackers who want to gain experience with all the new frameworks and services on the market.
A prime example is hiring a front-end wizard to rebuild sites in React, just because React is the new hotness. That engineer gets to put "Replaced legacy website with all-new React codebase" on their resume and pivot into the next job.
At my previous employer, one of the teams had a front-end that had become an unholy conglomeration of React and Angular, simply because the engineers were afraid their skills would fall behind if they didn't keep up with React. It was a mess.
Ironically, hiring developers who care more about getting the job done tends to choose the path of least resistance forward, which means sticking with frameworks, languages, and services that may not be the trendiest, but they get the job done.
I'd say they aren't really super-hackers; no true Scotsman and all that.
I love cooking, but I very rarely cook food just to cook and then throw it away. That I am cooking for people is part of my intrinsic motivation.
I feel the same way about software. I definitely also enjoy tinkering. But a lot of the motivation for me is in creating things for people to use. So I make sure to take jobs where the mission is one I can get behind and where I can develop empathy for the audience. I also find teamwork intrinsically motivating.
For me that makes for a pretty clear separation between intrinsically motivated coding on the job and intrinsically motivated coding at home. If I'm just fucking around with something cool to explore it, that's hobby time, because I'm not looking to help users or my team. But my days are still full of intrinsically motivated work because I'm there to fight for the users.
You can certainly have a passionate person who understands that at the end of the day user value is paramount even at the cost of some beauty. The author just wants to make sure you hire someone who can ship, not just passionately rewrite the codebase when a long weekend rolls around.
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.
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.
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.
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.
The internet isn't the domain of nerds and spergs anymore - it's a trillion-dollar industry that the whole world depends on. We have to shed this outdated, toxic, antisocial culture if we want to move forward.
(I think diversity is going to be an important part of the transition away from nerd culture. Women and minorities tend to be more well-adjusted.)
HN is one of the rare places where free thinking is still allowed (probably thanks to pg), but the new ideology is spreading fast.
On the bright side, this may be a good time to found a startup.
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.
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.
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.
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
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.