I had to integrate Azure Pipelines and wanted to shoot myself in the face. The idea that you are simply configuring a pipeline yaml is just one big lie; it's code, in the world's shittiest programming language using YML syntax - code that you have no local runtime for, so you have to submit to the cloud like a set of punch cards to see that 10 minutes later it didn't work and to try again. Pipelines are code, pure and simple. The sooner we stop pretending it isn't, the better off we'll be.
Plenty of discussion has been had around incentives and I agree with all that, but also there's another angle here: aside from dark patterns, I think the problems of terrible front-end experiences are most prevalent in the middle of the bell curve - the front-end products developed by rather mediocre skill levels and budgets. Which is usually a pejorative, but thinking of it as literally in the middle, not great but not terrible, a wide range of skill levels where people are more or less competent at their jobs. These are where I start to notice the worst effects of the median trying to adopt the technologies and practices that high skilled developers at good companies with huge budgets are able to utilize effectively, or outright make themselves, especially when there is so much churn that being "up to date" with technology is like a pipe dream to most people. These median teams inherit all the complexity, but due to budget or time pressures, etc. aren't able to overcome it effectively to produce a product with high quality, and users feel the sluggish experience and bloat that comes as a result. This pertains to more than UI of course but eventually manifests to users that way.
Something feels wrong. The median should be able to inherit the benefits of technology produced at the high end without such inheriting massive costs.
The implication is rough, but it is part of the truth (not all of the truth). However, I will add that the anointed ‘high-end’, your lifelong long backend devs, devops, data engineers, etc are adding to the problem. Backend people taking up the frontend hat under the fullstack guise create tons of awful end results, and this is even more common because they already exist at the company and are given a blanket ‘competent’ rating (in other words, they get a chance to mess with the curve before anyone else).
All of this is part of the pervasive problem that your post is slightly tainted by (my attitudes are tainted by it as well), which is a general disrespect for frontend. No matter, the truth of these attitudes will show up in all of our products. It’s always obvious to me which teams take frontend seriously and which don’t (the quality is always literally visible).
I do have a bias against front end development being from my perspective quite a mess, in the same way that physical scientists often look at the social sciences, though the social sciences are still quite important. But for what it's worth, I consider myself somewhere in that median band, and my perspective is motivated by and applies to front end as much as other parts of software dev/delivery.
I agree you can tell the difference, though I would place blame for those situations more on an organization than the developers who get shifted toward that work out of their specialization. It could be some dubious values, but it also could be project budgets.
I was a little underwhelmed by Tarkovsky's take on Solaris; the book was written with a lot more evocative prose, especially with respect to color, which made the film seem just so plain. But I really liked Stalker - then again I hadn't read Roadside Picnic. My understanding is that Tarkovsky's adaptations are usually quite different from the source material.
One small error (I think) - I noticed your link to pathfinder linked to someone's 2020 fork of the repository rather than the upstream servo repository.
Every time I am unfortunate enough to do something front-end it's just as bad as I remember.
Edit: professionally, that is; when I do front-end related stuff for myself, it's fine, but they are small and I keep things simple - vanilla JS where needed, etc.
What do you remember? These days I’m no longer concerned about `this` pointing to the wrong object. Importing files is a huge step forward from when I started. The standard library has grown; a bunch of Lodash isn’t needed anymore because of it. Promises and async/await. Even just template strings! So glad I don’t have to concatenate with pluses and watching my double or single quotes.
I was thinking the same thing as I was reading. Seems like feedback lag while drawing brush strokes would be frustrating for an artist. But then again, we have examples of surprisingly good response time in the game streaming world.
Like anything it's going to heavily depend on latency to the workstation in question. With cloud providers that have reasonable region coverage, it's not really that bad. In our tests, ~40ms latency is the upper bound of where you want to be before artists start really complaining, and Teradici themselves suggest 25ms for optimal results. However, depending on the task said artist is doing, you can venture above that, though for Cintiq/pen displays it becomes pretty painful and a "live with it" type deal.
Motivation from within is the strongest, and requires that work be aligned with personal goals, either in developing skills or making something happen. In these conditions, I've found that I'm at my most productive no matter where - I'm working against the clock to realize my own ambitions within the many constraints of my job.
However, this could simply be a mental health thing in anyone's case. There is nothing to lose and nothing to be ashamed of by consulting a professional about it.
How much of this is specific to Kubernetes and how much is more accurately because you moved from managing your own VM infrastructure to using managed services? Cloud providers have (often long had) ways of saying "run this code" without managing a VM and without involving kubernetes, including with docker support. And they are often very easy to use though not without their faults. An example being Azure app service.
I do agree that kubernetes is a pleasant experience from an application developer perspective with an existing cluster, but in my experience it was not without excessive pain and long hours by those administering the cluster. A year doesn't surprise me in your case, which brings to mind this question.
