Live data from Hacker News

Ask HN: Language-agnostic concepts a Backend Engineer should know?

news.ycombinator.com

41–50 of 60 posts

Re: Ask HN: Language-agnostic concepts a Backend Engineer should know?

#41

I think it's important to know about different data storage options and their trade-offs. Managing state is one of the hardest parts of backend development, particularly at scale, so an understanding of the trade-offs in databases/caches/blob-storage/queues, and when each is useful is important. I'd pay close attention to speed and "correctness". What's the consistency model of a system? Can we lose data and if so ho…

Absolutely this. Also, I’ve had to explain this to so many other engineers, both junior and senior to me: most data is inherently relational . This next statement is a bit opinionated: 9 times out of 10 you probably want an RDBMS. I’ve seen so many attempts to shoehorn some ElasticSearch/Mongo/Neo4j/whatever database into a design because the developer wanted to work on CoolDatabaseTech. Then you’re stuck dealing wit…

Exactly, but it goes a lot further than RDBMSs. For example does the application expect that all items on a queue will be processed? If so then you need a durable queue and Redis probably isn't a good idea, and this will likely reduce the throughput of the queue which might change how it needs to be used.

One I've been bitten by several times is expecting APIs to allow me to read-my-writes, only to find that their underlying data store is eventually consistent. The integration point/API client on our end may end up being twice as complex or more just to handle that.

Re: Ask HN: Language-agnostic concepts a Backend Engineer should know?

#42
post #11

C and how to debug it. If you understand the system a layer of abstraction or two below the layer you work in, you will be able to debug deeper. Learn system calls, Various ways how to examine processes. I learnt a lot of this back in the day by completing war games on a site called digital evolution (dievo). Those are antiquated now but still a really fun way to learn it.

So much for being language agnostic

Re: Ask HN: Language-agnostic concepts a Backend Engineer should know?

#43
post #30
post #11

C and how to debug it. If you understand the system a layer of abstraction or two below the layer you work in, you will be able to debug deeper. Learn system calls, Various ways how to examine processes. I learnt a lot of this back in the day by completing war games on a site called digital evolution (dievo). Those are antiquated now but still a really fun way to learn it.

Also, learn Javascript and browser tech in general. One of the keys to high-performance systems is figuring out how to make the layer above and the layer below talk to each other while removing yourself from the process as much as possible.

I would think that most front end developers already know JavaScript. It might make sense to look at some other approaches like Go (and maybe Rust/C/C++), which is designed for back-end work unlike JavaScript which was basically shoehorned into back-end work in order to leverage all the JavaScript developers in many companies.

Re: Ask HN: Language-agnostic concepts a Backend Engineer should know?

#44
post #18

Earlier quoted context omitted.

sounds very niche from an employability PoV.

You are by all means welcome to remain ignorant of how computers and frameworks and libraries all work, incapable of tracking down and fixing bugs in your application stack that affect you. Build a career filling in the boilerplate that Spring or Rails or whatever generates, and when the system doesn't perform as you expected it to, throw up your hands and say "I don't know what it's doing," and end the matter there.…

Your first paragraph is dead on. When I first encountered Ruby on rails after developing in C++ for years, it was very difficult to accept the black box of ruby on rails. In fact, my instincts are to fear tools like that. The sheer number of dependencies on third parties when using tools like Ruby on rails is downright frightening. Good luck making sure that all of the libraries your linking to are secure and that you can fix any issues that come up.

Re: Ask HN: Language-agnostic concepts a Backend Engineer should know?

#45

I think it's important to know about different data storage options and their trade-offs. Managing state is one of the hardest parts of backend development, particularly at scale, so an understanding of the trade-offs in databases/caches/blob-storage/queues, and when each is useful is important. I'd pay close attention to speed and "correctness". What's the consistency model of a system? Can we lose data and if so ho…

Absolutely this. Also, I’ve had to explain this to so many other engineers, both junior and senior to me: most data is inherently relational . This next statement is a bit opinionated: 9 times out of 10 you probably want an RDBMS. I’ve seen so many attempts to shoehorn some ElasticSearch/Mongo/Neo4j/whatever database into a design because the developer wanted to work on CoolDatabaseTech. Then you’re stuck dealing wit…

> 9 times out of 10 you probably want an RDBMS.

And the last 1 can be done (modeled) in a RDBMS when the scale/pressure/volume is low. In other words, wait until you feel the heat.

Re: Ask HN: Language-agnostic concepts a Backend Engineer should know?

#46
post #45

Earlier quoted context omitted.

Absolutely this. Also, I’ve had to explain this to so many other engineers, both junior and senior to me: most data is inherently relational . This next statement is a bit opinionated: 9 times out of 10 you probably want an RDBMS. I’ve seen so many attempts to shoehorn some ElasticSearch/Mongo/Neo4j/whatever database into a design because the developer wanted to work on CoolDatabaseTech. Then you’re stuck dealing wit…

> 9 times out of 10 you probably want an RDBMS. And the last 1 can be done (modeled) in a RDBMS when the scale/pressure/volume is low. In other words, wait until you feel the heat.

Yeah, Postgres off the top of my head does NoSQL (JSONB), graph and time series stuff either natively or through some cheap or freely available add ons. It really can do anything. It’s not gonna be the best at that non-relational stuff, but it will do a “good enough” job for most use cases until you introduce heavy scaling.

Re: Ask HN: Language-agnostic concepts a Backend Engineer should know?

#47
post #38

Earlier quoted context omitted.

You are by all means welcome to remain ignorant of how computers and frameworks and libraries all work, incapable of tracking down and fixing bugs in your application stack that affect you. Build a career filling in the boilerplate that Spring or Rails or whatever generates, and when the system doesn't perform as you expected it to, throw up your hands and say "I don't know what it's doing," and end the matter there.…

>>frameworks and libraries all work, incapable of tracking down and fixing bugs in your application stack... What does any of this has to do with C? >What can you possibly get out of it? I hope you realise that many of commenters here are not even software engineers. HN covers more topics than just 'another arrogant software dev lectures someone on topic X'

> 'another arrogant software dev lectures someone on topic X'

Not GP. But this is explicitly a software thread.

> >>frameworks and libraries all work, incapable of tracking down and fixing bugs in your application stack...

Pretty sure they are implying that C/C++ lies somewhere in most software stacks.

Re: Ask HN: Language-agnostic concepts a Backend Engineer should know?

#49

I'm currently learning back-end coming from a front-end career, and I started reading "Designing Data-Intensive Applications" by Martin Kleppmann, seems to be a must-have for anyone who wants to get serious in this field.

Yes this is a great book and a perfect example of language agnostic knowledge that is useful.

Re: Ask HN: Language-agnostic concepts a Backend Engineer should know?

#50
post #40
post #31

Earlier quoted context omitted.

Well, one doesn't have time to learn everything, so it's entirely reasonable to do a cost-benefit analysis (in terms of employability or personal interest) before investing.

The OP's statement makes the context clear though: It's not about knowing everything. It's about knowing a couple of abstraction layers under you (and, as I argued elsewhere, above you too). It's useful to understand a few classic networking problems that a backend engineer might face — e.g. weird latency issues caused by Nagle's algorithm, or TCP CLOSE_WAIT leading to ephemeral port exhaustion between a proxy and an…

OP was responding to a comment specifically about debugging C. Someone questioned the value of this to employability and then the comment I responded to laid into him/her, suggesting no one on HN should ask that. I am defending that question.
Post reply on HN