Live data from Hacker News

Everything I googled in a week as a professional software engineer

localghost.dev

391–399 of 399 posts

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

#391

Earlier quoted context omitted.

Reading, interpreting, and using dense technical documentation is a skill, just like reading maths. If you don't get anything out of it, maybe this is a skill you are presently lacking and something you should improve. Taking notes on what you are doing and reviewing your initial guesses, resources consulted, and eventual solutions may help you consolidate this ad-hoc knowledge into understanding. I've read many man…

You're insufferable like every other Linux elitist out there. You realize being polite while being an arrogant prick doesn't change how much of an asshole you are being? I hate this kind of bullshit and I'm tired of it. And I'll get warned because I'm the one getting mad over it. Fuck this shit.

I know it sucks when your environment sucks and your tools suck and people tell you your habits suck too. I can tell you're frustrated by your tone in this thread even before I told you that you may lack the skill of slowing down enough to read technical documentation. So, you're right. I'm telling you to be better and try harder, and I don't even know your situation! Maybe that does make me an asshole. Certainly most people higher on "agreeableness" than I am wouldn't say those mean things.

By the way: I might be a Linux elitist, but nobody's ever called me that. I use OS X in my day job. I've been programming in some capacity for about 30 years. Your mileage may vary. If you take my advice you may hate me for it, but it will almost certainly make you a better developer in the long run. And I don't mind if you think I'm an asshole. I know I'm right, and you probably know I'm right too.

Finally, if we weren't having this interaction in public, I'd be kinder, gentler, and might not say anything at all. But if one other person who hates reading difficult technical material is pushed to overcome that limitation by reading this thread, it's worth it, even if it means making you mad.

And just in case you're still reading, in addition to reading man pages, and taking notes, here are the other things you should be doing:

Preferring textbooks over blog posts and youtube videos to learn a new field.

Reading original research by pioneers in the field, like Turing, Shannon, etc, rather than their main findings rehashed by lesser minds.

Reading source code rather than jumping from documentation to Stack Overflow when something doesn't work.

Reading Knuth on algorithms, Stevens on Unix networking, etc. In other words, read the classics that everyone says you should read but most people don't. Work through the exercises. It's the closest thing to an actual superpower.

Look around for people better than you at all this stuff to help you improve.

Good luck!

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

#392

Earlier quoted context omitted.

could you give an example of a complex search? I've never bothered using advanced Google search patterns

I personally just use "site", "inurl" and the minus sign. Example: site:news.ycombinator.com -inurl:item google operators

I use "inurl:ycombinator", saves even more time when typing manually.

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

#393

Earlier quoted context omitted.

Ha! My trick is to ln -s a b then look at the link with ls -l, then remove my garbage! Your way is much better.

I just do it the one way, get the error that the destination already exists, then swap them.

Except if b is a directory, then ln -s a b will create a symlink at b/a which points to a.

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

#394

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 'ln' as a tool which creates a symlink. And symlink is a new object, a new kind-of file. So it must be the last argument. The source is just an attribute of that symlink "file" holding the path it points to. If I want to overwrite an existing symlink "file", I simply add -f meaning force-overwrite-if-the-symlink-file-already-exists.

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

#395

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 love the man replacement packages like tldr, bro, etc. for exactly these kinds of simple, yet easy to forget incantations.

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

#396
Funny, I don't do that many web search for my job (must have searched two different things this month). Beyond a mix of reasons (a bunch of third-party docs that aren't public, build systems that are developed in house (based of ant) and existing internals documentation), I wonder what it means about me and the software (vanilla Java, vanilla JS) I'm working on.

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

#397

Earlier quoted context omitted.

could you give an example of a complex search? I've never bothered using advanced Google search patterns

I personally just use "site", "inurl" and the minus sign. Example: site:news.ycombinator.com -inurl:item google operators

you could also do:

site:news.ycombinator.com -site:news.ycombinator.com/item

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

#399

Earlier quoted context omitted.

There's a small list of companies I'd do a, "Take home test," for. In my experience, most companies that ask for it are looking for free labor.

Well if they are good enough for you to put their code into your program then shouldn't they be good enough to be offered a job? Seems like it works exactly as intended in terms of trying to find someone who can do the job

I've had multiple take home tests result in changes to the products that company offers. I've never received a job offer from those companies. Maybe your experience differs, but I've had a sour taste left by such practice.
Post reply on HN