Hacker News Reader

Comment by alkonaut | Hacker News Reader

I think if you miss doing proper algorithmic coding and feel stuck gluing frameworks between a db and a web browser, you should just try to avoid web related development.

In embedded, desktop, games and a ton of other disciplines, there is lots of old school and fun dev and a minimal amount of CRUD boilerplate.

View on HN

Yes, this has worked well for me. Stay out of web development and it's not hard to spend your time doing "real" programming. Embedded work is especially good if you feel nostalgic about 80s-style PC hacking - the downside is that product cycles are limited by the hardware side, so the pace can feel really slow.

> Embedded work is especially good if you feel nostalgic about 80s-style PC hacking.

True, and reciprocally, it is terrible if you hate it. Back to the world of having no debugger, zero tool, potentially no auto completion and unable to do a print.

I still remember an old embedded IDE, when I scrolled down or up with the mouse, the code sometimes becomes a screen of garbage. It's not a display bug, if you save the file, it really become garbage of random characters :D

I will never go back to neither logs nor stacktraces.

Yeah, that's true - but the primitive conditions are a constraint that breeds creativity. I love to build tools, and embedded systems work offers lots of excuses for what would be called "reinventing the wheel" if you did it on a PC. No print? I'll write my own! No debugger? I'll build one! No autocomplete? Don't care, I never use it anyway! IDE sucks? Ehh, whatever, I'll use the terminal! Serial port driver doesn't work? Bootloader crashes? No idea what's going on? Well... okay, I'll debug it by making this LED blink!

But yeah, if that's not what gets you going, then embedded work is not for you.

If you can't tell apart a O(n^2) solution from O(log n) one, you still shouldn't be doing server-side development though.

Of course when you're gluing libraries together it is hard to know what they're doing under the hood. There are a lot of libraries with catastrophically stupid design decisions hidden behind the API, and then when everything runs like shit you find yourself having to dig into the libraries until you find the problem.

I feel that you're driving "we're just gluing libraries" argument to the point of absurd. Do you think that designing database schema and queries that run over it is something that is extremely rare and high-level in modern web development?

It's not rare, yet I find myself redoing this over and over with every job. Web apps that are a HTML table fronting a CRUD back-end and simple database schema are all too common.

I hear you saying "well, that's your fault you keep working at those companies" - and that's not too far from the truth.

Anecdotal evidence of "just gluing libraries": I once had users complain about a web-application being slow. As it turns out, it needed 1 second to generate 1KiB of data. They must have been using some sort of slow ORM in the back-end doing 1 DB query per FK.

That's not a slow ORM. That's literally the model of every single ORM I've seen! Sets, who needs them!

Details matter, quality development matters, and experience matters a LOT!

Okay, pure anecdotal but: exactly the same "complaint" including exactly the same advice (minus the "web" ) could be found some 20 years ago. Not only it seems the field is not "structurally" changing much, it seems people are people, still ;) ... and "CRUD" moved to the web.

Yes there has always been demand for what today is the archetypical web app. Data input. Data washing, data into DB, data out of DB data presentation. Basically the same CRUD we do in webapps, but just a DOS interface, VisualBasic form... That's what you don't want to do.

Reply on news.ycombinator.com