We once had a Cisco phone setup that didn’t really have a test-system, and I was tasked with automating phone creation/updates for around 5000 employees. The documentation for the API wasn’t very good at explaining what each setting was, and I got one of them wrong. It wasn’t wrong for those of us whom I tested it on, but it was wrong for quite a lot of people. As a result a few hundred people in the city of Skanderborg where I work, had their phones deleted. Which is sort of a big issue. Because it was weakly testet we rolled it out mostly to departments we knew, but one of those was IT, and suddenly the phone support for 5000ish employees was out.
The head of IT wasn’t happy when I told him, but his reaction was perfect. I was pretty new and I think he could tell that I was down about the situation. He told me that we all make mistakes, but it’s the people who own up to them that are useful. It’s some of the best advice I’ve ever gotten, and today I can’t even imagine working in a culture where mistakes aren’t allowed.
I don’t think you should test your phone-automation software in production. You really shouldn’t, unless it’s the only option you have and the reward far outweigh the risks. Because after my mistake, I got the settings right, and the automation saved thousands of man hours.
I often wonder whether one of the factors that decides whether boss is understanding or not is if the boss himself was once in the trenches. I worked as manager for a decade and the first thing I always did when such things happened was to try find the solve the problem. No use crying over spilt milk. As a senior developer now I am definitely more empathetic certain types of mistakes made by juniors.
When I started, I was an intern. I was lucky to live in a day where not every metrics were used to rate someone's productivity. So employees had time for me. Time to help me learn, and figure out stuff.
As I wasn't paid, I had low pressure to deliver good things. That said I was trying really hard to bring a net positive.
I miss the days where having interns was a common thing. We'd give them the repetitive boring jobs but they'd also get real experience and see _how_ things were done. Later they'd be trusted to do just about anything.
Now it's all 'senior'. Every job is looking for a heavy-hitter rockstar superman. Even if it's wrapped into this joly 'hey we're cool and kinda awesome too, woowee us!' - they're still wanting to find senior mad-scientists.
I contract myself out to large/small businesses, all sorts of industries, big pay jobs. Number of interns: 0.
The net result is I see plenty of 'senior engineers' hired who I wouldn't call senior. They've got 5 years experience, 2 of them were writing tests, and they're 'senior'?
Do the future a favour, get a few interns. They'll keep you young!
Pretty much agree, but not sure Internships are the best way to do it. Expecting people to work for no pay means you only get those that can afford to work for no pay.
I remember an article on HN from few years ago, about the German apprentice system. Paid work, coupled with college education.
Writing good tests is not easy. It's an important skill that not everybody has. In some industries, where you write safety critical software, you actually need more experience before you are allowed to work unsupervised as a tester. The testers I've worked with also had a say in the design of the software and were allowed to veto architectural decisions for being too hard to test.
So please don't look down on people writing tests. Quality assurance is what makes software suck less.
To your point, I saw a set of job listings for a start-up where the most junior engineer was a "Lead Engineer". Keep in mind that the requirements included basic knowledge of programming languages and web design, so this seemed to actually be their entry level job.
I wanted to apply just to ask why it was so important to throw "Lead" in front of there. What happened to all of the "Junior Engineer"s? If nothing else, that title is a lot more honest!
Part of the wave of level inflation; and if companies use titles instead of comp to hire folks who may consider title more valuable than comp (there are many). Consider: you’re a manager that desperately wants to hire a candidate but can’t match their other offers comp. one easy way to lure the candidate is with other things, including inflated titles. Naturally, you shouldn’t put any meaning into these titles. They tend to mean vastly diff things across organizations.
> I miss the days where having interns was a common thing.
Has this really changed as much as you think? It is well-known that the tech giants (Amazon, Google, Facebook, etc) hire a number of interns - from what I've seen, I'd guess it is at least in the high thousands between those three. Many more startup-y companies seem to do so as well - the June HN hiring thread shows 27 hits for "intern", and unicorns also are known for hiring a large number. Where I work we increase in size by ~10% every summer when interns arrive, and my last job was even more.
It's also no longer the case that tech internships are frequently unpaid, so they're much more accessible. At the top internships, they're making significantly more than average full-time devs. This seems to indicate plenty of competition.
I think it's due to companies being understaffed. I've talked with people at a couple of tech companies, both startups and large corporations, why they don't hire more interns.
The answer was the same: We don't have enough resources to train them. Everyone's overworked and behind schedule, and can't even set aside a measly 1 hour a week to show interns the ropes.
And some feel that it's just a chore, like interviewing candidates.
It seems like companies these days want direct replacements or shoe-in workers, that can go from orientation / setting up equipment on day 0, to producing code on day 1.
When I started out, I had 6 months of training and getting familiar with codebase plus tech.
This is obviously not the case everywhere, but seems like a trend from my own experience.
Getting a job for life in the private sector seems like a pipe dream. From my perspective it seems the relationship between employer and employee has become only about self-interest, making the long-term investment in employees is risky when they may just take the training and leave for better opportunities and security. I didn't think this was entirely the case until my dad was made redundant from the only job he had for 35 years of his life. I keep forgetting how much of an impact 2007/2008 really did have on the economy and the psyche of the working population, coming into it now seems like normal working environment for young adults.
Most people are senior in order to support their pay. They were hired on by another company cause they really needed someone and could afford them.
That company's HR department said "there's no way I'm paying a junior web developer that, that's not what glassdoor.com says they should make". The hiring manager knew they'd be an asset worth "senior" status, because they knew they had to move quick and the candidate already had a week's worth of in-person interviews scheduled elsewhere. Thus, the web developer is now a "senior web developer".
It's on their email signature, so you know it's legit.
I think this is a natural run of things. Junior people are in India, and always stay junior in the sense: their oursourcer companies never get hired to do critical stuff, or that's just a mistake.
Senior people are those who started off writing open source as a hobby, built up a great github profile, got hired into a small and poorly funded startup to do a job which a senior would do (because that startup didn't have a better alternative), broke some things, built experience, and proceeded to work in normal places as a senior.
This is how i see it should happen in a perfect world. It's just the international division of labor: if you have a low budget to pay someone do low-impact coding you will have a better bang for the buck spending it in India, not hiring a junior in the Valley. When you need to do serious stuff, you need local people of a senior level.
There is no place left for an American junior, as well as for Indian senior, too (their companies operate, or at least should in the perfect world operate, in outstaffing mode so they don't really need architects, only job for a senior developer may be doing interviews, probably).
I always found this interesting about my junior developers.
When I teach a new concept, I can instinctively tell who will listen, apply it and be able to move on to tougher concepts while understanding that some of them will be hard headed and will have to be beaten into submission.
One day, I got fed up with one of them (he kept trying to parse JSON by splitting the string in Java), and told him I would honestly use GSON to parse it because I'm lazy. I could see it click in his mind, as he realized writing a small JSON schema in Java was easier than his convoluted 12-step if statement chain (he was performing the string splitting based on the URL he was doing REST requests against). Now I call it the 'laziness as teaching' tool.
1) Admit you're doing it because you're lazy
2) List the set of items that need to be done in the new lazy approach
3) Contrast it against the previous method
4) Watch it click as they realize their way is so much extra work.
Well, part of the problem is the intrinsic desire for the person to prove themselves to you by doing a great job. Sometimes it’s more useful to let them try for a bit, before showing how your solution might be better.
Letting juniors experiment the best design by failing is sometimes an effective strategy. And if they do succeed or produce a better solution, awesome. That is a lesson that you can learn from (technology changes very quickly).
Why do I use JSON? No, it's probably not the best tool for the job. But it's quite adequate, and I don't have to write my own parser. That every other language on the planet can now also interface with my API with minimal fuss is just an added bonus. :)
> he kept trying to parse JSON by splitting the string in Java
I truly do not understand the mindset that, when presented with a simple means of doing a complex task, will do it manually[0].
If a junior dev did that in front of me I'd seriously start doubting their capability for the job.
[0] The one single allowable exception is doing a crappy task manually the first time so you know how, before switching to a tool. My first parser I ever wrote I did manually rather than with flex/bison so I knew how to. After that it was tooling all the way.
I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief.
EDIT: I misread and thought he was a supporter of the regime, but the source is not a villain as I thought before. In any case, I think there is some wisdom in this quote.
Question is, what do you do with the juniors who never get it? Those for whom mistakes/inefficiency aren’t just “mistakes” but are their normal mode of operation? I’ve had juniors who I did this “well, I’d be lazy and just use a library/script” routine on, and they essentially ignored me and went straight back to what they were doing. Either they were afraid of admitting they’d gotten it ‘wrong’ and were unwilling to abandon that method they’d personally thought of, or they genuinely didn’t even agree that they were struggling in the first place - in some weird way they must have ENJOYED struggling and thought it meant they were learning or solving something hard.
The idea that using a library to accomplish something essential but mundane is "lazy" is weird. If your job is to transport pallets of widgets from one place to another and you elect to use a truck that someone else has manufactured rather than building your own, that's expected behavior.
This article reminds me of the analogy made in the anti-procrastination book the Now Habit [0] called "raising the board". When you or your company culture tie the stakes of making a mistake into some kind of validation of your worth as an employee or as a human being, it's like taking the simple task of walking across a board on the ground, and transforming it into walking across a board 100 feet in the air with the building on your end also on fire. Obviously, it creates additional stress and anxiety that makes it significantly harder for you to get started, iterate, and bounce back from failures -- even though the actual difficulty of individual tasks hasn't changed.
If this article's point appeals to anyone and they are looking for a modern researcher on the topic, I'll gently push them in the direction of Brene Brown's work on embracing vulnerability as a driver of personal growth: https://www.ted.com/talks/brene_brown_on_vulnerability?langu...
“You’re right. That’s okay. I’m here to help you figure out how to make it better.”
No. It's just not realistic. In today's company your manager will say that to you then slate you for the "bottom 10%" category and you'll receive decreasingly subtle signs that they want you to leave. Companies don't actually train, reinforce or develop employees anymore, at least not for more than a few weeks.
(Author here) That's actually a real conversation that happened over a year ago, and I ended up becoming technical lead on the project later! No signs of firing yet. Not all companies are too lazy to care about their employees. It is, realistically, the smartest financial choice to invest in growing the people you hire instead of just throwing them away and hiring new ones every quarter.
In today's company your manager will say that to you then slate you for the "bottom 10%" category and you'll receive decreasingly subtle signs that they want you to leave.
This is usually a sign you're working for a manager who's never had a good manager themselves, so they've never learned how to manage a team well.
It's true that a typical workplace will do this. It's also a crappy way to run things or treat people, which will be detrimental to those that do it in the long run.
I'm mildly offended by the casual use of the word "wizard" here - I don't believe that they actually exist.
I'm not American, but I tend to think that assuming the existence of wizards or geniuses is fundamentally Unamerican.
If anything, the concept of wizard etc. is pretty much in the eyes of the beholder. In this sense, we're digging ourselves deeper by needlessly magnifying and exaggerating one's "ability". Different people produce different outcomes, but the difference in their output is mostly accidental.
Humans are not comfortable with explaining everything as luck. But I think many things are actually explained by luck, and we should take it easy.
Vast, persistent differences in competence across programmers are definitely real. Working in a homogeneous team for a long time can obscure it, sure. But if you can't think of any colleagues drastically better than you are, then either your work is on par with the giants of our field, or it's time to find some different colleagues who can challenge you and help you to continue growing. (Or you're making a conscious decision to rest, which is fine, but not while denying the possibility of alternatives).
I don't think absence of mistakes is what makes these people great, though, more like the difficulty of the problems they're able to solve, the effectiveness with which they can manipulate and discuss ideas, and the fitness-for-purpose of their solutions.
I don't love the wizard metaphor either. Mainly because I don't like buying into the ego behind it. Kent Beck had a great talk (happiness at work, I believe) where he talked about the downsides of seeking ego validation through one's work.
I'd much rather treat these as pretty common sense, learnable lessons that are accessible to anyone.
As for one's output being mostly based on luck? I must disagree with you. I find those that care about what they're doing, and why they're doing it - consistently outperform those that aren't invested in what they're doing. And I think there are those that are more suited to our line of work than others (whether due to how their minds work, or otherwise).
Luck does however play a part in the chances we get to learn and to prove ourselves, especially if you're not born into a relative position of advantage. But to sum up one's contributions, skills, talents and effort to be just luck? That seems dismissive.
> I'm mildly offended by the casual use of the word "wizard" here - I don't believe that they actually exist.
Neither do unicorns or nasal demons. It's a colloquialism and you're taking it too literally. Then there's Clarke's First Law:
"Any sufficiently advanced technology is indistinguishable from magic"
> Different people produce different outcomes, but the difference in their output is mostly accidental.
This is completely and obviously untrue. Do you believe a tightrope walker just gets lucky all the time, or that any ordinary person could do the job just the same?
> Humans are not comfortable with explaining everything as luck. But I think many things are actually explained by luck, and we should take it easy.
Actually, a lot of unsuccessful people are perfectly comfortable explaining everything away with "luck". That's how they stay unsuccessful.
Programming isn't about "luck", it is about skill. You don't get a working program "by chance". Sure, you might land that job because you're lucky. You're lucky to live in a time and place that offers you modern computers. You're lucky to have a brain that affords you to learn this skill - but you don't become a programmer just by accident.
The author is using wizards as synonymous with geniuses plus some geeky RPG terms used as metaphors. She's not implying that wizards exist, rather, that her peers seemed to be performing magic compared to her skill level at the time.
I remember using the arrow keys in the terminal to navigate my history and edit commands. The first time I sat next to somebody who knew ^R, ^A, ^E, alt-f and more readline shortcuts, I felt they were a wizard.
Watch NHL hockey and count the number of mistakes players make. And they're being paid millions to do it.
Mistakes are just... Ugh. They're so normal and so important to growth that it frustrates me that they're ever perceived as a bad thing. If you're not making mistakes then you're not making those risky plays that turn into goals 7% of the time. You'll end up being a consistent, mediocre player.
I totally agree with the message underlying what you're saying but specifically in sports, I think a really interesting thing is that this only applies once you're at the very top level.
Below that, I think being as boring and consistent as possible is actually the key to being an above-average player, paradoxically. It's the same percentages at work - for averagely talented players, those risky plays don't succeed 7% of the time, more like 1% (for argument's sake, obviously made up numbers) so it's actually a better strategy to do the boring thing which might succeed say 5% of the time, consistently. Still low, but better on average than most people who do try the risky, extremely unlikely to work, plays more frequently.
Attacking players are measured by how many successful things they do. Scoring 2 goals and making 50 mistakes in better than scoring 1 goal and making no mistakes.
Defensive players are measured by how few mistakes they make. Period.
He was a college professor in Grand Rapids who if I remember started the company with a student. He impressed me because he had company culture figured out early and that gave Atomic Object a distinct advantage.
They've expanded to several locations in the state and have an extremely low turnover compared to other shops. He understands that not every programmer wants to go into management and they're encouraged to become mentors and help staff stay current. He also indicated that he was starting to become an angel investor. I found him to be quite an interesting guy.
This is such an important lesson. Also, you're worth more than "what you've done lately". I personally struggle with tying my self worth to my productivity.
From my hometown! Atomic Object has their heads screwed on straight, and recognizes the importance of reality and nuance when it comes to software development. Other firms I've dealt with are ... less enlightened.
You'd be surprised how many companies have a sink or swim mentality. Many people are just in it for themselves and don't really want to help others, or they just aren't cognizant enough of their surroundings to bother to offer aid. If those that don't want to help need to, it's often full of belittlement.
I've been in situations like this, and let me tell you, it sucks. I feel like I could've grown a lot faster if someone just cared enough to work with me on some things I had difficulty with.
Makes me have a greater appreciation for culture and communication.
[+] [-] moksly|6 years ago|reply
The head of IT wasn’t happy when I told him, but his reaction was perfect. I was pretty new and I think he could tell that I was down about the situation. He told me that we all make mistakes, but it’s the people who own up to them that are useful. It’s some of the best advice I’ve ever gotten, and today I can’t even imagine working in a culture where mistakes aren’t allowed.
I don’t think you should test your phone-automation software in production. You really shouldn’t, unless it’s the only option you have and the reward far outweigh the risks. Because after my mistake, I got the settings right, and the automation saved thousands of man hours.
[+] [-] mmsimanga|6 years ago|reply
[+] [-] keyle|6 years ago|reply
As I wasn't paid, I had low pressure to deliver good things. That said I was trying really hard to bring a net positive.
I miss the days where having interns was a common thing. We'd give them the repetitive boring jobs but they'd also get real experience and see _how_ things were done. Later they'd be trusted to do just about anything.
Now it's all 'senior'. Every job is looking for a heavy-hitter rockstar superman. Even if it's wrapped into this joly 'hey we're cool and kinda awesome too, woowee us!' - they're still wanting to find senior mad-scientists.
I contract myself out to large/small businesses, all sorts of industries, big pay jobs. Number of interns: 0.
The net result is I see plenty of 'senior engineers' hired who I wouldn't call senior. They've got 5 years experience, 2 of them were writing tests, and they're 'senior'?
Do the future a favour, get a few interns. They'll keep you young!
[+] [-] treerock|6 years ago|reply
Pretty much agree, but not sure Internships are the best way to do it. Expecting people to work for no pay means you only get those that can afford to work for no pay.
I remember an article on HN from few years ago, about the German apprentice system. Paid work, coupled with college education.
https://tobi.lutke.com/blogs/news/11280301-the-apprentice-pr...
https://news.ycombinator.com/item?id=5314268
[+] [-] adrianN|6 years ago|reply
So please don't look down on people writing tests. Quality assurance is what makes software suck less.
[+] [-] civicsquid|6 years ago|reply
I wanted to apply just to ask why it was so important to throw "Lead" in front of there. What happened to all of the "Junior Engineer"s? If nothing else, that title is a lot more honest!
[+] [-] pm90|6 years ago|reply
[+] [-] thedufer|6 years ago|reply
Has this really changed as much as you think? It is well-known that the tech giants (Amazon, Google, Facebook, etc) hire a number of interns - from what I've seen, I'd guess it is at least in the high thousands between those three. Many more startup-y companies seem to do so as well - the June HN hiring thread shows 27 hits for "intern", and unicorns also are known for hiring a large number. Where I work we increase in size by ~10% every summer when interns arrive, and my last job was even more.
It's also no longer the case that tech internships are frequently unpaid, so they're much more accessible. At the top internships, they're making significantly more than average full-time devs. This seems to indicate plenty of competition.
[+] [-] TrackerFF|6 years ago|reply
The answer was the same: We don't have enough resources to train them. Everyone's overworked and behind schedule, and can't even set aside a measly 1 hour a week to show interns the ropes.
And some feel that it's just a chore, like interviewing candidates.
It seems like companies these days want direct replacements or shoe-in workers, that can go from orientation / setting up equipment on day 0, to producing code on day 1.
When I started out, I had 6 months of training and getting familiar with codebase plus tech.
This is obviously not the case everywhere, but seems like a trend from my own experience.
[+] [-] newsgremlin|6 years ago|reply
[+] [-] EADGBE|6 years ago|reply
That company's HR department said "there's no way I'm paying a junior web developer that, that's not what glassdoor.com says they should make". The hiring manager knew they'd be an asset worth "senior" status, because they knew they had to move quick and the candidate already had a week's worth of in-person interviews scheduled elsewhere. Thus, the web developer is now a "senior web developer".
It's on their email signature, so you know it's legit.
[+] [-] WrtCdEvrydy|6 years ago|reply
I mean, I've seen the counter... and it's not pretty.
[+] [-] anovikov|6 years ago|reply
Senior people are those who started off writing open source as a hobby, built up a great github profile, got hired into a small and poorly funded startup to do a job which a senior would do (because that startup didn't have a better alternative), broke some things, built experience, and proceeded to work in normal places as a senior.
This is how i see it should happen in a perfect world. It's just the international division of labor: if you have a low budget to pay someone do low-impact coding you will have a better bang for the buck spending it in India, not hiring a junior in the Valley. When you need to do serious stuff, you need local people of a senior level.
There is no place left for an American junior, as well as for Indian senior, too (their companies operate, or at least should in the perfect world operate, in outstaffing mode so they don't really need architects, only job for a senior developer may be doing interviews, probably).
[+] [-] WrtCdEvrydy|6 years ago|reply
When I teach a new concept, I can instinctively tell who will listen, apply it and be able to move on to tougher concepts while understanding that some of them will be hard headed and will have to be beaten into submission.
One day, I got fed up with one of them (he kept trying to parse JSON by splitting the string in Java), and told him I would honestly use GSON to parse it because I'm lazy. I could see it click in his mind, as he realized writing a small JSON schema in Java was easier than his convoluted 12-step if statement chain (he was performing the string splitting based on the URL he was doing REST requests against). Now I call it the 'laziness as teaching' tool.
1) Admit you're doing it because you're lazy
2) List the set of items that need to be done in the new lazy approach
3) Contrast it against the previous method
4) Watch it click as they realize their way is so much extra work.
[+] [-] pm90|6 years ago|reply
Letting juniors experiment the best design by failing is sometimes an effective strategy. And if they do succeed or produce a better solution, awesome. That is a lesson that you can learn from (technology changes very quickly).
[+] [-] zeta0134|6 years ago|reply
[+] [-] tempguy9999|6 years ago|reply
I truly do not understand the mindset that, when presented with a simple means of doing a complex task, will do it manually[0].
If a junior dev did that in front of me I'd seriously start doubting their capability for the job.
[0] The one single allowable exception is doing a crappy task manually the first time so you know how, before switching to a tool. My first parser I ever wrote I did manually rather than with flex/bison so I knew how to. After that it was tooling all the way.
[+] [-] stcredzero|6 years ago|reply
EDIT: I misread and thought he was a supporter of the regime, but the source is not a villain as I thought before. In any case, I think there is some wisdom in this quote.
https://en.wikiquote.org/wiki/Kurt_von_Hammerstein-Equord
I wonder if an RPG could be made adding these two axes to the alignment graph? (I just want to play a "Chaotic Stupid" character.)
[+] [-] taneq|6 years ago|reply
[+] [-] silveroriole|6 years ago|reply
[+] [-] barbecue_sauce|6 years ago|reply
[+] [-] hinkley|6 years ago|reply
[+] [-] ex3xu|6 years ago|reply
If this article's point appeals to anyone and they are looking for a modern researcher on the topic, I'll gently push them in the direction of Brene Brown's work on embracing vulnerability as a driver of personal growth: https://www.ted.com/talks/brene_brown_on_vulnerability?langu...
[0]: https://hashref.com/summaries/TheNowHabit.pdf
[+] [-] purplezooey|6 years ago|reply
No. It's just not realistic. In today's company your manager will say that to you then slate you for the "bottom 10%" category and you'll receive decreasingly subtle signs that they want you to leave. Companies don't actually train, reinforce or develop employees anymore, at least not for more than a few weeks.
[+] [-] excitedNerd|6 years ago|reply
[+] [-] onion2k|6 years ago|reply
This is usually a sign you're working for a manager who's never had a good manager themselves, so they've never learned how to manage a team well.
[+] [-] asveikau|6 years ago|reply
[+] [-] euske|6 years ago|reply
I'm not American, but I tend to think that assuming the existence of wizards or geniuses is fundamentally Unamerican.
If anything, the concept of wizard etc. is pretty much in the eyes of the beholder. In this sense, we're digging ourselves deeper by needlessly magnifying and exaggerating one's "ability". Different people produce different outcomes, but the difference in their output is mostly accidental.
Humans are not comfortable with explaining everything as luck. But I think many things are actually explained by luck, and we should take it easy.
[+] [-] closeparen|6 years ago|reply
I don't think absence of mistakes is what makes these people great, though, more like the difficulty of the problems they're able to solve, the effectiveness with which they can manipulate and discuss ideas, and the fitness-for-purpose of their solutions.
[+] [-] switchbak|6 years ago|reply
I'd much rather treat these as pretty common sense, learnable lessons that are accessible to anyone.
As for one's output being mostly based on luck? I must disagree with you. I find those that care about what they're doing, and why they're doing it - consistently outperform those that aren't invested in what they're doing. And I think there are those that are more suited to our line of work than others (whether due to how their minds work, or otherwise).
Luck does however play a part in the chances we get to learn and to prove ourselves, especially if you're not born into a relative position of advantage. But to sum up one's contributions, skills, talents and effort to be just luck? That seems dismissive.
[+] [-] guntars|6 years ago|reply
I prefer to work with people that accidentally consistently produce better outcomes.
[+] [-] gridlockd|6 years ago|reply
Neither do unicorns or nasal demons. It's a colloquialism and you're taking it too literally. Then there's Clarke's First Law:
"Any sufficiently advanced technology is indistinguishable from magic"
> Different people produce different outcomes, but the difference in their output is mostly accidental.
This is completely and obviously untrue. Do you believe a tightrope walker just gets lucky all the time, or that any ordinary person could do the job just the same?
> Humans are not comfortable with explaining everything as luck. But I think many things are actually explained by luck, and we should take it easy.
Actually, a lot of unsuccessful people are perfectly comfortable explaining everything away with "luck". That's how they stay unsuccessful.
Programming isn't about "luck", it is about skill. You don't get a working program "by chance". Sure, you might land that job because you're lucky. You're lucky to live in a time and place that offers you modern computers. You're lucky to have a brain that affords you to learn this skill - but you don't become a programmer just by accident.
[+] [-] apotheosis|6 years ago|reply
[+] [-] alphaoide|6 years ago|reply
[+] [-] lozenge|6 years ago|reply
[+] [-] Waterluvian|6 years ago|reply
Mistakes are just... Ugh. They're so normal and so important to growth that it frustrates me that they're ever perceived as a bad thing. If you're not making mistakes then you're not making those risky plays that turn into goals 7% of the time. You'll end up being a consistent, mediocre player.
[+] [-] davnicwil|6 years ago|reply
Below that, I think being as boring and consistent as possible is actually the key to being an above-average player, paradoxically. It's the same percentages at work - for averagely talented players, those risky plays don't succeed 7% of the time, more like 1% (for argument's sake, obviously made up numbers) so it's actually a better strategy to do the boring thing which might succeed say 5% of the time, consistently. Still low, but better on average than most people who do try the risky, extremely unlikely to work, plays more frequently.
[+] [-] BurningFrog|6 years ago|reply
Attacking players are measured by how many successful things they do. Scoring 2 goals and making 50 mistakes in better than scoring 1 goal and making no mistakes.
Defensive players are measured by how few mistakes they make. Period.
[+] [-] optimiz3|6 years ago|reply
NHL players get paid big bucks because their mean is higher.
Everyone makes mistakes, but in the end much of it comes down to talent and work ethic, both of which enable people to recover from their mistakes.
[+] [-] tehlike|6 years ago|reply
The ones who are afraid of making mistakes will never learn and be a constant mediocre player.
Valid at work, valid in real life.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] rmason|6 years ago|reply
https://www.youtube.com/watch?v=hxOjJmUtTYA
He was a college professor in Grand Rapids who if I remember started the company with a student. He impressed me because he had company culture figured out early and that gave Atomic Object a distinct advantage.
They've expanded to several locations in the state and have an extremely low turnover compared to other shops. He understands that not every programmer wants to go into management and they're encouraged to become mentors and help staff stay current. He also indicated that he was starting to become an angel investor. I found him to be quite an interesting guy.
[+] [-] DoreenMichele|6 years ago|reply
Of course, sometimes you still have to cut people out, but it is possible to foster a culture of growth rather than a climate of terror.
If this sounds strange, it's because so few organizations do it, not because it doesn't work.
[+] [-] Lowkeyloki|6 years ago|reply
[+] [-] gilbetron|6 years ago|reply
[+] [-] RandomGuyDTB|6 years ago|reply
let me stop you right there buddy
[+] [-] throwaway180118|6 years ago|reply
[+] [-] jshowa3|6 years ago|reply
[+] [-] LandR|6 years ago|reply
[+] [-] janpot|6 years ago|reply