We've all slammed head-long into this scenario: we need to learn how to do something, and by asking, we are told, usually condescendingly, that everyone knows how to do it, and RT(F)M and LMGTFY. Yet, when we look it up, no one has ever written up a guide because "everyone knows how to do that."
So, we eventually just hack and stumble our way through the non-obvious stuff, feeling like idiots for not being born with this innate knowledge that everyone else seems to have.
And then, as we achieve that knowledge, we realize, the "everyone knows" is just imposter-syndrome-driven smokescreening.
So, let's help cut the cycle here! What is ONE thing in computer programming or IT that is generally considered obvious, but actually isn't? What do you wish someone would have told you about that subject back when you learned it?
Top comments (11)
You can catch up with the trend later. When I was newer to professional software development, I was concerned about being on the cutting edge a little too much. If something was becoming popular, I was worried about missing the boat. I have come to realize that as I generally stay interested, curious, and willing to improve on my fundamentals, I gain the skills to jump on the trends if I really want to. I no longer have a feeling of obligations.
I say trends because that tends, but this can be generalized to non-trendy things. There are older languages, concepts, systems, etc. that I am super ignorant of, but I'm pretty confident that I could get involved in those areas if I immersed myself, but I can live with some ignorance if I'm not involved because there's plenty I do know.
I think it's good to keep up with what's going on, but you don't need to learn everything. This is obvious to me now but I was just talking to a slightly more junior developer who had the same concerns as I did about keeping up with trends. Stay curious and keep an eye on things, but there's no pressure with following trends as long as you keep improving on the fundamentals.
So true. You don't need to know everything about every new thing, but I'll echo it is important to know that things are out there by keeping tabs on topics in general. I just try to pay enough attention about what's out there so that if I come across a new problem I know enough to look into something deeper. If I don't know it even exists then I can't do that, but I certainly don't need to know everything about it right away. :)
Honestly, the Dev.To feed helps with that for me. If I start seeing the same topic coming up day after day I can add it to the list of things I might want to know a little bit more about.
This! So much this! I still fall for this sometimes. I wanted to learn about Elm, and machine learning and what about that thing, and this one??
Then, I started to realise that I was only scratching the surface on every single subject I ever learned. So, focus on fewer things and catch up later. I mean, machine learning is not going anywhere anyway. And we all caught up on some subject at one point.
The fact that programming offers so much is amazing, but it can also be extremely distracting
Makefiles and build scripts aren't magic. Yes, all the building guides would have us believe that they are, but there's a lot more going on. You must have the tools to build (i.e. compilers, interpreters, etc.) The nastiest part is usually the dependencies. You have to make sure that you have all of the necessary pieces of code (libraries) installed on your machine.
This varies from language to language - Python, PHP, JS, Rust, and many other such languages let you install many libraries using a special command. (See the documentation for "installing libraries" and "installing dependencies").
By and away, if you're building from source, you're most likely using C, C++, or some other cousin language thereof. Dependencies there are nastier. Static libraries are the easier ones, but you have to include the header files (
.h, .hpp,.hxx) for the library in your compiler, and the static library files (.aon UNIX,.libon Windows) have to be added to both your compiler and linker. Dynamic libraries (.dll) are similar, but often more complex - look those up.On UNIX (Linux, Mac) systems, many dependencies are easier to handle, as you can just install them via your package manager. If they're NOT available through your package manager, you'll need to track 'em down yourself
Whatever you're building SHOULD have documentation on what dependencies are needed, where they're expected to be, and so forth. If what you're building doesn't have this written down, think again whether you want that code. (Good projects should always document their build process.)
I took a different approach with my answer, but the x isn't actually magic thing is super generally applicable. It took me a long time to realize that if I was confused about how a dependency worked, I can look at its code and maybe find my answer right there! This doesn't always apply, as somethings are closed source or potentially so convoluted that they might as well be magic, but in my line of work I often find answers right in the code I'm depending on.
Here's a post on reading tests to find answers which touches on this thought.
I just had a moment so dumb I had to come on and post this. So I have a sever I setup in my basement to route from a subdomain on my website. I had port forwarded 80 and used an .htaccess rewrite to even make sure IP based requests were using the domain name instead. Now here comes my obvious moment. I then wanted to add SSL to the server and bless the people over at Let's Encrypt for making this so easy. I tried running their basic setup command
certbot --apacheand it failed. Over and over complaining about how it couldn't reach the server. I thought maybe the CNAME isn't working properly so I went onto TOR and went to my domain and the page loads. I couldn't figure it out. Then it hit me.I hadn't port forwarded
443. Then I ran the setup again and it ran flawlessly.When I started learning functional programming, most of the tutorials I read focused on patterns and syntaxes (or worse, category theory). They didn't emphasize that the value of FP (and therefore what I should focus on) is writing pure functions wherever possible. All those patterns are just there to support that. When you just try to use the patterns without the right goal, the benefits do not really materialize.
Sorry for a second comment, but this is another thing I wish someone would tell newbies using Python: DON'T
SUDO PIP!Can we start with acronysms ? Or are RTFM and LMGTFY more than "obvious" ?
Good catch, ha ha.
Naming Things. "Call things what they are" is way too subjective.