Live data from Hacker News

Everything I googled in a week as a professional software engineer

localghost.dev

321–330 of 399 posts

Re: Everything I googled in a week as a professional software engineer

#321

This is a fun exercise, then ask the second question "How productive can I be in my job when the network is unavailable?" The author states : What I’m trying to show with all this is that you can do something 100 times but still not remember how to do it off the top of your head. My experience differs from this, if I were to rewrite it I would say something like: "You can do something 100 times, and as long as you ca…

Yes, there is value in memorizing things, as things in our memory are easier to work with for thinking than things we have to go out, search for, access, and then get into our memory. See for example Barbara Oakley's discussion on mathematical fluency:

nautil.us/issue/40/learning/how-i-rewired-my-brain-to-become-fluent-in-math-rp

Or Feynman on the need for mathematical fluency to do physics:

> What we have to do is to learn to differentiate like we know how much is 3 and 5, or how much is 5 times 7, because that kind of work is involved so often that it’s good not to be confounded by it. When you write something down, you should be able to immediately differentiate it without even thinking about it, and without making any mistakes. You’ll find you need to do this operation all the time—not only in physics, but in all the sciences. Therefore differentiation is like the arithmetic you had to learn before you could learn algebra.

> Incidentally, the same goes for algebra: there’s a lot of algebra. We are assuming that you can do algebra in your sleep, upside down, without making a mistake. We know it isn’t true, so you should also practice algebra: write yourself a lot of expressions, practice them, and don’t make any errors.

Of course, in this particular discussion re: javascript, I think the design of the language doesn't help much here. Consider Javascript's `Date`, which the OP calls out as an API with a particularly difficult to remember set of conventions. Authors of languages and libraries can remedy this by having a coherence in design, naming, and behavior that help people build mental structures to memorize how these work and achieve the kind of fluency they need to do things without googling. Ruby's standard library I think is particularly good at this(here "principle of least surprise" helps not just with discovery, but retention).

EDIT: also want to add that using documentation and external resources is totally valid, as the grandparent comment states. There's just a balance to be had between relying on Google versus what you can draw from your mind quickly. Also think it's worthwhile to note that there is interesting work to be done in making documentation systems better and more integrated into our runtimes, see for example: https://www.geoffreylitt.com/margin-notes/

Re: Everything I googled in a week as a professional software engineer

#322

On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.

If you google/duckduck go something more than once, I think it should be put into documentation. I have one central org file where I keep that majority of my one off questions about a tool, and these days I look there often first before man or info because I have condensed the information into something faster to parse for me.

Right now my main battle is deciding to port docs like this into asciddoc(tor) or keep them in org, both being exported to html5 eventually.

Re: Everything I googled in a week as a professional software engineer

#323

On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.

Hah, I thought I was the only one!

Re: Everything I googled in a week as a professional software engineer

#324

This is a fun exercise, then ask the second question "How productive can I be in my job when the network is unavailable?" The author states : What I’m trying to show with all this is that you can do something 100 times but still not remember how to do it off the top of your head. My experience differs from this, if I were to rewrite it I would say something like: "You can do something 100 times, and as long as you ca…

The easiest arguments to win are against the ones you invent

Re: Everything I googled in a week as a professional software engineer

#325

On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.

I think of it like `cp`. Source to destination, where destination is the soft link. so it's like copying a file somewhere but instead of a copy you're making a link

Re: Everything I googled in a week as a professional software engineer

#326

On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.

[deleted]

Re: Everything I googled in a week as a professional software engineer

#327
post #221

Earlier quoted context omitted.

Yes, it would be platform specific as the OSX ln command would not be the same program as the GNU coreutils ln program. For GNU ln at least I don't find it confusing at all particularly considering the only other option is LINK_NAME. I guess YMMV though and it seems kinda pointless to argue whether it is or is not confusing. Perhaps a poll could quantify it.

If "target" is used to mean two different things in the same context, it is going to confuse people! This is why naming things is hard!

In GNU coreutils ln help and man page it only ever uses TARGET to refer to the link target?

Re: Everything I googled in a week as a professional software engineer

#328
post #327

Earlier quoted context omitted.

If "target" is used to mean two different things in the same context, it is going to confuse people! This is why naming things is hard!

In GNU coreutils ln help and man page it only ever uses TARGET to refer to the link target?

I wasn't speaking specifically about GNU. Note though that even there you see a --target-directory, -t, -T flags that make literally no sense anymore once GNU reversed the meaning of the term.

Re: Everything I googled in a week as a professional software engineer

#329

On the list of things I always Google, is how to create a symbolic link under Linux. I just can't figure out a way to remember what comes first; the source or the destination. The man pages add to the confusion by calling the "source" the target. So, the rule of thumb I now follow is cp or mv semantics.

In the old days there was just 'man ln'

Re: Everything I googled in a week as a professional software engineer

#330
post #9

Earlier quoted context omitted.

ul = countable items in arbitrary order ol = countable items in a pertinent sequence dl = key value pairs table = a matrix of three or more keys and values

More mnemonically, ul = Unordered List ol = Ordered List dl = Definition List Definition List is the only description not immediately obvious, but understanding a definition as a key/value pair clears things up and isn't hard to remember.

Those are the names of the elements for sure...
Post reply on HN