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.
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.)