Everything I googled in a week as a professional software engineer • Hacker News Board

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

#361

Post by grappler » Sat, Sep 07, 2019, 2:33 PM UTC

What has plagued me is not a notion that an experienced engineer needs to look stuff up, but a similar one that feels related: that as an experienced engineer I should be able to immediately incorporate a new thing I have no experience with, right then and there in a pairing session.

It comes in the form of "go ahead and install this thing, and throw this config value into it, and it should just work". And my reaction is "I want to read up on that thing first. I want to know what stuff it writes to my computer and where and what paradigms it uses. I want to think about how it will best integrate with the tools and workflows we have already. And then once I've done that, I'll probably be able to move forward with it comfortably. Then I'll want to document it so it becomes part of the regular setup others do when they onboard onto the project."

Just this past week when I said a version of this, I got a reaction like there is something wrong with me.

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

#362

Post by ihaveajob » Sat, Sep 07, 2019, 2:36 PM UTC

aloknnikhil wrote: post #7

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 read `ln -s A B` like "link A as B", and it tends to work with most Unix commands.

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

#363

Post by jplayer01 » Sat, Sep 07, 2019, 2:56 PM UTC

iforgotpassword wrote: post #76

aloknnikhil wrote: post #7

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.

There are some clever tips here how to remember. Ages ago I struggled too so for half a day I just kept repeating the words "ln target linkname" in my head. Anyone else?

I feel like a lot of this stuff is rote memorization that we shouldn't be so eager to demonize. The medical profession has you memorizing effectively random shit for years and that's fine. But in our industry, we think we should just magically remember stuff we enter once in a blue moon, and if not, who cares, just Google for it. It bothers me. And it's something I've increasingly turned to flash cards for. I'm tired of googling that command I used once 3 months ago but would be insanely useful right now.

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

#364

Post by jplayer01 » Sat, Sep 07, 2019, 2:58 PM UTC

inimino wrote: post #210

aloknnikhil wrote: post #7

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.

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.

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

#365

Post by iandanforth » Sat, Sep 07, 2019, 3:44 PM UTC

dpwm wrote: post #349

throwaway5d097 wrote: post #325

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

Same here. After adopting this approach, I haven't had to look it up since. The real question I have left: why is this so intuitive for cp, but completely counterintuitive for ln? I wonder if is because we think of how we would follow the link.

This. "I want something here that points to there" is how I always think about it. That's why "link" on my boxes is mapped to "ln -s" with the arguments swapped :)

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

#366

Post by hnarn » Sat, Sep 07, 2019, 3:58 PM UTC

throwaway5d097 wrote: post #325

aloknnikhil wrote: post #7

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

> 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 "destination" (which at least is the intuitive way to think about it for me, but I suppose it's individual), you actually end up with:

# cp [source] [destination]

# ln -s [destination] [source]

Where "source" is "the new thing that should be created".

Since I seem incapable of getting out of this way of thinking about sources and destinations, my rule of thumb is that when creating a symlink, you always decide where it should point first. Not intuitive perhaps, but this time I've made the mistake so many times it kinda sticks.

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

#367

Post by blackflame7000 » Sat, Sep 07, 2019, 4:06 PM UTC

levythe wrote: post #296

blackflame7000 wrote: post #281

Earlier quoted context omitted.

I am a big fan of the take-home problem. For example, Symantec once asked applicants to design a simple virus detector with wildcards (similar to grep) and then they gave interview spots to people with the best performance. During the actual interview, however, there wasn't much whiteboard coding only designing or "how would you do X" sort of questions.

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

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

#368

Post by martin-adams » Sat, Sep 07, 2019, 4:06 PM UTC

aloknnikhil wrote: post #7

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.

About 15 years ago a colleague of mine at IBM had the following on their board.

ln -s physical virtual

I never forgot it and can see it visually in my mind. You need something physical before you can virtualise it.

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

#369

Post by wool_gather » Sat, Sep 07, 2019, 4:19 PM UTC

lunchables wrote: post #137

abalone wrote: post #75

This 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 see it at least a couple times a week on sub-reddits related to software development. Junior devs who are convinced more senior developers are super-geniuses who know everything from memory.

Yeah, absolutely. Even more experienced folks sometimes get stuck on this. There's some selection/confirmation bias: you ask questions in chat or whatever, and there's someone who's got a lot of answers, and you're grateful and excited by the help. But you ignore all the time they were only partially right, or wrong, or -- most important! didn't even answer at all because they weren't familiar with the topic. (But someone else did answer, and also gets added to your mental "expert" list.) And of course you don't see all the things that they don't know or are struggling with. (Some of which could easily be things that seem simple and comfortable to you!)

I try to dissuade this kind of thinking when I see it: I like answering people's questions, and I take pride in knowing a lot of stuff. But there's way more stuff that I don't know than that I know. And I might need these folks' help with something I'm unfamiliar with, so I don't want them thinking they're "below" me and there's no way they could know something I don't. I'm sure they do!

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

#370

Post by rmsaksida » Sat, Sep 07, 2019, 4:49 PM UTC

throwaway5d097 wrote: post #325

aloknnikhil wrote: post #7

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

I do this as well, but it only works if I don't think about it. If I start thinking about it, I begin second guessing myself on whether I got it right and end up having to look it up.