Hacker News Reader

Honestly when I see what my friends who design airplanes and particle accelerators are doing, I feel like we're all kind of fucking around in software engineering, frontend or not.

Try looking into or messing with actual engineering of software instead. You'll get similarly amazing things. Here's a few:

http://www.anthonyhall.org/c_by_c_secure_system.pdf

http://www.methode-b.com/wp-content/uploads/sites/7/dl/thier...

https://ts.data61.csiro.au/publications/nictaabstracts/7371....

http://ceur-ws.org/Vol-192/paper08.pdf

Heh, true. Compared to real engineers and scientists we're just a bunch of monkeys re-inventign the wheel every 10 years (with each iteration being worse than the prior one).

But from time to time one of us monkeys gets lucky and changes the world.

So I guess it's a risk/reward thing :)

I agree, most are.

"but there's no real technical challenge in front end stuff."

oh boy, you are so wrong! as an old fart having spent a number of years building UIs, can tell you, this is hard! information layout, controls, flow - it can be tangled into a total CF, or it can be seamless. you are not pasting libs on top of libs - that is the job of a monkey, front or back end alike. normal devs start their day with talking to end users and listening to their pain. then they spend rest of the day trying to alleviate it. monkeys spend their days thinking how they can add to user's pain by pasting more layers of crap.

engineering is an important part in back end, front end or in cleaning the toilets. it is not what you do, it is how you do it.

You're describing a task which is more frustrating than technically challenging. Nothing you described requires a high degree of intelligence or training, only time. Of course some are better than others at it, but that's true of anything.

Think; designing the CV systems for self driving cars (since that's a hot topic at the moment) vs designing a UI which works seamlessly across browsers. One is a real, honest to God engineering challenge; the other is an exercise is patience and perseverance. There are many more people in this world who could pull off the latter than could the former.

If you truly, honestly believe that UI dev work is technically difficult when measured against the rest of the engineering world then I can't imagine you've been solving hard problems throughout your career. UI layout is not "hard" and it's certainly not engineering, nor is 'cleaning toilets'. of course creating UI's comes with its own set of challenges, but I'm specifically talking about technical difficulty.

You can jump off the train and do bad UI at any moment. But UI always, always, gets hard when you start caring. That's not a measure of whether UI is harder than CV, it's a low-pass filter on what the market will value.

Most of the individuals making CV demos are not making unfathomable genius-level demos: they are taking an existing library and bolting on a simple application to it. And most such demos are flimsy and not commercially viable, because the technology needs more massaging at a deeper level than the author is capable of in order to fulfill the desired marketing promise.

Meanwhile, simple bolt-on UI tends to be good enough. Not because it's fine as-is, but because the user can accommodate for its brokenness without being able to express what exactly is wrong with it. The product can ship and create value, albeit not as much. Yet, a UI dev who wants the best possible experience has to have the same attention to detail up and down the stack as the CV dev who wants their algorithm to perform well along every metric. UI innovations are understated because they oft seem obvious or unsurprising in retrospect, but they do come along every so often, and often in tandem with the developments elsewhere - these days, AI algorithms are increasingly intertwined with the interface in a very direct fashion, when one considers voice processing, predictive text, or other such features.

And yet, if you should aim to achieve better UI, some naysayer will come along and proclaim that you have made something "overengineered" and should "just use a standard toolkit like the rest of us."

by UI design I do not mean cross browser compatibility, but rather an understanding of the underlying data and operations on it, which involves familiarity with the business domain. this is hard. putting stuff on the screen is not hard. I am OK with tables and gifs. with all due respect your contempt for people who build UI (and clean the toilets) and misunderstanding or general principles of engineering are sad (pardon my microagression).

> putting stuff on the screen is not hard

> your contempt for people who build UI

You've carved out your own definition of Frontend dev, it doesn't always require business/domain knowledge, many just put stuff on the screen.

Incidentally, I found this hard - not in a math problem way, but in a costing a lot of time and patience way. I distinctly recall spending a couple of hours trying to align some div after being requested to do so. I strongly dislike CSS.

Oh don't even get me started on front end development. A few times I've actually had the opportunity to make some really brilliant JavaScript optimizations only to have any performance gain made totally irrelevant by business loading up the page with a ton of totally non-performant ads.

This hits home way too hard.

> You're not solving hard engineering problems

What, in your mind, makes an engineering problem hard? I've certainly had to dig out CS algorithms and 'clever' applications thereof to reach desirable performance out of some custom widgets in front end projects. I don't know if that can considered hard – hindsight tends to make everything seem easy – but it is certainly beyond pasting in a library like you describe.

I have to agree that you can create some very useful projects that do not deviate from a framework/library's documentation, or what have you. But we don't really know what the parent in particular is working on.

>What, in your mind, makes an engineering problem hard?

A problem which requires a high degree of creativity, intelligence, and technical ability, likely one which hasn't been solved before. You're right; it's a bit difficult (at least for me) to define, but we know it when we see it. Sending men to the moon was a hard engineering problem; implementing the UI for gmail was not.

You speak of using 'CS algorithms' in your UI's. I assume you're talking about things like optimizing a search of a list by using a better data structure or sorting algorithm. C'mon. You didn't solve these problems, other people did, you just did a little research, and this is basic stuff most of us can pull off fairly easily.

The vast majority of web development is not engineering. It is in fact just pasting together code other people wrote to solve a particular, relatively trivial problem.

Lol, you think you are spending 40 hours a week at the forefront of problem solving new challenges?

Let's be real, for a moment. By your definition of a hard engineering problem, very few people are spending their time doing it. Virtually no one is doing it every day.

Why pick on front end dev specifically? You think the average backend dev building installing flask is facing a lot of unsolved problems? You think the average game dev is rendering 3D models in some new, magical way?

So, I didn't want to say what I do because I didn't want to make it personal, but yes, I do. I work in biotech and desogn control systems for an immunofluorescent imaging device and associated computer vision algorithms used to identify circulating tumor cells in the blood stream.

We just released a prognostic test for colon cancer which is actually relatively groundbreaking as it provides a new treatment path for people who previously had no options.

So yes, I feel that I am. I have been a part of small engineering teams delivering brand new technologies to the market my entire career.

And you're right, very few people, especially in software, are solving hard problems. I wasn't picking on anyone, I was responding to a comment.

So you are using a fluorescent fiberscope to identify tumors.

So you are implementing some vision library. How is that a hard engineering problem?

> So yes, I feel that I am.

That's the crux of the issue. You are doing exactly what you find so distasteful about web development: implementing existing algorithms to solve a specific problem.

Unless of course, your team is actually inventing new vision algorithms that somehow changed the field, which I'd love to see the paper on.

Stringing together some OpenCV functions isn't hard engineering.

> You didn't solve these problems, other people did

that's a high bar for engineering. Integrating known solutions into a situation is engineers. Mechanical engineers don't discover the laws of motion themselves.

So you're right about that, and I thought the same right after I posted. There is of course a scale here. Taking academic scientific research and turning it into something real is a far cry for changing e.g. an array to a hash table to improve lookup speed.

> I assume you're talking about things like optimizing a search of a list by using a better data structure or sorting algorithm.

You assume wrong. They were not straight up textbook problems, but I agree that I used a wealth of existing knowledge to apply it to my specific problems. That's what engineering is.

> You didn't solve these problems, other people did

Naturally. If you are working on finding novel discoveries the world has never seen before, you would be appropriately labeled a scientist working on science. Hence, also why we consider the algorithms I mentioned before to come from computer science, not software engineering.

You are comparing the sexiest problems of one field with the ordinary problems of another. This is just unfair comparison.

By saying that "we know it when we see it", you are acknowledging that this is a value judgment (nothing wrong with that, just don't present it as an absolute truth). Also, by your definition, sending humans to the moon is not a hard engineering problem. It has been done before; it involves pasting together some relatively well-understood components like rocket engines and guidance systems.

I think you have confused engineering for research. Engineering is not anything like you have described. I went to school for aerospace engineering.

Ok, then backend folks just do API integrations and database guys just make tables, no real technical challenges anywhere. Anybody getting stuff done is pasting together libraries.

>Ok, then backend folks just do API integrations and database guys just make tables, no real technical challenges anywhere. Anybody getting stuff done is pasting together libraries.

The original poster said nothing about frontend vs. backend. Still, you're absolutely correct, backend work is mostly gluing together pre-built libraries and software too.

> there's no real technical challenge in front end stuff

You're looking at this backwards. It isn't about the task. It's about the person who approaches the task. Someone "creative, intelligent and technically able" (to quote your later comment) will bring vision to any task.

Like water they will find their level, find the new and shining thing they can bring to the arena in which they find themselves.

These invidious distinctions contribute nothing to mutual understanding amongst computing professionals. All of whom need to work with each other to achieve great things. That includes the documentation people - shout out to them for their intelligence and creativity too.

There's engineering challenges in frontend but they only apply to Facebook-tier scale. There's also cooler stuff like data visualization, advanced animations/design and WebGL but those seem to be done by designers. For most of us, it truly is gluing X framework to Y backend over and over again.

Sure, but even then I wonder how much of that complexity (the scaling bit) is actually implemented by the front end devs. I would assume that it's handled on the back end, but of course a UI like FB, used by 1.7 billion people, can't be an easy thing to design.

At least at Google, "front end dev" extended down to the webserver tier, written in C++/Java. You were expected to make any changes necessary inside the webserver to complete your feature. That's part of what made hiring so hard: the number of devs who know Javascript and C++ and have their algorithms down cold is relatively low.

I imagine it's fairly similar at Facebook.

Of course, that's not the definition most 'front end devs' fall under.

"[T]here's no real technical challenge in front end stuff"

I have the distinct sense that you might not have done much of this.

There might not be many esoteric algorithms to implement, but there is plenty - more than plenty - to do in terms of managing UI state and back end integration, especially if you have stakeholders who want to see a variety of complex UI manipulations happening in response to various business rules. Which can often be internally self-contradictory. In a DOM that delights in being uncooperative, pretty much . . . always.

Frankly, it's enough to make using Java or a C variant for typical back end work look like a walk in the park.