Longer I work as a developer less frequently I google stuff. Most times I use google to find a project on Github and read docs. If I google for something specific then it is for finding better solution.
Everything I googled in a week as a professional software engineer
191–200 of 399 posts
Re: Everything I googled in a week as a professional software engineer
#192I often search for "X sucks" to see if others agree with me that X indeed sucks.
I sometimes do that if I'm learning X and like it. I will probably disagree with an "X sucks" article, but if it's well written, it will teach me about some pitfalls of X.
Re: Everything I googled in a week as a professional software engineer
#193Earlier quoted context omitted.
Because Yahoo isn't a search engine; the results are powered by another search engine (at this time, Bing)
The definition of what is a search engine doesn’t change based of its internal implementation (here, Bing).
Sure, maybe a better term is "virtual search engine" (in the sense the Mobile Virtual Network Operators are just mobile service resellers)
Re: Everything I googled in a week as a professional software engineer
#194Earlier quoted context omitted.
Because Yahoo isn't a search engine; the results are powered by another search engine (at this time, Bing)
Bing gets their results from other search engines too. https://www.wired.com/2011/02/bing-copies-google/ As far as I can just about every search engine uses results from Google directly or indirectly by using a source like Bing that in turn gets some of their results from Google. If you won't call something a search engine unless it doesn't use anyone else's search results you might have a hard time naming more than…
Perhaps, though I suspect much has changed in the 8+ years since that article was written.
Re: Everything I googled in a week as a professional software engineer
#195On 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.
Here's how I finally memorized it: ln has a 1-file-argument invocation, so ln -s ../../a_fine_file will create a symbolic link to that file under the current directory and under the "a_fine_file" file name. The single argument case has to have the file you want to link to as input. That generalizes nicely as the 2-file-argument invocation maintaining the logic.
and now I've just memorized it myself. Thanks!
Re: Everything I googled in a week as a professional software engineer
#196Google-fu is pretty much a requisite for any engineer (and I'm not just talking software).
Re: Everything I googled in a week as a professional software engineer
#197Earlier quoted context omitted.
> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” I've met lots of younger devs who have varying degrees of impostor syndrome, so anecdotes like this probably help people like that feel less bad about not knowing everything.
I'm of the opinion that not googling stuff means you're not a proper engineer. And from what I've seen, those who don't google consistently also fail to understand the answers they find when they do google things. It is, in fact, an essential skill.
I’ve asked pre-internet programmers and they said they used to keep reference books at their desk or even a small library/book room at their employers.
I’ve heard some government contractors can’t google because they work on non-internet connected computers. They probably keep a lot of books.
Re: Everything I googled in a week as a professional software engineer
#198Earlier quoted context omitted.
Isn't that what a whiteboard interview is? Proving you can do things without google or else you aren't a proper engineer? (For the record I disdain whiteboard interviews as the accepted metric for testing one's ability)
IMO it's not. I've never given or taken a whiteboard interview where the I (or the candidate) was not allowed to either google things or to make assumptions about how certain things worked. For example, if your solution involved generating all permutations of a sequence, and you didn't remember how to do that efficiently, I would let you make up a black box function that just does it. We might come back to this later…
> if your solution involved generating all permutations of a sequence, and you didn't remember how to do that efficiently, I would let you make up a black box function that just does it
But sometimes, the interview question is generating all the permutations :(
Re: Everything I googled in a week as a professional software engineer
#199On 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.
What came first: the file or the symlink? Of course the real file came first! Mnemnic that helps me: IN SYMLINKS, REAL FIRST! ln -s REAL_FILE link_name
Two minor points: They are both real files. The symlink may be created first.
"Source" and "target" are confusing names because the target of the ln command is the file it creates, which is the symlink that points to the source file, which is the "target" of the symlink in an intuitive sense. The mnemonic works because it matches mv and in that case the file that exists must obviously come first. In ln without -s the file also must exist, which makes perfect sense. So it's easy enough to remember if you understand what the ln semantics are and don't get hung up by the source and target jargon.
Re: Everything I googled in a week as a professional software engineer
#200[deleted]