You're Worthwhile, Even When You Make Mistakes(spin.atomicobject.com)
spin.atomicobject.com
You're Worthwhile, Even When You Make Mistakes
https://spin.atomicobject.com/2019/06/30/mentoring-you-are-worthwhile/#.XRkm4GAtLuU.hackernews
101 comments
> get a few interns
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
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
My degree involved 4 months of school followed by 4 months of paid work. It meant that it took 5 years, but it was totally worth it. I graduated with 2.5 years of experience at different companies, no student debt, and a full-time job already lined up.
Twenty years ago I don’t think the word internship carried an expectation of being unpaid. The term ‘unpaid internship’ was used for that.
It’s interesting that unpaid internships have become the norm so much that the ‘unpaid’ part of the term has become redundant.
It’s interesting that unpaid internships have become the norm so much that the ‘unpaid’ part of the term has become redundant.
I don't know anyone who expects an internship to be unpaid, especially in the tech industry. I've heard quite a few complaints in the medical industry though.
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.
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!
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.
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.
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.
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.
> 2 of them were writing tests
I mean, I've seen the counter... and it's not pretty.
I mean, I've seen the counter... and it's not pretty.
I believe the point being made is that 5 years isn't really enough to call oneself senior, especially if 2 of those years is in a very narrow focus with little to no consideration for the larger picture required.
The meaning of a job title is encoded in your company's performance review and promotion system criteria. All other beliefs about what a title "should" be are just noise.
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.
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.
Also, at some companies getting promoted is the only way to higher pay, and you have to promote people so they don't leave due to financial factors. It can be the only way around brick walls set up by HR("no, we can't give this guy a $5k raise, but we can promote him to senior and give him a $5k raise" - logic)
Yeah that's a good point.
I would agree if it weren't for the baggage that gets attached to the "senior" and "junior" titles. I'll admit to having my own -- otherwise I wouldn't be here arguing about it, haha.
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.
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.
So maybe there are still interns, they just have a fancier title now?
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).
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).
The world is not static. It's complex and ever-changing. And people aren't trained to think about that complexity or change.
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.
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.
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.
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).
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 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.
I agree with this 100%.
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.
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.
Yep, I've seen it too.
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.
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.
This does not relate to what I wrote. She was a dick. That does not reflect on you in any way. End of.
Edit: and I'm really sorry you had to go through that.
Edit: and I'm really sorry you had to go through that.
> Totally wrong.
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.
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.
It all depends on what one means by "already been shown how to do it". Something like that could easily be misunderstood/forgotten by the trainee or glossed-over by the senior. Or maybe he was just having a bad day. Whatever the case, learning often takes some amount of repetition before mastery is achieved.
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.
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.
Sometimes, the simple means of doing a complex task will
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.
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.
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.
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.)
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.)
“He was an ardent opponent of Hitler and the Nazi regime.”
I don’t think he counts as a villain, unless you were pro-Entente.
I don’t think he counts as a villain, unless you were pro-Entente.
Sorry, I misread that he was a supporter!
Laziness is, after all, one of the core virtues of a programmer (along with impatience and hubris.)
A certain amount of laziness really is an important skill to have as a programmer, the busy bee will do lots over-engineering over-architecting and wheel reinventing. Where the lazy guy will go out of their way to find and use libraries and tools that save them effort and get the job done and have way less bloated code. On the other hand things like not being diligent about fixing bugs can be a problem though.
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.
> in some weird way they must have ENJOYED struggling and thought it meant they were learning or solving something hard
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.
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.
I think enjoying the struggle will lead you wrong more often than not. I normally find that if I’m really struggling, it doesn’t mean I’m learning, it means I’m missing some information and I need to seek guidance. I’ve always learned more from looking at a successful existing implementation than trying to brute force my own solution (though it’s fun/useful to have a pop at something on your own first, of chorse). Sure, you need some tenacity and concentration, but I don’t understand people who will happily and repeatedly bash their head against a wall for hours without ever checking whether there’s a way around the wall!
> what do you do with the juniors who never get it?
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.
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.
> Question is, whad to you do with the juniors who never get it?
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.
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.
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.
> ...elect to use a truck that someone else has manufactured rather than building your own, that's expected behavior.
When I'm feeling sardonic I will call it 'being lazy' but at other times I will describe it as "because I have better shit to do."
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.
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 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'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.
(Author here again) I appreciate your point here! It's true that "wizard" reminds me a little bit of being called a "rockstar," which I have always had a distaste for due to the above-mentioned ego thing. I elected to use "wizard" because I find it to be a useful and interesting metaphor in light of my own personal love for RPGs and fantasy, and because I was really inspired by Julia Evans' use of the term to de-mystify learning. I think of it as a rhetorical device, and nothing more.
Good to hear. That's essentially how I read the article, and I think it has a special quality to those with the rpg/ fantasy background.
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!
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!
Ah yes, the power-mad dark wizard. You should avoid that guy and hang out with the laid back hippy zen wizards.
> 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.
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".
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".
> Different people produce different outcomes, but the difference in their output is mostly accidental.
I prefer to work with people that accidentally consistently produce better outcomes.
I prefer to work with people that accidentally consistently produce better outcomes.
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.
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 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.
It's a hyperbole https://en.wikipedia.org/wiki/Hyperbole
> I’ve spent the last three years learning to think like a wizard, to conjure joy from pain[1] and cast protection spells over the important things[2]. I finally feel like I’ve grown into a bonafide wizard myself.
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...
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...
If you follow the link at the top of the second post, you can find this, which defines what they think a 'wizard' is.
https://drawings.jvns.ca/wizard-programmer/
https://drawings.jvns.ca/wizard-programmer/
Hah, I remember seeing this when it first came out. Thanks for the reminder. It's not the only reference to Julia Evans on the site either.
> 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.
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.
I think this is just the opposite extreme. I've literally seen people copy and paste code that they didn't fully understand and it ended up working. In fact, one of the senior devs where I work added a piece of code with the specific comment "I have no idea how this works and I don't care" and its been used ever since. And he's not a bad programmer by any means having written probably 90% of the software we use by himself.
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.
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.
Of course there's an "element of luck" to everything, just like there's a level of variance to everything, but the dominating factor is skill.
Even if all you do is copy-paste code by trial and error, there's a level of skill to that too.
Even if all you do is copy-paste code by trial and error, there's a level of skill to that too.
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.
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.
“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.
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.
I don't mean to deride you in any form or fashion but your experience seems to be the outlier and the OC's experience seems to be the modus operandi (having experienced it, myself).
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...
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...
> but your experience seems to be the outlier
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.
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.
[deleted]
I do believe my experience is something of an outlier in our field and I think it'd be great if it wasn't- I wrote the post in hopes that people might see this experience and use these observations to improve their own mentor/mentee relationships.
>I wrote the post in hopes that people might see this experience and use these observations to improve their own mentor/mentee relationships.
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).
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).
> 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.
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.
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.
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.
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.
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.
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.
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.
You might be right. But this is especially interesting to me.
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 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 played team sports all through my childhood and teens (rugby, soccer and field hockey) and totally empathise with what you're saying. Especially at that age, the social pressure of making a mistake is intense, and kids especially are brutal about letting you know you've 'let the team down' or whatever. One of the most vivid memories I have to this day from childhood is scoring an own goal for my school soccer team. Think I literally cried. Hard to imagine it mattering that much now, but I think as a child/teen your peers' opinions and judgement is everything.
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 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 think as a child/teen your peers' opinions and judgement is everything
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.
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.
For most of the sports, there are usually two versions: amateur and professional. The amateur games are the ones where outcomes are decided by who makes more mistakes. In professional games, it tends to be about who can execute more brilliant moves while still minimizing mistakes.
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.
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.
I've seen a nice paper on this subject discussed on HN once: 'The Mundanity of Excellence' [1]. It's about how olympic-level swimmers end up at the olympic level. The point is exactly the one you're making: they do so by consistently doing the most boring things.
[1]: https://academics.hamilton.edu/documents/themundanityofexcel...
[1]: https://academics.hamilton.edu/documents/themundanityofexcel...
an employees value is being predictable
That sounds like one of those reductionist things believed by a Silicon Valleyist who doesn't know there's a world outside tech. Or maybe a project manager who depends on reducing everything to point scores.
There are many many roles where you need to be able to make mistakes. Predictability is
There are many many roles where you need to be able to make mistakes. Predictability is
in my experience companies are very risk adverse - you're better off doing the bare minimum because any mistakes will ruin your career trajectory
When we need automatons to do a job, we write ourselves some automatons.
My sports/mistakes theory:
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.
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.
All I'll say is variance and mean relative to successes and failures.
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.
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.
This is really important.
The ones who are afraid of making mistakes will never learn and be a constant mediocre player.
Valid at work, valid in real life.
The ones who are afraid of making mistakes will never learn and be a constant mediocre player.
Valid at work, valid in real life.
[deleted]
An actual culture of excellence tries to root out bad behaviors rather than looking for someone to pin the blame on.
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.
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.
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...
[0]: https://hashref.com/summaries/TheNowHabit.pdf
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
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're worthwhile
let me stop you right there buddy
let me stop you right there buddy
I'm listening. Go on?
Four years ago I met Carl Erickson, one of the founders of Atomic Object, when he spoke at Lansing Startup Grind.
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.
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.
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.
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.
I've found one of the quickest things to atrophy for managers is their empathy for being an IC.
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.
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.
You make many valid points that I agree with. On a person's mindset, I would say a manager's character does play a role in how they will react. Sometimes some managers are too weak and fear the higher ups so will unleash on the junior. Sometimes though the manager, themselves are also going through issues in their own life so yeah the person's mindset will play a role. The type of organisation will play a role. If incentives are wrong the wrong types of people get promoted and it has the potential to go downhill very quickly.
If nothing else, you can always serve as a good example of a bad example.
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!