But seems like the trend of the last 10 years is to rewrite every single already existing Unix tool in Rust or node.js. Throwing out code is more fun than reading man pages I guess.
This saddens me. It looks like the average dev in 2020 believes he needs to pollute his working environment with thousands of seemingly useless tools to be productive.
fzf, silver searcher, ripgrep, etc.
I will be downvoted to hell, because these people genuinely believe they need these tools, and will find whatever performance or feature argument to explain why. But from my experience, I am much faster at any command line task than pretty much anyone using these fancy stuff, even though I stick to bash, vim, and coreutils...
The standard tools have a lot of cruft. `grep` being case sensitive by default is I think a good example of a default that used to make sense, but is probably better the other way around today. There are countless other such examples.
Your comment reads as a no-true-scottsman "look how skilled I am" signaling device. You're not necessarily wrong, but you're also clearly fighting a pointless battle, and sound a bit out-of-touch.
Yes, the tools already exist and work. No, they do not need to be re-written, but the new versions are often substantially more usable and newcomers enjoy that. Such is the nature of life. Things change. Accept that and you'll be happier.
Your attitude might win some points with other fight-the-tide-till-my-last-dying-breath types, but it reads to me as "It is the children who are wrong!"
I worked with a guy who had the same attitude about always using kubectl over the gui because it was "faster". He was demonstrably slower at quite a few common tasks, like discovering errors in logs across many pods, than others who used the gui.
Yes it looks much nicer imo. One thing that annoys me with ctrl-r is that if you make a typo and backspace it, you will not be back to where you were. The "cursor" has moved back in history, potentially past the command you were interested in. It's also nice you can see many different matches at the same time.
I kind of think the author should have foreseen this question and provided an answer.
You should see my git aliases that makes heavy use of fzf. It definitely speeds me up. `ga` gives an fzf-powered selection only on files in my git status to `git add`. I can cherry pick commits without ever typing a branch or commit hash. Fuzzy-find on reverse search with fzf is way better than the built-in ctrl+r. ripgrep is way better than grep. I could go on.
I appreciate your call to be familiar with the core unix experience, but the unix userland is definitely enriched by these newfangled tools.
You’ve just picked an arbitrary point in the development of these tools that you’re happy with and are suggesting that any progress beyond that point is wasted. I’m sure there were folks around when bash development started saying that they were super productive in Bourne shell so why start a rewrite from scratch. Is vim the terminal point of editor development, forever? Why wasn’t it when nvi replaced Joy’s original vi? Why aren’t we still using ex?
All of the tools you mentioned started as rewrites of existing tools and only became better over time as they added features. That process hasn’t stopped.
And it automatically ignores the directories like .git, build, node_modules, etc., whatever is in .gitignore, without having to add a bunch of "-prune" clauses.
I can easily give examples of using `fzf` or `ripgrep` to perform the same action in many less keystrokes than the built-in utilities would require, e.g., traversing a deep directory hierarchy using `fzf` to fuzzy search for the right directory to `cd` to, or performing a text search of only `git` included files over many repos.
Given these tasks are accomplishable in many less keystrokes using `rg` and `fzf` than the built-in utilities, how would you make the argument that you're able to accomplish these command line tasks faster using only "bash, vim, and coreutils"?
Roughly $350/mo at this point, and I’d love to 10x it this coming year.
I have an Etsy business that I set up last year that doesn’t require much input from me and uses third party fulfillment. I average about 30 sales per month including the holiday season and about $10/order profit.
Dividend stocks currently pay around $50/mo, which buys more stock every time (DRIP), so that should increase nicely over the next 30-40 years. I also buy more on a regular basis, but that does take some effort/research on my part.
I’ll leave out stock, bond and mutual fund growth on its own since that’s not really income per se.
I’m also working on a YouTube channel that I just started last month. It doesn’t even have 10 subscribers but I do point people to product recommendations, which has already gotten me a $45 referral payout. Could be a fluke, but I’m in it for the long term, so we shall see.
> Think about all the possibilities if everyone can go learn whatever their heart desires without worrying about paying something back?
They can do that online and or in a library. Once you start paying someone to teach them, it starts costing money and that money has to come from somewhere.
Most of these are agreeable enough. "Unconscious bias training" seems like a bit of a stretch, but I haven't taken it to know whether it's helpful. 2, 3, 4, 6 are fair, I'd say.
> 5. Consider salary transparency
This is a double-edged sword. While good for some things, it is not without cost. For instance, seeing a top performer's pay can be motivating for some and demotivating to others. And others' performance isn't always immediately clear so it may be that other workers don't see higher pay as 'just,' which will cause them to devalue their own work because, "what's the point?"
To resolve this, you can flatten pay but then you remove the incentive to perform well. You can separate people at different paygrades into different physical locations, but now you're segregating performance groups while harming overall open communication.
> 8. Don’t force female coders behave like men to be successful
I'd say success is acting like a good coder -- regardless of gender -- just like it says in the conclusion:
> “Overall, to become a female developer, you only have to do what any other smart dev would do. Spend weekends and late nights in front of your computer, laying down lines of code, debugging and developing your personal projects. Follow tutorials, read articles, and learn on the fly. Master the lingo. And, if you are curious enough to go deep down to the core of what you are trying to build, you will need to acquire a large and useful understanding of computer science. In a nutshell, spend time to learn all you can.”
I don't see a lot of places discussing the concept of trial hiring (i.e. giving someone fair pay for actual work to skip the bias inherent in interviewing and judging them based on some preset metrics). I feel like this would get around the problems highlighted in this study: http://blog.interviewing.io/we-built-voice-modulation-to-mas.... At my company, we use trial hires and we have a lot more women involved as a result.
Right, and I get that your counterpoint is against the person above you. However, that doesn't change the context of Damore's argument, which is saying that interests may differ due to differences in cognitive ability and that the difference may help to explain the gender gap.
And a lot people are ignoring the context, instead pulling straw men out of the text to fight, rather than arguing the substance of the memo itself, context included.
It's a great read and the sort of lead-out at the end yields some more useful insight:
> Prior art aside, I would like to leave off on a high note. I mentioned earlier that men are doing a lot better on the platform than women, but here’s the startling thing. Once you factor out interview data from both men and women who quit after one or two bad interviews, the disparity goes away entirely. So while the attrition numbers aren’t great, I’m massively encouraged by the fact that at least in these findings, it’s not about systemic bias against women or women being bad at computers or whatever. Rather, it’s about women being bad at dusting themselves off after failing, which, despite everything, is probably a lot easier to fix.
To me this is more useful than "women are less interested in tech on average," or "there's a hiring bias in favor of men over women."
It's also not just about self confidence and "dusting yourself off", but about being immersed in the field and understanding how the process works. If you're a CS major, and all your friends are CS majors, you've heard everything there is to know about the interview process, you know it's normal to bomb one or two, it takes some practice, maybe you borrow someone's copy of Cracking the Coding Interview to get better, etc.
But if you come from outside that culture, and you don't have many friends in the industry, you might bomb one algorithms and data structures interview and think "wow I guess I'm not cut out for this". The only reason I didn't think that after my first interview was because I knew so many people who had been through it before me.
It might be easier to frame the problem as "how can we reach people outside our circle" rather than "how can we reach more women", even if it amounts to the same thing.
> His reaching out to alt-right media and having a "Goolag" shirt on the very first interview suggests that he was kind of ready for it.
Which alt-right media did he reach out to? I've been paying pretty close attention and I saw him being interviewed by the likes of Jordan Peterson and Ben Shapiro, but they are not alt-right media. They are both classical conservatives.
> As anyone who's worked for Google (I have) will tell you, that's highly discouraged. You don't want to put Google or yourself into a weird legal position for posting publicly about this (for example, Google would have to track you down and make sure to archive all your internal emails moving forward for possible discovery, etc.)
Then all we have to go on are theories and the question: what's to be gained from him lying about this?
His very first interview was with Stefan Molyneaux, a self-described "fighter for men's rights" (yeah, I know.)
> what's to be gained from him lying about this?
I don't think he was outright lying, I think he was just uninformed and made a lot of assumptions and drew
conclusions (biased by his own political views) out of those assumptions. I do think his inflammatory approach to accusing Google and Googlers of "leftist bias" was a way to get attention.
About what's to be gained? Well... he's been interviewed by the New York Times and he'll probably get a book deal out of it, plus whatever money he might get if he manages to successfully sue Google.
I've been told that his first interview was actually with Jordan Peterson. The Stefan interview with simply the first to be published maybe, or widely seen.
