Hacker News new | past | comments | ask | show | jobs | submit | Jemaclus's comments login

I would like to recommend "I Will Teach You To Be Rich" by Ramit Sethi. It's a 6 week program to automate your finances. There's a lot of really good advice in there, and there are some viewpoints that he'll point out that maybe you haven't thought of. (Buying a house, for example, is not always the best idea.)

Love this idea. Very funny and well done!

Fun fact: back in ye olden days (90s, early 00s), we used to call these "boss keys," where you could hit a key on your keyboard while playing a game, and the UI would switch to a spreadsheet or document, so that as your boss walked by, it looked like you were working, but once they were gone, you could hit another key and jump right back into Quake or Hexen or Command & Conquer or whatever. Haven't seen an app with a boss key in a long time, and I think they're due to come back!


I think a lot of this is mental -- identifying problems and solving them -- and then after that, practice practice practice.

There's a quote I've heard from many people that goes something like this: "Make it work; make it work well; then make it work fast."

Wherever you go, look for problems to solve. Code takes 30 minutes to compile? Find a way to speed it up. API takes 3 seconds to return a response? Find a way to speed it up. Database migrations require downtime? Find a way to avoid that.

Another option is to find better ways to do things that you already know how to do. Know how to query an API and retrieve a list of users? Improve it by re-using connections or caching responses for short periods of time. Know how to build a REST API? Now figure out how to scale it to 1000 requests per second. Know how to render a scene using ray-tracing? Optimize it to 60fps.

I think the key here is relentless curiosity. You're asking the right questions, so you're on the right track! Just keep at it. Never settle for "fine." Ask yourself how to make it better. And over time, you'll get "better" on the first try.

Once you have that mindset down, it's just practice, practice, practice. Write as much code as you can. Find tools that resonate with you. Find design patterns that accelerate your growth and reduce mistakes. Incremental progress is still progress!


As an organ transplant recipient who would have died 20 years ago without one, I hope you reconsider.


I will. Please write your representative asking to reform NOTA to permit compensation to the estate through a 20% tax on all transactions involving an organ transfer. For the $700k liver transplant, it is not unreasonable that my family receive $140k. For the $20k the OPO receives, it is not unreasonable that my family receive $4k.

Once NOTA is reformed, I will register to provide.


In many cases, we don't have much of a choice. Recently I applied for Paid Family Leave through my state's website. They'll mail you a form, but the form says they prefer that you file online. The website has a phone number. If you call the number and you're lucky enough to get through, it tells you to use the website. (Most of the time, it says "too many callers" and hangs up.) There is no physical office to which I can go to talk to a real human.

The website itself isn't too bad, I guess. You fill out the form, which is easy enough, and hit submit. At the top there's an "Inbox" section with zero messages.

Two weeks later, you get a letter in the mail. Snail mail, not email. And it says your claim has been approved/denied. Nothing in the website inbox.

As far as I can tell, the inbox does nothing. All communication from the state to you goes through snail mail.

It's wild and crazy and is giving me the biggest headache ever. But I have no other choice, so I put up with it. What else am I to do?


First of all, the fact that you're asking this question puts you ahead of most engineers that I know. There's a well known saying that goes something like "Make it work, make it work well, then make it fast."

One of the simplest ways to think about scale is to think in terms of speed. This is a very very gross oversimplification and glosses over a lot of really important concepts, but at its core, you can say "if it's fast enough, it'll scale."

In a very simple mathematical sense, consider the idea that you have a single-instance, single-threaded application with no concurrency. If a request takes 1000ms to run, then you can do, at most, 1 request per second. If the request takes 100ms, you can do 10 requests per second. If it takes 10ms, you can do 100 request per second, and if it takes 1ms, you can do 1000 requests per second.

See? Speed is throughput is scale.

But that is, obviously, an oversimplification of the problem. Real applications are multi-threaded, multi-instance, and offer concurrency. So now the problem is identifying your bottlenecks and fixing them. But again, at its core, the main idea is speed. How can you make things as fast as possible?

(Note: There is a need to consider concurrency and parallelism, plus certain data stores have inherent speed limitations that may need to be overcome, and those things can offset poor speed, but the simplest path to scalability is speed and optimizing throughput.)

The analogy I like to use is the grocery store. Imagine you own a grocery store, and you want to make as much money as possible. Well, the best way to do that is to make sure your customers can get their food and check out as fast as possible. That means making sure the food is easy to find (i.e., read access is fast!), that they don't have to wait to check out (i.e., queue depth is low), and that checking out is fast (i.e., writes are fast). The faster your customers can walk in the door and back out again, the more customers you can sustain over a period of time.

On the other hand, if your customers take too long to find their groceries, or they spend too long waiting in line, or they have to write checks instead of swiping a smart phone, then you wind up with a backlog. And the larger the backlog, the longer it takes for money to hit your bank account.

So in this sense, time is literally money. The faster they can get through your system, the better.

I mentioned three different ways of thinking about speed: reads, writes, and queue depth.

Keeping with our grocery store analogy, consider how to improve each of those things. How do you make sure your customers can find what they're looking for as fast as possible? You "index" things. You put signs on the aisle, you organize your content in a way that is intuitive and puts related things near each other. If you want spaghetti, the pasta and the sauce and the parmesan cheese are all right next to each other. If you want breakfast, the eggs and milk and cinnamon rolls are right next to each other. In and out.

Similarly, your data needs to be organized smartly so that the user can get in and out as fast as possible. In a database, this means optimizing data structures, adding indices, and optimizing queries. Reduce expensive queries, keep cheap fast queries. Find ways to cache hot data. Make it easy to find what you need.

For writes, how do you speed up writes? One way is to make things asynchronous. Throw things that can be eventually consistent into queues and let an asynchronous job handle it outside the normal flow. The customer experiences minimal latency, and you've introduced concurrency to keep the data flowing while the customer is doing something else. This is, in part, why those little screens at the checkout counter ask you so many questions. They're distracting you while the cashier is scanning your groceries.

Queue depth optimization is important as well. If the queue gets really long at the grocery store, how do you improve that? You add more cashiers! The more cashiers you have, the more concurrent customers you can handle. But does it make sense to have 1 cashier per customer? Probably not. Now you've overscaled and you're spending too much money.

As you can see, this is a complex operation, and again, my analogy is overly simplified and very dumb, but I hope this gives you a decent idea of how to visualize a scalability problem.

I'm not familiar with Elixir, but frankly the concepts should translate to any language, although the details my vary.

My suggestion? Learn how to do profiling, identify bottlenecks, and target the biggest bang for your buck. The big risk here is micro-optimization, so fight for changes that give you order of magnitude improvements. Saving 50 microseconds isn't worth your time, but shaving off 1500 milliseconds almost certainly is.

Best of luck.


As someone working in an extremely small scale world I don’t get opportunities to tackle scaling problems, so this was a very nice read. Thanks!


Even at small scales, speed is extremely important! I don't know if it's still true, but I talked to an engineer at SmartyStreets several years ago, and they said they could serve up 100,000 requests per second on a Raspberry Pi. At the time I didn't believe them, but since then I've developed several systems that could absolutely do that.

At small companies, every dollar counts. You could save a bajillion dollars by serving up all your traffic on an AWS micro or small instance, instead of larger machines!

So even at small scales, it's worth figuring out how to make things fast. That makes scaling later much easier!


Thanks! Why would you want fast read access in the customer example? More customers looking for items means a smaller queue


You mean "customers in the aisles means shorter lines at checkout"? That would be true if you're optimizing for short lines at checkout, but what a business is really optimizing for is sales over time, and so you want as many people to come in, buy their stuff, and leave in as short a period as you can. The more people you can get in and out of your store, the more money you make.

The more time they spend wandering the aisles (or browsing your site), the more opportunity for them to say "I can get this somewhere else faster/easier/cheaper." Every second they aren't punching in payment details is a moment for the baby to cry, for someone to call, for the boss to give them an assignment, for a bathroom break. Any of those things can totally break the moment and cause the customer to abandon their cart and leave.

Solution? Don't let them hang around. Get them to their goal as fast as possible and keep the total transaction time -- from landing on the site to checking out -- as short as you possibly can.

To put a more concrete example, imagine a company like Instacart. If it takes you more than an hour to fill up your cart on the site -- for whatever reason! whether bad organization, slow response times, whatever -- then you might as well just go to your local grocery store yourself! You can almost certainly be in and out of your local store in less than an hour.

The value prop that Instacart has is "you never have to go to the grocery store again, because it's easier to order from home." But if it's harder to order from home, then what's the value of Instacart? (Again, I'm oversimplifying here, but this is the gist of the value prop. Instacart doesn't sell groceries -- it sells TIME. It sells that hour of your life back so you can spend it with your family or playing video games or arguing with me on HN.)

And so in terms of scalability, Instacart wants you to land on the site, add everything to your cart, and get the order placed as fast as possible. And to do that, everything needs to be fast. The category pages need to load fast, the product detail pages need to load fast, your cart needs to load fast, the checkout pages need to load fast. The faster everything is, the quicker -- and better! -- your experience is.

There are numerous studies out there that show that as little as 500ms latency can cost millions of dollars for a company. It's really important to keep everything fast!

I have more thoughts about this, but this is the gist of the answer to your question: because the goal isn't short queues, but rather faster total trips.


Start interviewing! Get experience! Don't expect every interview to result in an offer. Take each interview as practice. Honestly, the first 10 companies you interview with, you should fully expect rejection, so don't go after your dream jobs immediately.

Interviewing is a skill just like ML and coding are skills, and you need to practice to do it well. And the best way to practice... is to do it!

And frankly? Everyone should be interviewing on a regular basis, anyway. Always keep an eye on the market and be ready to jump if something better comes along.

Best of luck!


looks at the market for coding skills "hmm... guess I'll interview at McDonald's for practice" ;)


Time to get a real job bro.


Here's the thing: if you don't play, you definitely can't win and your odds are zero. You can't win if you don't play.

I personally buy a single $2 lottery ticket about 2-3 times per month. I know I'm not going to win. But you know what I do? I spend at _least_ 30 minutes, if not the entire day, fantasizing about what I would do with the money.

Am I going to win? Not at all. But I think I now have a better idea of what my financial priorities are than I did before I started playing! I know what I'd do with my money if I won $1M, 2M, 5M, 10M, 25M, 50M, 100M, 250M, 500M, 1B... I know what I'd do with the money. And you know, I may never get to $1 billion, but given my current income and age, I will definitely hit the $1M and $2M marks, possibly the $5M point. And so knowing what I would do with that kind of money? That's pretty fun to think about.

In a world where my wife and I go to see Dune 2 in movie theaters and it costs $100, or in a world where a burrito can cost $15-20, or gas prices at $6+ per gallon, a $2 piece of entertainment with the tiny, infinitesimal chance of winning big seems eminently reasonable to me.

Now, if you're Bruno Mars and have a gambling problem, then maybe you should spend those $6/mo on something else.


You said "book" (singular), and I just wanted to let you know it's actually a trilogy, so there are more if you want to read them!


I totally agree with you, but I'm deeply amused that you didn't define the term yourself!

This is a pet peeve of mine, for real, especially with PR releases that sometimes hit the top of HN. Sometimes you'll see a post about "Updates from Widgetizer" and then it just talks about the features, assuming everyone already knows what Widgetizer is. It's kind of crazy. The writers are missing out on a lot of conversion by not doing a "by the way, ADB is the Amazon Debug Bridge, a tool that lets you..." and then people go "Wow, I didn't know that existed," and go investigate.


I didn’t know what it was until someone posted a reply to my comment. I don’t have an Android device and I can’t be bothered to fill in the obvious gaps the author left when the thing isn’t of immediate consequence to me.

It wasn’t intentional, but one could argue by my not defining the term I helped it really sink in for people how annoying it is, heh.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: