Live data from Hacker News

What the hell have you built

wthhyb.sacha.house

101–110 of 239 posts

Re: What the hell have you built

#101
post #64

An improved CV, lets be honest most stuff is boring projects that could even be built with 1990's technology, distributed systems is not something that was invented yesterday. However having in the CV any of those items from left side in the deployment strategy is way cooler than mentioning n-tier architecture, RPC (regardless how they are in the wire), any 1990's programming language, and so forth. A side effect fro…

Any minute you spend in a job interview defending your application server + Postgres solution, is a minute that you will lack to talk of follow up questions about the distributed system that interviewer was expecting.

Yes, it’s nonsense, stirring up a turbulent slurry of eventually consistent components for the sake of supporting hundreds of users per second, it’s also the nonsense that you’re expected to say, just do it.

Re: What the hell have you built

#102
post #71
post #8

What the hell have you built? Turns out a pretty straightforward service. That diagram is just aws, programming language, database. For some reason hadoop I guess. And riak/openstack as redundant. It just seems like pretty standard stuff with some seemingly small extra parts because that make me think that someone on the team was familiar with something like ruby, so they used that instead of using java. "Why is Redi…

This comment makes this thread a great time capsule. Given that the website is now over 10 years old, it perfectly illustrates how much 'best practices' and architectural complexity (and cloud bills) have changed since then.

No no, don't give me this.

I was there before 10 years ago. I remember the pain in the ass that was hosting your own web server and own hardware, dealing with networking issues with cisco switches and thinking about getting a ccna. I remember the days of trying to figure out php and ranodm ass modules or how python and wsgi fit together on a slow ass windows machine instead of just spinning up an app and doing network calls using a spa.

Have you guys just forgotten all the enterprise crap that existed? Have you guys forgotten before that how things like compilers (ones you had to pay exorbintant amounts of money for) and different architectures were the headaches?

It's been two steps forward, one steps back, but we're still way better off.

Yes, people bring in k8s because they want to resume build and it goes poorly, but I've also used k8s in my personal setup that was much easier than the poor man's version I had of it.

All of this is just rose-tinted glasses, and people throwing the baby out with the bathwater. Just because some people have bad experiences with microservices because people don't often do them right, people just write them off completely.

Re: What the hell have you built

#104
post #96
post #64

An improved CV, lets be honest most stuff is boring projects that could even be built with 1990's technology, distributed systems is not something that was invented yesterday. However having in the CV any of those items from left side in the deployment strategy is way cooler than mentioning n-tier architecture, RPC (regardless how they are in the wire), any 1990's programming language, and so forth. A side effect fro…

This is also how you can identify decent places to work at: look for job postings that emphasize you aren't expected to already know the language. For example, in the recent "who's hiring" thread, I saw at least two places where they did that: Duckduckgo (they mention only algorithms and data structures and say "in case you're curious, we use Perl") and Stream (they offer a 10-week intro course to Go if you're not al…

To do that you need a mixture of elements: work in a somehow "exotic" language [1] and the company can afford to pay top-talent salary [2]

[1] all those examples check that box, but please let's not start a language war over this statement.

[2] for Jane Street I hear they do, DDG pays pretty well especially because it pay the same rate regardless where you are in the world, so it's a top-talent salary for many places outside SV.

Re: What the hell have you built

#105

I don't really get this line of argument Or at least it's not engaging with the obvious counterargument at all - that: "You may not need the scale now, but you may need it later". For a startup being a unicorn with a bajillion users is the only outcome that actually counts as success. It's the outcome they sell to their investors. So sure, you can make a unscalable solution that works for the current moment. Most lik…

>So sure, you can make a unscalable solution that works for the current moment.

You're making two assumptions - both wrong:

1) That this is an unscalable solution - A monolith app server backed by Postgres can take you very very far. You can vertically scale by throwing more hardware at it, and you can horizontally scale, by just duplicating your monolith server behind a load-balancer.

2) That you actually know where your bottlenecks will be when you actually hit your target scale. When (if) you go from 1000 users to 10,000,000 users, you WILL be re-designing and re-architecting your solution regardless what you started with because at that point, you're going to have a different team, different use-cases, and therefore a different business.

Re: What the hell have you built

#106
The fact that we have lambdas/serverless functions and people are still over-engineering k8s clusters for their "startup project" is genuinely hilarious. You can literally validate your idea with some janky Python code and like 20 bucks a month.

The problem is that people don't like hearing their ideas suck. I do this too, to be fair. So, yes, we spend endless hours architecting what we'd desperately hope will be the next Facebook because hearing "you are definitely not the next Facebook" sucks. But alas, that's what doing startups is: mostly building 1000 not-Facebooks.

The lesson here is that the faster you fail, the faster you can succeed.

Re: What the hell have you built

#107
post #24
post #7

I feel like sometimes it’s a form of procrastination. There are things we don’t want to do (talk to costumers, investors, legal, etc.), so instead we do the fun things (fun for engineers). It’s a convenient arrangement because we can easily convince ourselves and others that we’re actually being productive (we’re not, we’re just spinning wheels).

Is it really for "fun"? Or is it to satisfy the ideals of some CTO/VPE disconnected from the real world that wants architecture to be done a certain way? I still remember doing systems design interviews a few years ago when microservices were in vogue, and my routine was probing if they were ok with a simpler monolith or if they wanted to go crazy on cloud-native, serverless and microservices shizzle. It did backfire…

I worked for a company once where the CEO said I need to start using Kubernetes. Why? We didn't really have any pressing use cases / issues that were shouting out for Kubernetes at all.

His reasoning was all the big players use it, so we should be too...

It was literally a solution looking for a problem. Which is completely arse backwards.

Re: What the hell have you built

#108
post #98

While I agree with most of this rant, I have a problem with the common "just use postgres" trope, often repeated here. I recently had to work with SQL again after many years, and was appalled at the incidental complexity and ridiculous limitations. Who in this century would still voluntarily do in-band database commands mixed with user-supplied data? Also, the restrictions on column naming mean that you pretty much h…

"just use postgres" is an excellent advice. How about incidental complexity and ridiculous limitations of an ORM? Time spent learning how to use an ORM can better be spent 'refreshing' your SQL knowledge. Also, when you learn how an ORM works, you still don't know proper SQL nor how do databases works, so when you switch language now what, you quickly take a course on another ORM? SQL is a language, ORM is not,it's just ' an entire layer of code that your application doesn't really need' and in some applications you could never ever use an ORM.

Re: What the hell have you built

#109
post #81

It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues: You want straightforward, self-contained deployments for one, instead of uploading files onto your single server. If the process crashes or your harddisk dies, you want redundancy so even those twelve customers can still access the appli…

> You want a CI pipeline, so the junior developer can't just break prod because they forgot to run the tests before pushing. Make them part of your build first. Tagging a release? Have a documented process (checklist) that says 'run this, do that'. Like how in a Java Maven build you would execute `mvn release:prepare` and `mvn release:perform`, which will execute all tests as well as do the git tagging and anything e…

Why not do a CI pipeline from the beginning instead of relying on trust that no one ever forgets to run a check, considering adding CI is trivial with gitlab or github.

Re: What the hell have you built

#110
post #37

Earlier quoted context omitted.

The point is that it doesn't matter which is better or worse for the case, or if you know the pros/cons of each: In those interviews (and in real work too) people still want you skewing towards certain answers. They wanna see you draw their pet architecture. And it's the same thing in the workplace.

I fully agree on workplace politics, but for system design interviews, are you not also just supposed to ask your interviewer, ie give them your premises and if they like your conclusions? I also understand that some companies and their interviews are weird, but thats okay too, no? You just reject them and move on.

If there's a big enough bias, the questions become entirely about finding that bias. And on 90% of cases the systems design questions are about something they designed in-house, and they often don't have a lot of experience as well.

Also: if there's limited knowledge on the interviewer side, an incorrect answer to a question might throw off a more experienced candidate.

It's no big deal but it becomes more about reading the room and knowing the company/interviewers than being honest in what you would do. People don't want to hear that their pet solution is not the best. Of course you still need to know the tech and explain it all.

Post reply on HN