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.
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.
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.
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.
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.
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.
The right answer to this, as usual, is probably somewhere in the middle. Perspectives like this are pessimistic, but important because the industry has age bias and yet we need to understand where technology might be going full circle. But instead of taking that as a bad thing and stopping there, we need to understand why and how the context is different this time and what that means. Managed services in general seem to be the ultimate cloud computing offering so far, and aren't reinventing the wheel. They are expensive and costs can be hard to reason about (probably on purpose), and cloud computing companies are profiting greatly from inefficiencies, but they take care of entire categories of operational concerns. This feels like the natural progression of the field. We can take advantage of these things selectively while being conservative in when and how we adopt them.
Complexity is a difficult topic, not the least because the many ambiguous meanings it has taken on. When people bring this up, they talk about it like it's a fixed thing that could go to 0 if only someone actually tried hard enough. Yes, complexity is a problem, but that complexity is always increasing is inevitable as long as technology advances. The first episode of the 70s series "Connections" comes to mind. We need to be able to identify and eliminate waste while dealing with this fact.
Specifically, performance optimizations and reliability improvements. More generally, applying my most unique and valuable skill set compared to the people I work with and advocating for good design decisions toward those ends.
I think you've been a role model in how to build and maintain a popular software project while keeping the spirit of FOSS and promoting a positive community around it. I look forward to seeing what you get up to next.
Fuck anyone callous enough to take something as far as an onsite trip with the pretense of a job and then just ghost them. I can't think of a much clearer way to show that much disrespect of someone and their time. And that's just the tip of the iceberg in this case. Remember things like this whenever you see the "microsoft <3 linux" slogan and the rest of the PR facade people are all too willing to swallow.
I briefly looked over this project when this link first popped up and didnt think much of it, but then i was surprised to see this huge surge in votes. I dont do much in the javascript and related world - can someone explain what in particular about this project has generated such interest? Even after reading the top comments, I feel like im missing the bigger pitcure.
A capitalist blames a lack of demand for the deep socioeconomic flaws that disasters like this shine an ugly light on. By his logic, if people wanted these things, capitalists would be able to make a ton of money off of them, and so it's everyone else's fault for not creating the demand.
And I don't know the original quote, but the idea that "capitalism is how we take care of people we don’t know" is a hilarious feat of mental gymnastics to frame such a inherently self-centered economic system as some sort of inherent altruism.
He challenges the public sector to make better things than the private sector without even acknowledging the massive and growing asymmetry in the resources available in the private sector to accomplish these things.
And lastly he attempts deflect criticism like mine by writing off any counterpoint as "attacking" his ideas and instead asking we talk about what we would "build" and therefore take his deeply biased assumptions as axioms.
It's not the only factor, but to look at this problem without critically evaluating capitalism's role is like ignoring the elephant in the room. Now that we are in a point in time where the more wealth and power is being accumulated by an ever shrinking pool of people, capitalists like Andreessen have more power than ever to employ these kinds of changes. If the supposed demand is not there, then maybe take that one of many signs that capitalism is a dead end.
How timely. I found this series after watching The Ascent of Man, which I found after watching Cosmos. Highly recommend all three, especially the Ascent of Man.
James Burke has a way of conveying a sort of fundamental optimism about society that I find invigorating. I remember listening to an interview with him from the past couple years and after all this time, he still sounds as sharp as ever.
"Why? Because coding a percentage in COBOL would take an estimated five months."
Five months to code a percentage, or five months to add the calculation, integrate that data point with other systems (does this need to be shown as its own field on any unemployment forms or reports? etc.), test it to the point where it has been demonstrated stable enough to be included in a critical system, and then deliver this change?
I don't know the first thing about COBOL but the fact that government is (for good reasons) slow to move, the stability needed in critical things like unemployment processing, and all the other things that go into "coding a percentage", explain that timeline a hell of a lot more than what language was used.