Live data from Hacker News

Everything I googled in a week as a professional software engineer

localghost.dev

371–380 of 399 posts

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

#371

Earlier quoted context omitted.

Reading the man page instead of Googling this will make you a better engineer, and it will also cost more of your time while you figure out what the man page is trying to say. This knowledge may save you time later, if you use it again, or not. So the advice I would give is, never Google if the answer can be found in the man page. Unless it's a tool you're unlikely to ever use again, of course.

Man pages are so insufferably long and mostly irrelevant though. It's come up on HN before, I think, how if you're ever looking for anything specific like commonly used arguments and common usages, it's a complete waste of time to go through an entire man page.

Except that, if you think about it, every sentence in a well-written man page was put there by an absolute expert in the tool who thought you might need to know it. If you want to master your tools, it's absolutely not a waste of time to read the friendly manual. When you use a system professionally every day and refuse to read the manuals because it takes too long, and you're in way too much of a hurry, you're only hurting yourself in the long run.

You're probably going to notice the time you spend reading man pages, when you just! want! to! get! something! done! And that's frustrating. What you're less likely to notice is the next five times you reach for the wrong tool, or have to go hunting around for some bubble-gum-and-twine way to do something, because you didn't previously read the man page that tells you exactly what you needed to know to do it easily and correctly.

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

#373

Earlier quoted context omitted.

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

It's also how one should remember it, instead of the definitions you provided. It's mnemonically designed.

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

#374

Earlier quoted context omitted.

> A work sample test, structured interview, or IQ test (alone or in combination) would be a much better filtering process. I'm not sure what any of these mean in concrete terms. Is an IQ test like those "why are manhole covers round" Microsoft questions of yore? Yuck. Is a work sample a homework test? That takes more time for both parties. It's not a good substitute for a 1 hour first round screen. And what's a "stru…

You should probably look up what an IQ test involves instead of just guessingly blindly, getting it wrong and then writing off the suggestion based on a wrong assumption.

Is stratifying income based off of IQ any more than we already have something that would benefit society?

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

#375

Earlier quoted context omitted.

Companies don't care about artificially restricting hiring: they want developers to be as cheap as possible. The truth is, software engineering really quite hard, but that whiteboard interviews just happen to be a rather poor way of evaluating candidates. A work sample test, structured interview, or IQ test (alone or in combination) would be a much better filtering process.

> A work sample test, structured interview, or IQ test (alone or in combination) would be a much better filtering process. I'm not sure what any of these mean in concrete terms. Is an IQ test like those "why are manhole covers round" Microsoft questions of yore? Yuck. Is a work sample a homework test? That takes more time for both parties. It's not a good substitute for a 1 hour first round screen. And what's a "stru…

You have questions, and I have answers!

https://www.wired.com/2015/04/hire-like-google/

If you have more questions after reading that, then ask away.

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

#376
post #366

Earlier quoted context omitted.

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

> I think of it like `cp`. Source to destination, where destination is the soft link. That doesn't make sense to me. The way I think about cp is "copy this, and put it over here". If you think about symlinks that way, you mix it up. When you say "source to destination, where destination is the soft link", that makes it more confusing for me, because if you consider the symlink that is being created as the "destinatio…

If it was a hard link, I suppose my way of thinking about it would make more sense, since all hard links are as valid, pretty much the same. That is, after running

  ln /some/file /other/file
/some/file and /other/file are hard links. So in this case ln is just copying a hard link, while afaik cp would be copying data, making a hard link pointing to the new data. In userspace? That seems to be what's happening here - https://github.com/openbsd/src/blob/master/bin/cp/utils.c

This is made a bit more confusing by the differences in man pages. For GNU ln, it's shown as ln TARGET LINK_NAME, but for OpenBSD, ln source [target]. But the usage is pretty much the same?

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

#377

Earlier quoted context omitted.

Man pages are so insufferably long and mostly irrelevant though. It's come up on HN before, I think, how if you're ever looking for anything specific like commonly used arguments and common usages, it's a complete waste of time to go through an entire man page.

Except that, if you think about it, every sentence in a well-written man page was put there by an absolute expert in the tool who thought you might need to know it. If you want to master your tools, it's absolutely not a waste of time to read the friendly manual. When you use a system professionally every day and refuse to read the manuals because it takes too long, and you're in way too much of a hurry, you're only…

Well, no. Even if I read the damn thing, there are tens of tools I use day to day. I'm not going to remember any of it. It doesn't matter how much of an expert the author was if it's not structured in a useful way. And I've read enough fucking man pages. I've retained zero except for maybe what I ended up using. If I used it more than once. Maybe. Man pages don't tell you shit. They tell you everything and you still need to parse, interpret and analyze it because it's so ridiculously dense and there's never any guidance on actual real-world usage. Theoretically they're useful, realistically, they completely ignore everything about how human beings function. They're not written for people.

Hell, I often find that while the author has managed to cram everything and the kitchen sink into it, there's so much missing from it regarding how a tool works, caveats, whatever. All these things that are crucial to actually understanding the tools you're using beyond what some flag or other does on a surface level.

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

#378
post #366

Earlier quoted context omitted.

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

> I think of it like `cp`. Source to destination, where destination is the soft link. That doesn't make sense to me. The way I think about cp is "copy this, and put it over here". If you think about symlinks that way, you mix it up. When you say "source to destination, where destination is the soft link", that makes it more confusing for me, because if you consider the symlink that is being created as the "destinatio…

how about like this:

# cp [existing-thing] [new-thing]

# mv [existing-thing] [new-thing]

# ln -s [existing-thing] [new-thing]

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

#379

Do yourself a favor and set up browser shortcuts. In Chrome, for example, you can add custom search engines. If you set the search URL to: https://google.com/search?q=site:docs.python.org/3+%s&btnI (That last character is a capital "eye"/I, for "I'm".) It does a Google "I'm Feeling Lucky" search for your query, and restricts the results to the Python docs. So, e.g., I can type: py enum And get the Python docs for the…

You can set up that MDN shortcut easily using the website https://mdn.io/, which does nothing but redirect to an I’m Feeling Lucky Google Search like you described. In your keyword bookmark (Firefox) or custom search engine (Chrome), just use the URL pattern “https://mdn.io/%s”. I titled my bookmark “Search MDN via mdn.io” and gave it the keyword “mdn”, same as deathanatos.

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

#380

I use dash to keep all of the reference material for libraries and programming languages I use stored locally. It has cut my searches down to almost nothing. IMO, it is better to use the reference material, because it forces you to understand the mechanisms involved and solve the problem yourself vs looking up a solution. This act helps imprint the knowledge into your long term memory. Of course, this is my anecdotal…

For anyone wondering what Dash is, it’s an API documentation browser macOS app. It works offline and has fuzzy search that shows results as you type. You can get it at https://kapeli.com/dash. The full version costs $30.

https://devdocs.io/ is a free alternative. It’s a web app that can be set up to work offline. It was missing a few convenient features of Dash last time I checked, but I can’t remember which features those are right now.

Post reply on HN