You're Worthwhile, Even When You Make Mistakes
spin.atomicobject.com
spin.atomicobject.com
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.
If I had to conjecture, it's much more a person's mindset, the organizational culture, and their incentives (so the system), that will dictate how they respond to mistakes.
I have seen this in organizations from to tech, to education, non-profits, and beyond.
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.
https://tobi.lutke.com/blogs/news/11280301-the-apprentice-pr...
It’s interesting that unpaid internships have become the norm so much that the ‘unpaid’ part of the term has become redundant.
So please don't look down on people writing tests. Quality assurance is what makes software suck less.
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!
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.
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.
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 mean, I've seen the counter... and it's not pretty.
For us, "senior" means "promoted twice" i.e. by first building a successful small system and then by building a successful medium system, with the first having not imploded yet, and your peers and stakeholders generally happy.
Mostly I feel that "senior" is more likely to trigger overconfidence and "tin god" personas; conversely "junior" is a classification I feel people tend to be too much in a hurry to shed. These are obviously traits of the people exhibiting the behavior, and not the fault of the terms themselves, however it is not inappropriate to take human nature into account. Accordingly I am wary when the title is tossed around lightly.
In general I do agree that titles are mostly arbitrary and useful just as an org-specific shorthand for the responsibilities and achievements implied.
Thanks for sharing your org's criteria, it's nice to hear about places that base evaluations on how happy both peers and stakeholders are.
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).
You can keep trying to reduce the complexity and change you see around you by pretending it boils down to simple divisions, but you end up just fooling yourself.
The more interconnections develop across and around traditional hierarchies, the less such divisions and hierarchies are required. People who see that increasing connections create more paths and opportunities will prosper. And people who don't see it will not. Irrespective of whether they are Americans or Indians.
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.
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).
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.
> If a junior dev did that in front of me I'd seriously start doubting their capability for the job.
Everyone has gaps in their knowledge and learned-approaches to problems. Even the most senior and experienced people have gaps, or develop gaps as things change rapidly. The junior simply did what he knew would work, and the mentor happened to know a better way.
The proper, healthy response to something like that is exactly what the parent commenter did, and it ended with "a click" in the mentee's mind-- a small but noticeable step-up in the skill and knowledge of the junior. That's satisfying to both the junior and the mentor.
If your response to a mistaken approach is questioning whether or not someone should even be there, well, that's pretty much an example of the sad state of the status-quo. It's how people end up making horrific software because they're too afraid of getting input from someone that can help them because they have learned, over time, that asking for help too often means a withering dismissal from someone who should have known better.
My last job was precisely described in your last paragraph. I loathed asking for help from a senior dev I was working with because every time I did, she made it very clear how much of a nuisance I was being. She even verbally chastised me over IM for correcting a typo in a variable in a stored procedure she wrote.
Working with her was an exercise in torture and I eventually quit because my manager believed her on everything. I was also so full of self-doubt that I questioned whether I should even be a developer anymore.
It screwed with my mind so much that I still have a lot of anxiety to this day.
Some people act that way because they experienced the same kind of abuse when they were starting out. They end up dishing out what they themselves received, perhaps believing that that's the way things are supposed to go.
Others, do exactly the opposite and retroactively compensate for their mistreatment by being kind and supportive in a way they wished they had been treated.
Edit: and I'm really sorry you had to go through that.
Read the original post: "he KEPT TRYING to parse JSON by splitting the string in Java"
This rather fits with the other bit about "beaten into submission"
I have to assume from that text that he'd already been shown how to do it. If he could not understand that the easy way was easier than doing it the hard way, well pfffft.
It may be there's more subtlety here than was given, I dunno.
Real life work is not like stackoverflow, if you have a team that's your responsibility, you can't just downvote them to oblivion. Nor can you use performance on any one incident to decide to end someone's career in that particular workplace.
Sometimes people just don't measure up to expectations, that's OK, it happens, but firing should be a decision based on a history of underperformance.
Questioning whether or not someone is fit to "be there" should be something that is done upon deciding to start a PIP. Otherwise, it's just eroding the confidence and motivation of the individual and the team and, in many ways, is as bad as firing that person out of spite.
1) Bbscure the logic of solving the task. 2) Layer on extra logic of the tool. 3) Warp your thinking around the tool, causing you to miss easy optimizations.
These are some reasons to not use a ready-made tool.
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.)
I don’t think he counts as a villain, unless you were pro-Entente.
I'm not sure why you're incredulous about this? If you're struggling to write your own JSON parser, you are learning something new by doing something hard. Maybe you're not learning a lot (if you're just brute-forcing it), but you're still learning. Being in flow means you aren't learning, it isn't deliberate practice.
If somebody was wasting a lot of time rewriting a library instead of using it, it might be time to have a discussion on learning vs delivering value. I think 20%-30% is the sweet spot of learning vs producing.
It's kinda weird, because I only get the juniors that are on the fast track for promotion. I'm just supposed to fill in any holes on their knowledge sets for React, NodeJS, and some of the legacy applications in house and pass them along. They'll usually only spend like 3-4 months with me. Someone who isn't learning gets sent back to the general junior developer pool for a bit longer.
How about nothing? Just because their approach isn't the one you would take doesn't necessarily make it wrong. You've clearly offered your help, but if they don't want it, that's their decision. Some people have a hard time learning from others' mistakes and need to make their own.
Does their code produce the incorrect results or are they unable to complete their tasks in the alloted time? You (or management) can push them reasonably on that; otherwise, embrace the idea that they can still be effective without doing everything your way. You might even be able to learn something from them.
> ...elect to use a truck that someone else has manufactured rather than building your own, that's expected behavior.
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...
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.
As far as could tell, they weren't saying it didn't happen to you but to infer that's (generally) not how things work elsewhere. For example, if you've never heard of the phrase "being managed out"[0,1,2], you're lucky, but others haven't been and will continue to not be for some time.
You're preaching to the choir, essentially. :)
[0] - https://www.linkedin.com/pulse/getting-managed-out-fired-wel...
[1] - https://www.mattgingell.com/managed-out-at-work-a-guide-for-...
[2] - https://www.ronankennedy.ie/blog/2017/1/16/am-i-being-manage...
I'm not sure that follows just from adding your own ancedata ;). I've made my share of mistakes at every job, and haven't gotten managed out. What will get you fired is consistently under-performing, persistent personality conflicts, or repeated negligence without visible improvement.
Your company might be too lazy to have any sort of formal training program, but that cuts both ways - they'll be too lazy to hire a replacement if you're showing signs of improving, too. Your manager probably has too much on their plate to train/mentor you themselves, but I work places where coworkers like talking shop, and will generally be happy to share advice, techniques, thought processes, etc. - especially if it means they're enabling you to take things off of their plates to get more stuff done.
Now, granted, this isn't everywhere, but it's far from being OC's "unrealistic" either.
Aye and thanks for the contribution to that effect/effort.
Maybe one day we'll get to a point where this is normative in the industry (and it's my earnest, strident hope that we do).
Absolutely, a capable person can contribute far more if they develop professionally especially when trust is built between employer and employee, with the caveat that this is specific to tech firms whose business model centers around developing a body of code and institutional knowledge to maintain it. But this is a minority of firms and thus what a minority of people experience.
Most IT roles have a lot of churn. Contracting is a big one, but many roles in non-tech firms don't benefit much from highly skilled engineers because the software is not their core business. If you land in one of these roles, you'll likely have the negative experience many people talk about.
Broadly put, the best jobs in a company are usually the ones critical to what the company does. If you're doing support work of some sort, yeah, you're easily replacable. On the bright side, it's good experience you can leverage to get a better position.
The other problem is for everyone trying to become an engineer, most will fail, and the only way to know is usually to fail repeatedly, which is a miserable experience. If your management really is good at investing in their employees, it can be less painful as they can help you transition, but nothing can make trying really hard and failing a pleasant process. And since the quality of management is something like normally distributed, the bulk of people go through this with mediocre guidance.
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.
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.
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'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 really love Julia Evan's writing as well, especially the way she's so humble and open about her path.
I have unfortunately met a bunch of folks that while being brilliant, also seem caught up in being seen as uniquely gifted/powerful. When their status gets challenged, they can be particularly nasty in defending themselves. And it's that connotation where the Wizard metaphor troubles me. Looking back I've even see myself getting caught up in this, which I think can be an energetic trap, and really harm relations and even team efficiency.
Funny that a single word has such a dichotomy :) Thanks for the article!
Of course I actually don't believe that everything is just luck. But too much emphasis on one's talent and ability and "good taste" and/or "right choice" etc. is actually intimidating and harmful. (Again, the balance is the key.)
Note to self: the word I should've used was "mysticism".
I prefer to work with people that accidentally consistently produce better outcomes.
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.
Would you say there isn't some element of luck to that?
Granted I don't think it's a dominating factor, but I do think that it is present.
Even if all you do is copy-paste code by trial and error, there's a level of skill to that too.
Sounds like they're being quite earnest about the wizard stuff. Clicking through the links yields even more wizard talk.
[1] https://spin.atomicobject.com/2018/06/01/conjure-joy-from-pa...
[2] https://spin.atomicobject.com/2018/11/07/wizard-consultant-s...
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.
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.
I was that consistent mediocre player in the 10+ years I played hockey. I was always so nervous and afraid of making mistakes. Absolutely terrified. Mainly of letting down the "good players" So I just played this safe game and got maybe 3 points a season.
Then one season I was put onto a team with three Allstars who didn't want to play A or AAA that year. They got onto the same team because all three of their dads were the coaches for the team. They encouraged more growth out of me than any coach or teacher ever has before. Everyone was so supportive and after a few months I was genuinely convinced that nobody was going to get upset if I made mistakes. So I started putting myself out there. I started trying to position myself usefully. And the others actually stated passing me the puck. And every time I messed up someone would give me some form of verbal or nonverbal reassurance. My confidence exploded. We won everything that year and went on to the All-Ontario tournament. I was 16 and that was maybe one of the best weekends of my life. I still vividly remember this almost two-line pass that I received and dodged around the defense. Almost a breakaway but the goalie scrambled out and dove on the puck. Coach said, "holy shit. Where was that all season?!" A formative memory I will never forget.
And then the next season. 16-17 year Olds. Lots of hormones. A real bunch of assholes. They reinforced all my fears about making mistakes. That was the last year I ever played hockey.
I did briefly get back into team sports playing soccer at University, and while better because I was older, I still just found the pressure of making mistakes with a team made of people I wasn't really close friends with kind of spoiled the enjoyment ultimately.
In adulthood I started focusing on squash, and enjoy it so much more in no small part because it's an individual sport and it totally flips the mistakes situation around. Yes, mistakes are mega frustrating, but they happen and they're lessons to be learned from to improve - all embarrassment and social pressure of letting others down is gone.
I don't think this stops when we grow older. We're primates who live in groups. The approval of our group is vital for our mental well-being. It's tempting to believe that we've outgrown this mentality because we've evolved past it, or we've gathered enough wisdom to be unaffected by it ... but I don't think we have. Ostracism works just as well on adults as it does on children.
This applies for more than just sports, for example, programming. For the majority of people, it's better to focus on consistency, readability, and idiomatic code, rather than clever optimization and heavy hand solutions that allow bugs to creep in.
[1]: https://academics.hamilton.edu/documents/themundanityofexcel...
There are many many roles where you need to be able to make mistakes. Predictability is
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.
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.
The ones who are afraid of making mistakes will never learn and be a constant mediocre player.
Valid at work, valid in real life.
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.
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.
let me stop you right there buddy