no porn queries tho?
Everything I googled in a week as a professional software engineer
121–130 of 399 posts
Re: Everything I googled in a week as a professional software engineer
#122Re: Everything I googled in a week as a professional software engineer
#123Given the amount of documentation the average developer consumes, it seems odd that some of them do not think their stuff needs any.
Re: Everything I googled in a week as a professional software engineer
#124This is great but the premise seems kind of straw man. I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Perhaps this is a reference to the interviewing process. Tests are a different thing, though. I’ve been on practical technical screens where you can google, because the test was about building a larger system, and they don’t care if you don’t remember this or that API…
> 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.
Re: Everything I googled in a week as a professional software engineer
#125On 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'm the same way with scp, I never remember the order and then it changes if you're uploading or downloading. Also, an obligatory xkcd: https://xkcd.com/1168/
I find scp really easy. rsync, on the other hand, is like tar to me.
Re: Everything I googled in a week as a professional software engineer
#126On 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'm the same way with scp, I never remember the order and then it changes if you're uploading or downloading. Also, an obligatory xkcd: https://xkcd.com/1168/
Easy way to remember extracting with tar is "eXtract Zee Files" -xzf.
Re: Everything I googled in a week as a professional software engineer
#127On 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.
Yup, exactly. I always use the form:
ln -s ../../a_fine_file .
Re: Everything I googled in a week as a professional software engineer
#128This is great but the premise seems kind of straw man. I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Perhaps this is a reference to the interviewing process. Tests are a different thing, though. I’ve been on practical technical screens where you can google, because the test was about building a larger system, and they don’t care if you don’t remember this or that API…
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)
A good whiteboard interview doesn't require much outside of basic syntax/data structures, and will offer some form of help along the way (often in the form of a somewhat helpful interviewer).
Re: Everything I googled in a week as a professional software engineer
#129On 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.
It finally clicked with me when I read about it as ln -s real fake
Real is always better than fake, real comes first.
Re: Everything I googled in a week as a professional software engineer
#130This is great but the premise seems kind of straw man. I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Perhaps this is a reference to the interviewing process. Tests are a different thing, though. I’ve been on practical technical screens where you can google, because the test was about building a larger system, and they don’t care if you don’t remember this or that API…
> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Yes the whole interview process is based on the idea of doing stuff for the company that you wouldn't actually do. Indeed I interview my candidate's ability to find resources, to know what considerations are needed, how to deal with IDEs, collaborative tools, the git protocol. I will fire someone on the spot for impleme…
> the whole interview process is based on the idea of doing stuff for the company that you wouldn't actually do
The process for successful interviewing at places that use whiteboard testing for interviewing involves digging in and putting in a lot of hard work studying previously unknown concepts-- work that most people don't consider very fun.
To me, this sounds like exactly the kind of thing that a person will need to do to be successful in their first few months in a big company. Learning about their particular systems, authentication and authorization methods, security audit procedures, deployment methods, how they do dependency injection, logging, diagnostics, troubleshooting...