> Next time, I had learned the coding conventions and how scope worked in JavaScript. The time after that I finally understood closures.
Is this normal in some companies? This seems to imply they shipped production javascript in which the author didn't understand scope or closures. I can't honestly wrap my head around this one.. how could you write functioning code without understanding scope and closure? Repeatedly moving code lines around until it doesn't give an error or something? Putting everything in a single function?
Yes, it is quite normal in companies with good code-review policies. I review code, not its author.
As far as writing functioning code without understanding scope and closure, a lot of JavaScript is written in a way that just doesn't require deep knowledge of the language. For example, take [1]. It certainly requires some JS knowledge to understand its purpose, but, at the same time, I'd feel comfortable assigning a new-to-JS programmer a task like "give each callback a custom string that's printed out when it's called." and expecting him or her to complete it.
"I learned how scope worked" does not imply that the author was previously unaware of the concept or didn't understand it at all, it just means that there was some aspect that she didn't fully understand until it was pointed out in the code review. I don't find that hard to believe at all. How many developers have you met that never had any questions or misunderstandings about, for example, the scope of `this` in JavaScript?
This seems quite normal in companies. Obviously the size, age and (development) leadership in companies would determine exactly how "excellent" released code could be. My career has mostly been as web (application) developer at small companies that had a priority other than "highly skilled developers." The priority was usually "a complete web site that functioned." Whatever ugly, un-reviewed code that made it into that released product was fine, as long as it "functioned." None of these places included code-review as part of the release process, so there's zero chance of preventing code being released that wasn't written with full understanding.
Personally, I only came in contact with the term "closure" rather recently. Scope was something I intuitively understood since my early days as a coder, and read about. This is the good and bad of being completely self-taught in most respects. There was no linear escalation of education to hold my hand through each and every concept. I would try code that I felt would work. Usually it would. Was it elegant, self-contained, de-coupled? Nope, not at all. But it functioned.
Whilst it's probably impossible to write code without understanding anything about scope, you can actually get quite far without understanding lexical scope and closures.
For example, I've worked on a load of JS projects where every function is first-order, named and written at the top level, except for a few clearly redundant anonymous callbacks like `function(x) { return foo(x); }`. Obviously that code has been written without understanding first-class functions, lexical scope, closures, etc. but it worked.
I've also been in the reverse situation in code reviews: where I've made some use of lexical scope in my code, and had to explain what lexical scope and closures are to the other members of the team.
I've been repeatedly told to be wary of using too much lambdas in Java because some of the cow-orkers have problems with while loops, so... well, my experience with professional programming so far is that most people barely know how to code and there's little incentive to change it, since modern professional programming is just plumbing - connecting libraries together with snippets from Stack Overflow. And I'm being only a little cynical.
(And the whole argument about avoiding to use language features is ridiculous. In commercial space, people don't expect others to learn anything, as if programming wasn't a craft and as if people were born to do it. Imagine a boss telling construction workers not to use power tools because some of the young hires have never seen a powered drill in their life.)
There is a third option when confronting failure other than "blame others" or "drop out": admit the failure, learn from it and know you will do better next time. That's what successful people do.
There's the fourth option of not judging yourself on whether you are a good programmer or bad programmer but instead just trying to become better (which I think is essentially the conclusion eventually reaches).
It's the shift from a fixed mindset to a growth mindset a la Carole Dweck. That is quite a tough shift to make however when you've been conditioned with lots of feedback from school and university telling you are good and then suddenly that feedback disappears when you start work. Indeed I imagine most programmers aren't actually especially good when they first start - certainly if I looked back at the code I wrote 10+ years ago, I'm sure I would cringe.
> just trying to become better, which I think is essentially the conclusion eventually reaches
Yes, though there's a lot more detail to it than "just trying", mostly about good ways to get there: shortening the feedback cycle of improvement through peer feedback, getting past the fear of failure by lowering the cost of mistakes through blameless review. And that "being smart" is the wrong criterion, which I think is the "growth mindset".
Hmm, the motivation towards self-improvement this kind of pressure creates can be a good thing, but that has to be weighed against unhealthy levels of stress and undue hits to confidence.
I think it better to believe oneself junior, but competent for that level, than an incompetent senior.
A slow ease into unfamiliar tasks, with initial supervision from someone already familiar, is what might be best practise, but given current demand for programmers, is often not what you end up in. "Hit the ground running" can be the euphemism...
One of the really important insights from Dweck's work is that the style of the feedback itself influences mindset, independent of whether the person receiving it is trying to become better or not. Kids who receive "you must be pretty smart" feedback are much more likely to fall into a fixed mindset, which in turn leads to avoiding challenge, resisting trying to become better, and having a harder time with failure. Kids who receive "you must have worked very hard" styled feedback are pretty much the opposite.
I really wanted to like this essay but I'm having a hard time with the fact that it basically overlooks how important feedback style is to mindset. The sixth paragraph in particular struck me as full of fixed-mindset thinking.
It's a topic my mentor/friend (I always add mentor because he means more to me than just "friend" and he teaches me stuff) have discussed before. Our work environment is lacking in a lot of feedback and review; we're often reporting to people who don't work in our company and touchy-feely stuff is indirectly seen as unnecessary in this culture. Add that to the fact that we're separated from the majority commercial IT world and there's a sense of "we're just hacks" and really don't know what we're doing, we're just her because of a lucky credential that gets us hired and riding the contracting gray train.
In trying to evaluate my skills absent feedback, I look to compare myself to those around me. And there, I've noticed, is dangerous territory. I need to state that what happens here, is not good, but it should be recognized. If I'm on a team of engineers and operations staff, building a system, I look around and see what others are doing. Did the configure something wrong that resulted in a fault? Someone screw up and dump too much on that datastore? "Ha!" I guiltly laugh. Because I knew not to do that, I must be better than them. And since, given I hold a very critical view of my own skills, if I'm simply average or "getting by", then they must be really bad indeed.
Of course, that's a terrible thing to think about one's colleagues. There's a danger in thinking that because one knows something, that knowledge must be common because to know something esoteric would be exceptional and therefor, better. Keeping with the narrative that we're average, and knew it anyways, then it must be exceedingly simple and the other person should have known better. That's not the case. We can know uncommon things. We can be deeper in our fields than we think.
The other fallacy of course is that it's also a degree of confirmation bias. Everyone else's failing below ours is a sign of their ineptitude. It assumes that our own mistakes wouldn't have been caught in turn.
All of this I'm trying to illustrate is, impostor syndrome can be harmful to more than just ourselves when we fail to believe in our own abilities and at the same time, measuring ourselves against others. I've caught myself trying to drag my colleagues down in my private assessments in this way, and that's not good.
This is a misreading of imposter syndrome, at least how I understand it to work and how it has been used in common parlance around me. Granted that has included a lot of academic circles and math/physics types, not only programmers.
Imposter syndrome refers to beliefs about your own lack of competence, skill, experience or whatever - in contradiction to good evidence to the contrary. And the uneasy feeling that you're going to be "found out" at any moment. As such I think it is a useful characterization, and understanding it will help you mentor some people more effectively.
I get the point in the article, and I do think a lack of feedback does contribute to this in some way (especially in smaller or newer companies where getting any sort of code 'review' is pretty much non existent), but I think the simplest reason for imposter syndrome might just be same as the reason so many are unhappy on social media.
You just can't see how much other developers might be struggling with issues. You can picture your own struggles and time online looking through Stackoverflow answers and documentation and what not, but not the nightmare some other 'better' developer might be having with their own work.
So you think other people are simply not struggling, and hence know more than you do, or can pick things up more quickly, or whatever else.
Maybe it's just more of a 'grass is greener' thing.
19 comments
[ 1.6 ms ] story [ 18.4 ms ] threadIs this normal in some companies? This seems to imply they shipped production javascript in which the author didn't understand scope or closures. I can't honestly wrap my head around this one.. how could you write functioning code without understanding scope and closure? Repeatedly moving code lines around until it doesn't give an error or something? Putting everything in a single function?
As far as writing functioning code without understanding scope and closure, a lot of JavaScript is written in a way that just doesn't require deep knowledge of the language. For example, take [1]. It certainly requires some JS knowledge to understand its purpose, but, at the same time, I'd feel comfortable assigning a new-to-JS programmer a task like "give each callback a custom string that's printed out when it's called." and expecting him or her to complete it.
[1] https://github.com/facebook/react/blob/master/src/shared/uti...
Personally, I only came in contact with the term "closure" rather recently. Scope was something I intuitively understood since my early days as a coder, and read about. This is the good and bad of being completely self-taught in most respects. There was no linear escalation of education to hold my hand through each and every concept. I would try code that I felt would work. Usually it would. Was it elegant, self-contained, de-coupled? Nope, not at all. But it functioned.
For example, I've worked on a load of JS projects where every function is first-order, named and written at the top level, except for a few clearly redundant anonymous callbacks like `function(x) { return foo(x); }`. Obviously that code has been written without understanding first-class functions, lexical scope, closures, etc. but it worked.
I've also been in the reverse situation in code reviews: where I've made some use of lexical scope in my code, and had to explain what lexical scope and closures are to the other members of the team.
(And the whole argument about avoiding to use language features is ridiculous. In commercial space, people don't expect others to learn anything, as if programming wasn't a craft and as if people were born to do it. Imagine a boss telling construction workers not to use power tools because some of the young hires have never seen a powered drill in their life.)
http://www.amazon.com/Daring-Greatly-Courage-Vulnerable-Tran...
This book addresses a lot of these issues in broader sense, so it applies to all areas of life.
It's the shift from a fixed mindset to a growth mindset a la Carole Dweck. That is quite a tough shift to make however when you've been conditioned with lots of feedback from school and university telling you are good and then suddenly that feedback disappears when you start work. Indeed I imagine most programmers aren't actually especially good when they first start - certainly if I looked back at the code I wrote 10+ years ago, I'm sure I would cringe.
Yes, though there's a lot more detail to it than "just trying", mostly about good ways to get there: shortening the feedback cycle of improvement through peer feedback, getting past the fear of failure by lowering the cost of mistakes through blameless review. And that "being smart" is the wrong criterion, which I think is the "growth mindset".
I think it better to believe oneself junior, but competent for that level, than an incompetent senior.
A slow ease into unfamiliar tasks, with initial supervision from someone already familiar, is what might be best practise, but given current demand for programmers, is often not what you end up in. "Hit the ground running" can be the euphemism...
I really wanted to like this essay but I'm having a hard time with the fact that it basically overlooks how important feedback style is to mindset. The sixth paragraph in particular struck me as full of fixed-mindset thinking.
It's a topic my mentor/friend (I always add mentor because he means more to me than just "friend" and he teaches me stuff) have discussed before. Our work environment is lacking in a lot of feedback and review; we're often reporting to people who don't work in our company and touchy-feely stuff is indirectly seen as unnecessary in this culture. Add that to the fact that we're separated from the majority commercial IT world and there's a sense of "we're just hacks" and really don't know what we're doing, we're just her because of a lucky credential that gets us hired and riding the contracting gray train.
In trying to evaluate my skills absent feedback, I look to compare myself to those around me. And there, I've noticed, is dangerous territory. I need to state that what happens here, is not good, but it should be recognized. If I'm on a team of engineers and operations staff, building a system, I look around and see what others are doing. Did the configure something wrong that resulted in a fault? Someone screw up and dump too much on that datastore? "Ha!" I guiltly laugh. Because I knew not to do that, I must be better than them. And since, given I hold a very critical view of my own skills, if I'm simply average or "getting by", then they must be really bad indeed.
Of course, that's a terrible thing to think about one's colleagues. There's a danger in thinking that because one knows something, that knowledge must be common because to know something esoteric would be exceptional and therefor, better. Keeping with the narrative that we're average, and knew it anyways, then it must be exceedingly simple and the other person should have known better. That's not the case. We can know uncommon things. We can be deeper in our fields than we think.
The other fallacy of course is that it's also a degree of confirmation bias. Everyone else's failing below ours is a sign of their ineptitude. It assumes that our own mistakes wouldn't have been caught in turn.
All of this I'm trying to illustrate is, impostor syndrome can be harmful to more than just ourselves when we fail to believe in our own abilities and at the same time, measuring ourselves against others. I've caught myself trying to drag my colleagues down in my private assessments in this way, and that's not good.
Imposter syndrome refers to beliefs about your own lack of competence, skill, experience or whatever - in contradiction to good evidence to the contrary. And the uneasy feeling that you're going to be "found out" at any moment. As such I think it is a useful characterization, and understanding it will help you mentor some people more effectively.
You just can't see how much other developers might be struggling with issues. You can picture your own struggles and time online looking through Stackoverflow answers and documentation and what not, but not the nightmare some other 'better' developer might be having with their own work.
So you think other people are simply not struggling, and hence know more than you do, or can pick things up more quickly, or whatever else.
Maybe it's just more of a 'grass is greener' thing.