loading...
Cover image for Stating The "Obvious"

Stating The "Obvious"

codemouse92 profile image Jason C. McDonald ・1 min read

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?

Discussion

pic
Editor guide
Collapse
ben profile image
Ben Halpern

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.

Collapse
dvanherten profile image
Dave van Herten

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.

Collapse
damcosset profile image
Damien Cosset

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

Collapse
codemouse92 profile image
Jason C. McDonald Author

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 (.a on UNIX, .lib on 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.)

Collapse
ben profile image
Ben Halpern

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.

Collapse
kspeakman profile image
Kasey Speakman

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.

Collapse
nektro profile image
Meghan (she/her)

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 --apache and 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.

Collapse
codemouse92 profile image
Jason C. McDonald Author

Sorry for a second comment, but this is another thing I wish someone would tell newbies using Python: DON'T SUDO PIP!

Screwing Up System Dependencies With Pip

Collapse
hamdouni profile image
Brahim Hamdouni

Can we start with acronysms ? Or are RTFM and LMGTFY more than "obvious" ?

Collapse
codemouse92 profile image
Jason C. McDonald Author

Good catch, ha ha.

  • RTM = Read the Manual (assume the F)...
  • LMGTFY = Let Me Google That For You
Collapse
stevekennedy profile image
Steve Kennedy

Naming Things. "Call things what they are" is way too subjective.