Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike’s Rules of Programming (1989)

users.ece.utexas.edu

Post reply on HN
Print view View original

271–280 of 332 posts

Re: Rob Pike’s Rules of Programming (1989)

#271

Post by Aeolun »

Cthulhu_ wrote: post #267
userbinator wrote: post #208

Earlier quoted context omitted.

It seems that a subset of developers are somehow convinced that adding complexity is a good thing for performance and should be done first, when it should really be a last resort. Their usual rebuttal is "it's scalable " and other buzzword-laden phrases. I wonder if it's a form of "big data envy" or just regular "architecture astronautism".

Honestly, it's the other way around usually; simplicity is scalable. A stateless service talking to a database is fine. You can scale out the service, and scale up the database. It's even easier when you use a cloud provider, their relational database offerings can scale from a wordpress blog's database to enterprise scale, tens of thousands of transactions / second. The problem is that it's boring , and there's a lo…

No, no. We need all these layers of proxies, caches and various databases to make things more reliable!

Re: Rob Pike’s Rules of Programming (1989)

#272

Post by dkarl »

dvfjsdhgfv wrote: post #242
dkarl wrote: post #126

> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

> It looks like an excellent candidate to put it entirely in RAM and trigger sync on writes only, why on Earth would you need anything else.

That's effectively what MySQL is going to do.

Re: Rob Pike’s Rules of Programming (1989)

#273

Post by Aeolun »

rumanator wrote: post #111
mgkimsal wrote: post #93

Earlier quoted context omitted.

> Bad programmers worry about the code And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.

> And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules. It seems to me that what you're actually seeing is an entire industry trying to eliminate all code-related issues, specially bike-shedding ones. This is patently obvious to anyone who was forced to waste their time in code review iterations discussing, say, where a brace should go and how many spaces someone should have add…

Doing any kind of style discussion in a code review means you’ve already failed.

I personally get super annoyed when people keep pointing out style issues, but our CI tool can notify me of issues with my commit until the end of time without me getting frustrated with it.

Re: Rob Pike’s Rules of Programming (1989)

#274

Post by dkarl »

aprdm wrote: post #180
dkarl wrote: post #126

> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

hehehhe I have actually put some data that do not change more often than once a week hardcoded in the code base and commited in source control... whenever a change needs to happen in the data the CI/CD runs and deploys a new version of the app. You don't wanna know how that was done before. It is like < 1 GB of JSON as well.

I wish we had a deployment process trivial enough to support that. On the other hand, eventually you want to farm that job out to customer success or an implementation engineer, and then it's not so fun having the data in source control.

Re: Rob Pike’s Rules of Programming (1989)

#275

Post by lllr_finger »

Supermancho wrote: post #234
veets wrote: post #86

Earlier quoted context omitted.

It seems you are arguing something different, although I am having a hard time understanding what you have written. I think you are saying algorithms and data structures aren't hard, distributed systems are hard. In my experience choosing the correct data structures and algorithms in your services/programs/whatever can dramatically simplify the design of your systems overall.

> It seems you are arguing something different, I'm making an argument that the stark reality of what's hard in software development is not the simplistic "Rules of programming", which have limited utility. The reason the "rules" aren't self evident (or followed), is because we live in the reality of disparate functionality paired with an ever-changing technical landscape. You can't just make a DB KISS abstraction an…

> we live in the reality of disparate functionality paired with an ever-changing technical landscape

It is the responsibility of tech leaders to minimize this (accurate) stereotype. Choose boring technology, and only build your own or choose something exotic when it gives you competitive advantage - because the reality I also see is that 99% of devs aren't working on anything new or unseen in the field. Even at the FAMANG companies, most people I know are working on boring problems.

So when your CTO or architect or whomever buys into the hype for X technology, make a good argument against it by proposing a better solution.

Re: Rob Pike’s Rules of Programming (1989)

#276

Post by bballer »

karl11 wrote: post #6

Everyone building no code tools is learning or will learn that the problem most businesses have is not a lack of coding skill, or the inability to build the algorithm, but rather how to structure and model data in a sensible way in the first place.

I've been preaching this to all my non-coder creative marketing type buddies who have ideas all the time and think they can just whip up a product using all the latest and greatest no-code tooling.

They are destined for failure.

Re: Rob Pike’s Rules of Programming (1989)

#278

Post by specialist »

dkarl wrote: post #126

> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

I feels ya.

My most recent team had our hottest dataset in dynamodb. Because cloud. So much effort to get our web service's P99 The whole dataset fit easily into RAM.

Thru (way too much) effort, I was able to introduce Redis. First shared. Then eventually one mini-instance per EC2, running alongside nginx & nodejs.

Re: Rob Pike’s Rules of Programming (1989)

#279

Post by combatentropy »

OliverJones wrote: post #81

In long-lived systems (systems that run for many years) it's almost impossible to choose the "right data structures" for the ages. The sources and uses of your data will not last nearly as long as the data itself. What to do about this? Two things: STORE YOUR TIMESTAMPS IN UTC. NOT US Pacific or any other local timezone. If you start out with the wrong timezone you'll never be able to fix it. And generations of progr…

PostgreSQL stores it as UTC if the data type is "timestamp with time zone" --- https://www.postgresql.org/docs/current/datatype-datetime.ht...
Post reply on HN