akdas

There's one more advantage to client side analytics, though maybe you meant to cover that under "Usually easier to setup": it's the only option if you host your site on a platform like Github pages. The problem is, you don't have access to server-side logs on these platforms.

> do you train you brain to remember the key positions so that it doesn't matter what character is printed on a key?

Yes.

> how do you _learn_ the layout then?

Using an image of the new layout, and by doing drills. If you care about touch typing, you're training to type without looking at the keyboard anyway.

This is how I learned to touch type on Dvorak years ago. I had never learned to touch type on QWERTY before, and I still can't. But then again, I typically don't type on other people's computers and when I do, I look at the keys.

That's partially because photos used to be rarer. So either the subjects were richer to have access to photos, or the subjects dressed their best when getting their photographs taken.

I don't think this discussion will be productive if different people have a different set of first principles they start with. In this case, I disagree that HN works extremely well. It works well, but there's still a fair amount of misogyny in my experience.

As the article and comments mention, writing forces you to understand your material really well. I'll offer another perspective: it's useful to approach topics from a less knowledgeable perspective.

The beginner's perspective exposes a lack of information on the topic, especially if the topic is usually covered only by experienced folks. It's also a great way to gather feedback from others who know more about the topic, aiding both you and anyone who reads the resulting discussion/follow ups.

The key is to be transparent with knowing about the topic and explicitly soliciting feedback in areas where you have low confidence. This is the part many armchair experts miss.

That's exactly how I started as well: documenting a project I was doing so the information I gathered was in one place. Just yesterday, I was writing a Makefile, and I referenced my own blog post on the topic to refresh my memory.

It really helps to have your own personal knowledge store, and writing in a way that can be published publicly helps me write clearly. Future me benefits and so do readers who I never expected would stumble onto on my writing.

HN has a form of a Code of Conduct (https://news.ycombinator.com/newsguidelines.html), and strong moderation to remove truly bad-faith comments. These two aspects are really important to the level of discourse here.

And while I would say HN is often times civil, I've definitely seen misogynistic or otherwise demeaning comments here.

It also barely touches on the harassment she encountered that caused her to withdraw from technology and her online presence. The reason that's relevant is I remember her blog fondly, and it's sad we lost someone who was so clearly invested in teaching others.

I hope we can learn from that lesson, though given the negative response I've seen to Codes of Conduct and the calling out of sexism within our industry, I can see growth being a very slow process.

This is a great point I hadn't considered. While I'm a generalist, when it comes to big company interviews, I'm definitely more on the backend side.

What kinds of uncommon scenarios and edge cases have you encountered in your experience? Are these questions trivia about specific frameworks and languages, or something else?

A lot of the big tech companies actually have processes around mentorship. It's one of the reasons I think working at a big tech company can be more valuable than at a small startup, especially early on in one's career.

I don't mean to suggest all startups forgo mentorship, but often, smaller startups simply don't have processes in place for most things, including mentorship. And of course, what you get mentored on depends on the company too: at a big company, the focus may be on growing your career, whereas the mentorship at a smaller company may be about navigating an uncertain product roadmap.

Unfortunately, getting into a big tech company (especially when not doing so right out of a well-known college) requires a lot of luck, so getting access to this mentorship isn't exactly easy...

Absolutely, it's something I researched while writing this article (since I knew someone would bring it up :)). Ultimately, I wanted to talk about concepts more than specific technologies, so I avoided going into detail on Spanner.

I don't claim to understand the underlying tech for Spanner, since I haven't read through the research paper fully. But my understanding is that write latencies are increased, which is a trade-off that has to be made. No matter what, _some_ trade-off is necessary, unfortunately.

I've learned a ton working at scale, and I wanted to share some of that knowledge with others.

To be honest, this is the type of knowledge I actually had to unlearn when I decided to try my hand at early-stage startups. Unfortunately, this is also the type of knowledge that's helpful to go from a startup to a big tech company, where you get the chance to learn this in the first place! Hopefully my writing can help bootstrap that knowledge for others.

At the time I wrote those, I was actually surprised because I didn't see much improvement using emcc-raycast. In both implementations, you can see that I'm allocating objects/structs all over the place, so that probably brings down the performance.

Great demo.

A couple of years ago, I wrote a Javascript implementation myself: https://github.com/avik-das/js-raycast

And then, when asm.js (precursor to WebAssembly) became a thing, I rewrote it in C and compiled it to asm.js: https://github.com/avik-das/emcc-raycast

I'd already written a ray tracer (so a fully 3D renderer) prior to that in college, so it was fun to learn about a more limited algorithm that was better suited to older hardware.

I hadn't heard about CUIDs, but based on the Github repo [1], I see they fall into two of the categories I presented:

- A large range. It looks like CUIDs support a short version, but the README calls out the short version should only be used for disambiguation, and are "absolutely not recommended for database unique IDs".

- Encode the partition in the ID. In this case, the partition is either based on the browser or the process ID of the server.

Cool stuff, thanks for pointing it out!

[1] https://github.com/ericelliott/cuid

This is a topic I wrote about recently[0]. The fundamental problem is that these big companies are so afraid of hiring a bad candidate (a false positive) that they are willing to put up with a ton of smart people who fail their interviews (a false negative).

And the worst part of this is, from the inside, it really looks like the process is working. After all, there are some really smart people who get hired, and saying the hiring process is bad feels like you're saying your coworkers aren't smart. But the truth is, these companies are hitting smart people. They're just hitting a non-uniform dust of all three smart people out there.

I think this is an opportunity for smaller companies to hire people who wouldn't make it into the big companies, and innovate in a way the big companies can't!

[0] https://hiringfor.tech/2020/02/10/false-positives-and-false-...

Absolutely! The feed will be available at https://hiringfor.tech/feed.xml when I start publish content (probably next week).

1. Trying to make hiring in tech a better experience by sharing my knowledge and experience with both job seekers and those doing the hiring. The really hard part about this is influencing some change in how hiring is done, because I strongly believe the current hiring process selects for the wrong skillset. I'm publicly committing to write about this topic weekly with a newsletter that I just launched: https://hiringfor.tech

2. At work, I recently completed a really long project with a large team. I'm trying to make the lessons learned accessible to others in the company because they'll also be undertaking similar projects soon. That means documenting my learnings at a level of abstraction that allows others to not make the same mistakes as us, but still have enough flexibility to tailor their implementation based on their team's needs. The hard part is the intersection of technical and people-oriented knowledge dissemination.

This year is going to be focused on a lot of teaching, which I'm excited about.

I don't have access to the logs when I deploy to Github Pages. Github Pages is really convenient for me for many reasons, but no access to the logs is the main downside when it comes to analytics.

Thanks! You're absolutely right about not being upfront about being GNU Make-specific. I edited the post to mention it, and I also edited the follow-up post to say the same.

I have the same setting, but vim automatically sets `noexpandtab` when editing a file named Makefile. I don't have any explicit setting to do that, nor any Makefile-related plugin.

I'm a big fan of understanding the tools in our ecosystem, whether or not we use those tools directly. Make is one such tool that I initially used by copying other people's Makefiles, tweaking little bits and pieces to suit my needs. Only when I sat down and learned what Make offers out of the box did I grok those Makefiles I was using.

I know people might use tools like CMake, instead of writing Makefiles directly. However, it's still good to know this important part of the Unix ecosystem.

(I was inspired to submit this to HN based on the discussion around "An opinionated approach to GNU Make": https://news.ycombinator.com/item?id=21812656 - a fantastic article, but one you get a lot more out of if you understand the basics first.)

> Your "just let them talk for 5 minutes", is another person's "wait until they're receptive to feedback."

The way I'd put it is "just let them talk for 5 minutes" is another person's "actually listen to them before offering feedback". I'm constantly surprised by how many people offer advice without even hearing what the problem actually is.

It sounds you may already know this, but for those who don't: malls were originally designed to be small cities. The inventor of the shopping mall, Victor Gruen, envisioned a structure with housing, medical centers, post offices, in addition to shopping. The idea was to mimic what his birthplace of Vienna already had: a mixed-use center not dominated by cars the way American suburbs are.

99% Invisible has a great episode about it: https://99percentinvisible.org/episode/the-gruen-effect/

> his leadership qualities depend only on his ability to lead a group towards a goal, which he was doing swell at

It sounds like his behavior was alienating people who would have been willing to work toward that shared goal, but were instead pushed away. So based on what I'm reading, he was a poor leader in this regard.

Maybe I'm reading the GP's anecdote incorrectly, but the behavior in question seemed like targeted harassment, not just "a bit of adult off-color talk".

> The best is defined as the optimum person to complete the required task.

What about long-term potential? Someone may solve the current task well, but will they grow in skill in order to take on larger challenges? Someone who can grow in this way may be better to keep on the same project because they will also have historical context while scaling with the project.

> The "best" is found by measuring his aptitude (tests, etc.).

Measurements for "aptitude", especially tests, are easily gamed and don't in any way guarantee actual competency.

> And if you're still being asked where you graduated from 5+ years into your career ... something might be wrong. Have you really nothing better to show?

Sometimes, the fact that someone didn't go to a top-name school limited their choices. If they went to local state school far from Silicon Valley, and they didn't have money to move to the Silicon Valley right away, they may have worked at small, non-engineering-focused companies. So yeah, maybe they're really capable, but 5+ years into their careers, they haven't had the chance to demonstrate it yet.

The problem is how to measure that skill. For example, I've known very skilled individuals who switched over to my industry later in life. They neither had past experience, nor strong technical abilities when I first met them. But what they did bring to the table was the ability to learn quickly, and after investing in them, they were capable of delivering fantastic results. Furthermore, even early on, they brought their experiences from other industries with them, breaking up the group think that would have formed without them.

Some companies believe the most skilled people are the ones who have demonstrated certain technical abilities. Under this form of meritocracy, the companies delude themselves into thinking they've hired the most skilled people, but they haven't.

The inclusive meritocracy in the article solves that problem by expanding the definition of skilled, and by investing in a more diverse group of individuals. This results in more (in number) skilled people at the end of the investment.

That's a good point, and I'm sure that's true for many people. Interestingly, for me personally, my interview skills increased as a result of interviewing others, as I understood what interviewers were looking for. The big problem is that interviewers typically don't provide feedback to those who fail the interview.

So even that part can have some component of perpetuated exclusivity.