More like, back-end is easy, easier than front-end. He is comparing low-level backends with web frontends.
On my first serious project at the first job I estimated back-end part of an app as 75% and front-end as 25%. It ended up exact reverse of that. And in the next years the pattern repeated over and over.
Everybody seems to think that UI is just about placing buttons but backend is the heavy lifting. In reality, requirements change more often and in a more fundamental way, code is harder to test, more third party dependencies involved, even the dumb KLOC metric ends up bigger.
By any mean, low-level backend will be harder than high-level backend, and low-level frontend will be harder than high-level frontend. Try implementing HTTP server in plain C vs. plain Java (no third party frameworks) and you will see. Being easier is practically the definition of high-level, he is just comparing things that are too different.
He is comparing low-level backends with web frontends.
No, I don't think so. I think he's doing exactly what he said - comparing low-level with high-level. The low level stuff he was working on doesn't sound like it was a backend; it sounds like it was an embedded device running bare-metal (no OS). You wouldn't do a backend (database server, say) that way (or so I suspect).
But that's not what "backend" means. "Backend" means "not directly facing end users, but doing part of the work for the parts that are directly facing end users". Embedded systems are not backend. They are their own category.
Back-end being exciting and interesting might make it a tad easier since you can focus on it. When doing front-end I have to fight myself from browsing the web instead of implementing another CRUD while being asked to somehow make it pop while having no specs.
Comments
More like, back-end is easy, easier than front-end. He is comparing low-level backends with web frontends.
On my first serious project at the first job I estimated back-end part of an app as 75% and front-end as 25%. It ended up exact reverse of that. And in the next years the pattern repeated over and over.
Everybody seems to think that UI is just about placing buttons but backend is the heavy lifting. In reality, requirements change more often and in a more fundamental way, code is harder to test, more third party dependencies involved, even the dumb KLOC metric ends up bigger.
By any mean, low-level backend will be harder than high-level backend, and low-level frontend will be harder than high-level frontend. Try implementing HTTP server in plain C vs. plain Java (no third party frameworks) and you will see. Being easier is practically the definition of high-level, he is just comparing things that are too different.
No, I don't think so. I think he's doing exactly what he said - comparing low-level with high-level. The low level stuff he was working on doesn't sound like it was a backend; it sounds like it was an embedded device running bare-metal (no OS). You wouldn't do a backend (database server, say) that way (or so I suspect).
I'm counting bare-metal/kernel into backend category here, because I don't have better word for "not directly facing end users".
But that's not what "backend" means. "Backend" means "not directly facing end users, but doing part of the work for the parts that are directly facing end users". Embedded systems are not backend. They are their own category.
Taking the minimal to no frontend approach is probably underrated then, for managing complexity. i.e. with Slimvoice https://news.ycombinator.com/item?id=19632817
Back-end being exciting and interesting might make it a tad easier since you can focus on it. When doing front-end I have to fight myself from browsing the web instead of implementing another CRUD while being asked to somehow make it pop while having no specs.