In my field (close up magic) I would tell someone that it takes loads of practice to be good. I would be implying two different kinds of practice that they should do. First I would be implying that they should first, on their own, master all of the sleight of hand and patter that goes with a given trick. The second (and most important) kind would be to then perform for people again, and again, and again. Performing for people is where the real growth hides, and where you make the biggest leaps in your abilities. A lot of beginners miss this, because they don't think of performing as practice to get better, they just think of it as "show time, don't screw up". You really need to perform your act in front of people in order to really see what works and what doesn't.
One of the key skills that a good programmer needs but that isn't specifically taught in computer science is reading and understanding large code bases and API's.
I found this to be very much the case. In hindsight I'm also shocked that source control systems didn't get a mention in my course.
As a professional programmer very little of your job involves actually writing code. Most of it revolves around understanding the surrounding code well enough to not fuck it up, documenting shit and quite a lot of testing.
The few times when I had a blank slate to work with felt wonderful: I could write code almost as fast as I could think rather than analysing things for an hour then writing a couple of lines to deal with a bug or to add a feature.
Such one-liners have the potential of leading us in the wrong direction if we are not careful. It's been a common trend nowadays to have thousands upon thousands of blog posts advertising that a seemingly difficult task (learning to program, learning to play music, loosing a lot of weight) is incredibly easy to master in just a few days / few weeks if you just read "these 7 amazing tricks which will blow your mind"!
This seems to be a desire in most people's minds: instead of recognizing in which area you have better affinity and in which you have less, and then investing a lot of effort in the area you have better chances to become good in, the temptation is there to believe that the world is at your fingertips and you could easily learn to do anything you wanted, if you just knew some "insider secrets". This is why there is such a big market for such one-liners.
It might be harsh to say, but for me this seems like the remnants of a shamanistic culture, where people have the power fantasies that if they just learned a few magic phrases from the shaman / a guru, they will be capable of doing magic without expending any significant effort.
I would much sooner trust a scientific article relying on experiments and surveys, than sensationalist blog posts with nice-sounding one-liners, who claim that you can become instantly better at your chosen profession just by reading a few hints. Unless those hints are nothing more than to choose an area you have the better affinity to, and practice, practice, practice and practice.
people have the power fantasies that if they just learned a few magic phrases from the shaman / a guru, they will be capable of doing magic without expending any significant effort.
That's exactly what "expecting short inferential distances" means in this context. Well, there are two options: either this, or assuming that the job also needs some "mysterious essence" you just have to be born with.
Many people believe that ability to learn programming is both highly innate (unchangeable) and highly variable.
What does it take to be a programmer, not just to become one?
Making peace with the fact that there will never be a day when perfect code springs full formed from your head like a Greek goddes, and that what you are getting paid to do (assuming you're getting paid) is to be aggravated.
If the job is good, the aggravations are the kind that you get to have fun eliminating: clients with use cases the product team didn't think of, someone changed an API and didn't tell you, you need to build a new feature, etc. (If the job is bad, the aggravations are probably the same as any other bad job: meetings or mismanagement.)
I'm very explicit about this to everyone I talk about programming to (I work on large-scale projects, mind):
This job is like being a plumber living in the basement of a ten-square-mile building. Not only do you not understand how all the pipes connect, you will never understand where all the pipes connect, and that's okay. This is not a job for people who have to understand all the minutia in order to feel comfortable making a change, nor for people who expect to get a change right the first time they try it every time they make a change. You have to be comfortable screwing up, and more importantly, comfortable admitting you've screwed up so you can undo the mistake and try again. Just try to learn from your mistakes each time.
Do all work planning for the possibility that someone else did something incredibly stupid, and will do something incredibly stupid later. Expect zero common sense. When you run a new line from point A to B, make sure it can handle not merely fresh water and sewage (both, at all times), but also gas and plumbing pieces being run through it, and take what steps are necessary to deal with this.
Simplicity is the most important part of this job, because every bit of complexity you add makes every subsequent thing harder to do without adding even more complexity. Complexity snowballs. Imagine being under there, looking up at a tangled mess of pipes, and needing to run a new line; now imagine a single pipe with branches going out and up. One of these is easy to modify, the other is difficult, and the difficult one is going to require a more complex solution, making the next change harder still. Don't be afraid to make things less complex; some of the most valuable work you'll do is simplifying things.
But don't expect simplification to be appreciated by anyone; indeed, prepare for the need to say nothing about having done so. Your most valuable contributions may require you to be completely silent because they weren't in somebody else's priority queue, and you don't to annoy anybody by letting them know you're ignoring their priorities. The job is very political, and populated almost entirely by people who have no sense of politics, or who think politics shouldn't matter. Pick your battles carefully - and everything you work on is some kind of battle, and if you don't know who the sides are, you're in dangerous territory.
Were anyone to ask me "how does one become a plant population biologist?", I'd say "let's walk and have a look at what grows around here and you will tell me what you see". I don't think that "remember species of interest" will cover it.
I think you are very unlikely going to become a plant population biologist without an academic degree. On the other hand you can become a programmer if you learn to code.
Well, it happens, but such people usually don't have the means to travel widely and remain "any good" only in their little patch of vegetation.
Here's my answer for being a lawyer.
Lawyers actually talk about this. We have the phrase "thinking like a lawyer." We debated what it meant all the way back in jurisprudence class. We reached no conclusions. (Hey, we're lawyers: a conclusion arrives only with hourly fees!)
The modes of thinking for a lawyer alternate between two things: issue-spotting and issue-analysis. The key to thinking like a lawyer is being able to move back and forth between the two modes of thought. As you are issue-spotting, you have to edit down by quick analysis. As you are doing analysis, you have to be aware of issues that you might otherwise pass by. So, issue-spot and issue-analyze.
The other critical thing about thinking like a lawyer is being able to hold multiple contradictory descriptions of reality in your head. The states have to include both the facts (in a pretty probabilistic way) and the law (in terms of the arguments that might be made and again some probabilistic sense of their strength). So, two limited quantum multiverses in your head.
Then trivially, I could say things about being able to communicate well in person, and write well, and work well with other people. But really, that should be an "or," not "and." If you can do one thing really well, that's good enough. So, one good social skill.
Am I on track for what you were asking?
Yes, about this. You know, I always was amazed by how lawyers could hold on to their lines of thinking despite the conversation meandering as it will. Some teachers in our college seem to think it is not a good thing, but really, we students appreciated structured lectures greatly.
Trust the specifications. The customer (your mate, your brother, your dog) will under specify and then change the specifications. Build to spec. If spec if not clear; do not build it. Don't waste your time (you can do that a lot).
(told to me) If you want to be the smartest person in the room don't work for google. even the janitors (the people who are theoretically the bottom rung) graduated with honours at the top of their class and beat out 500 other programmers for the job, just to sweep the floor of the place.
In fact - there is always going to be some upstart 13 year old next week who taught themselves to code at age 3 and reprogrammed half the internet for fun at 15 and wants your job.
...If you want to be the smartest person in the room
That's the usual trade-off between being a big fish in a small pond and a small fish in a big pond.
It would be good to have a way of telling people what they should expect from jobs - especially "intellectual" jobs - they consider taking. NOT how easy or lousy the work is going to turn out, just what might happen and approximately what do they have to do, so that they will decide if they want this.
When people ask for job-related advice, like "how does one become a programmer?", they are often told short and generally useful things, like "learn to code". And maybe also "it is really easy [if you aren't bad at math]". On the other hand, there are all these un-generalized stories of failures which are always just a bit different from the asker's own situation and prospects. There are a lot of them, but they are not actionable; and indeed what can you conclude from them - "it's not easy and don't learn to code"?
Were anyone to ask me "how does one become a plant population biologist?", I'd say "let's walk and have a look at what grows around here and you will tell me what you see". I don't think that "remember species of interest" will cover it. And then, if the person leans down, looks hard and keeps paying attention to the small details, I would share with them some stuff that has happened to me in the field (featuring Dogs, Tourists, Gatherers, Drunks, Heathens, Homeless people, Boars, an Elk, and the most dreaded beasts - the Landowners).
Now, from the point of view of my second supervisor, plant population biology is easy. She began as a geobotanist and then turned to more or less taxonomy, and it takes... work. LOTS of work. Once I brought her my orchid counts, and she said something like "a kid in the Seventh Form can do this; it's not science", and I was deeply offended and upset but didn't disagree. Because technically, if one trained a kid in the Seventh Form to write some Latin, survey rigorously, and a couple other tricks, yes, it was possible that he would have obtained the same data. Perhaps even better data, if his eyes were sharper, for example.
I've just never met a kid actually doing that, during the five snowless seasons when I browsed the countryside. Because however safe and simple it is, there needs to be a level of autonomy and self-sufficiency one has to attain before anybody would let a kid out on her own. The implicit assumption is that she won't fall down with sunstroke miles away from "civilisation", without a phone, a map, or even an ID.
Also, she has to have some credibility, to stand by her counts when challenged. Unfortunately, orchids and most other protected species become a bone of contention when somebody wants to build something in the described habitat. And that somebody is going to have money, and will go to court if need be... and it is so easy to stop being a student when one's Head of Department finds this a more convenient resolution... This is the second assumption: the person who counted the plants doesn't just go through the motions, she knows full well and accepts the responsibility for her data.
And the third assumption is - at the end of the day, teach someone else. It is the hardest and probably least enforced custom, but a job, generally, isn't about "you", and it needs to be done even after it stops being "your" ideal fit. One day, a supersmart Seventh-Form Kid is going to knock on the door, and "you" will have dote on The Kid and kick back Dogs, Tourists, Gatherers, whatever, and answer (perhaps to the official officials) for every word The Kid spelled wrong. I don't know how it is in programming, but in plant research delegating is really hard. So don't you ever go into the field if you think it's all about learning how the species look and little else.
And now - what assumptions do you implicitly when you tell someone to learn to code? What does it take to be a programmer, not just to become one? (Same to other professions.)