noamsml

Joined 18 years ago

Karma
470
Submissions
192
Member since
Aug 23
Software Engineer on Payments at Square. My opinions are my own.
View on Hacker News

Recent submissions

Comment · 9 years ago
I'm no expert on snapchat, but one thing I can say from personal experience being at an IPOing unicorn -- until about a year into our IPO, we were a "no buy", and all of these giant companies were ostensibly going to crush us with products that didn't even compete with us. Then, one year and a couple of earnings calls in, we're suddenly a "buy" and people consider us stable and successful. What did I learn from this? Never trust the stock market, and doubly so do not trust the stock market with a new stock.
Comment · 10 years ago
Low wages? Silicon valley engineers tend to be fairly highly paid...
Comment · 10 years ago
I feel like this is a terribly lacking reply. I'm not a trend-person by any mean: I'm a deep-backend developer, and my main language right now is Java[1]. However, when I have to maintain rails apps, even well-written ones, I find myself frustrated. I think ceding the advantages of a compiler is a fundamental mistake. Compilers and static checkers make for better software more easily; they don't replace tests, but they complement them and constitute compilable documentation for your code, enhancing its maintainability considerably.

[1] I write in Java because I work for a Java shop, but even if I had my choice of languages, I'd probably be using either Swift or a compile-to-JVM language.

Comment · 10 years ago
I disagree. I'd rather getWhenPresent than orElse if the code has nothing to do with a missing value. If someone needs the value and uses orElse without isPresent, their code will break in new and unexpected ways rather than in the obvious one.

(An even better solution is SWIFT's approach to nullable types, but that boat has sailed; intellij etc could however implement a static checker for bare Optional-getting)

Comment · 10 years ago
Playing devil's advocate here: The only way to really learn the full ruleset of a team is by undergoing a couple of code reviews in which every issue is pointed out. Once your teammates see you've understood the prevailing style, they don't have to work as hard at code reviews.

That said, I usually hate petty/nitpicky code reviews. I try to focus only on issues that I think affect readability, maintainability or functionality.

Comment · 10 years ago
I wonder if, given the giant set of existing Android libraries written in Java, they'd need to create a swift <-> java FFI.
Comment · 10 years ago
Comment · 10 years ago
Where's the redirect to some app store bullshit after 5 seconds?

Never buying or using anything from those sleazeballs, and you should follow suit.

Comment · 10 years ago
Apple Pay uses the same token for many transactions. It's not unique per tap.
Comment · 10 years ago
This is like people who want to repeal Obamacare and have no alternative. If you advocate blocking all ads, you should at least have a vision for how you're gonna pay for your fucking content. I block ads too (I'm ADD and moving objects in my field of vision make it hard to enjoy content), but I'm not going to be fucking self-righteous about it.
Comment · 10 years ago
Nice. These sorts of warnings are why it's worth investing the extra effort to enable -Werror in your codebase if you can.
Comment · 10 years ago
Comment · 10 years ago
I don't entirely agree. As someone who works in a mid-to-large company, and who has worked in a 50,000 person company (admittedly for both companies not all employees were engineers), I feel it's worth noting that as companies get larger and teams more diverse, they tend to require the exact features open source projects need.

A product manager in team X who noticed a bug in product Y is not going to know what fields are necessary for that product, and as issues make their way to company-wide mailing-lists (or are linked from internal meme websites -- you know who you are), they may accumulate +1-spam if no voting system is put in place. As such, I believe GitHub's ability to move upmarket and satisfy its larger customers is actually aligned with implementing the features requested in the "Dear Github" letter.

Comment · 11 years ago
Anecdote: I switched back from a kindle after 2 years. My kindle broke in the middle of a thrilling novel (The Magicians by Lev Grossman, highly recommended), and I decided to buy it hardback. Soon enough, I decided to not bother getting my kindle fixed -- paper books felt so much more focused, more visceral, and more engrossing.

I'm not sure it's inherent. This may be a generational thing -- I grew up on paper books. Still, one data point.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton