Live data from Hacker News

Everything I googled in a week as a professional software engineer

localghost.dev

381–390 of 399 posts

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

#381

I recommend every software engineer download/purchase Dash ( https://kapeli.com/dash ). It’s worth more than whatever that I paid for it (probably like $50, I think). That app is a lifesaver; especially when I’m offline for a bit and trying to work

I agree, Dash is extremely useful. You forgot to describe what it is, so for anyone who is wondering: Dash is an API documentation browser macOS app. It works offline and has fuzzy search that shows results as you type.

Dash currently costs $30. For anyone who doesn’t want to commit to that, you can also try https://devdocs.io/, a free web app alternative with fewer features. DevDocs can even work offline, like Dash does.

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

#383

Earlier quoted context omitted.

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…

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 pages, many many times, and if I get nothing out of it, I find it is invariably because I am in a hurry, and I'm probably about to fuck something up. The thing to do is usually to slow down and do it right. Only rarely is the right thing to ask someone else for the solution, or see what some other poorly-informed person on the internet thought, although in an emergency asking for help is almost always the right call.

A huge amount of what man pages don't tell you is general Unix philosophy. Man pages don't tell you the lore around the thing, they describe the implementation. It's up to you to infer the consequences and how it can be used. Man pages don't hide the underlying bones of the system either, and generally assume you're comfortable writing a C program to test a syscall if you're not sure about something. So sure, reading man pages isn't always easy, but neither is getting regular exercise or eating your vegetables.

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

#384

Earlier quoted context omitted.

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?

in sofar as IQ helps predict actual job performance, I'd say yes.

Now I'm not saying the situation isn't complicated. In the mid-20th century, IQ testing was a great driver of social mobility. However, as was pointed out in _The Bell Curve_, it's becoming the opposite. From what I understand, the heritability of IQ and assortative mating (i.e. people marrying other people of similar IQ/educational attainment) are the main drivers of this.

I don't think the formation of an entrenched class system is necessarily a good thing, but I think in the local context of our industry there's still a lot of good that could be done by improving our hiring process. I mean, would you rather hire people who only sound smart, or who are smart?

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

#385

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.

Thinking like this, it fits the pattern of other coreutils tools:

    $ mv existing_path new_path
    $ cp existing_path new_path
    $ ln existing_path new_path

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

#386

Earlier quoted context omitted.

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…

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.

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

#387
post #334

Earlier quoted context omitted.

Network latency is an issue then. The word list is going to lag behind keystrokes. Also, doesn't work offline.

If you assume your corpus fits in the same instance (since you mention offline), you can run a single node elasticsearch on the same instance as well.

No, you can't run elasticsearch offline on a web client.

Look, we can keep going back and forth and maybe you'll dig up some javascript library that implements a search. And that's fine, I believe there are "maker" roles that largely are about gluing things together and translating requirements into code and shouldn't require screening for CS fundamentals. But at some point it gets a little hacky and suboptimal if you lack a good practical grasp of computer science.

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

#388

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 reactio…

This comment makes me want to work with you.

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

#389

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.

The best way to remember it is that only the first argument is mandatory.

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

#390

Earlier quoted context omitted.

> But having a deep understanding of data structures (not just arrays and maps) and algorithms really gives you a mastery of your craft, especially around performance and scalability. Can you give an example?

Ok.. Find all the words that match a search string prefix. I.e. you have a search field and want to show the possible matches as you type. With each new char you’re calling this search and getting back a list of words. The dictionary is in memory in whatever data structure you choose. You only have to return matches if the search is 3 or more chars long. Now, how does your implementation scale when the dictionary has…

Prefix tree is the right answer here right? From an interview standpoint.

But my question is: why would you want to roll your own here? Wouldn’t the appropriate move be to look for solutions for your specific use case that’ve already been made? Ie if you’re talking web, I see no reason why a standard database index would work. MySQL’s index, a b-tree, is perfectly serviceable for the question, no? I’m having trouble imaging a situation where an out of the box solution wouldn’t work...

I don’t think I have a deep understanding of efficient data structures. I couldn’t re-implement a red black tree for example without looking it up. I wonder: is it enough to have a cursory understanding of things like runtime complexity, space complexity; understand the different basic data structures and how they have trade offs that can help or hinder different operations, and how that connects to real world work. Especially how different actual solutions use different data structures internally. What I don’t understand is the value from going from cursory understanding of data structures to deep understanding.

Post reply on HN