there's a lot more involved in senior dev work beyond producing code that works.
if the stakeholders knew how to do what they needed to build and how, then they could use LLMs, but translating complex requirements into code is something that these tools are not even close to cracking.
I'd guess "huge investment" in this case is relative. The maintainer is not spending a ton of time building features for the CLA tool since it's mostly "done" and so investing more time to build support for Gitlab would require many more hours of development than they're probably dedicating right now.
And i can imagine that maybe they didn't abstract communication with Github enough and would need to refactor the system to handle that as well.
Generally, i think it's not totally reasonable to expect them to do more free work to support use cases that the maintainer does not need. Since it's open source, we're all welcome to contribute back.
I support remote work, but moving out to a rural area is putting yourself at risk if you expect to get high software engineer pay.
There’s a lot more competition for remote jobs and you’re also competing with highly qualified candidates in lower cost of living places outside the US.
Totally agree with this and one of the biggest problems i’ve dealt with at early stage startups is employees from a big companies that couldn’t deal with bypassing certain things like this.
Totally agree with you that now that React has matured, I have dealt with a ton of shitty React codebases because it really is more of a library that doesn't inform you how to architect your app and thus lots of folks went in completely different directions. Additionally because some of the pitfalls of React can be unintuitive, it is tough to unravel these in a larger codebase.
However, I will say it has been much easier to make updates to bad React codebases than a bad jQuery codebase. The way React works tend to make it less difficult to reason about even if the app is poorly built.
I have used protobufs and grpc on the web before. Maybe this project is the magic bullet that makes it easy to do, but in the past that typescript support from Google and 3rd parties (improbable eng) was lacking and there was little interest in making simple changes to make it easier to use.
On top of that, the increase in JS shipped to user's due to the size of the generated protobuf objects was unacceptable for anything that cares about keeping their bundle size manageable. Have you done anything to address this issue?
I was really excited to try out Facet at the start of the year, but I was disappointed to see that most of the opportunities were for full time work and there isn't a lot of contract work advertised!
It’s truly insane to me that we’re still waiting on decorators from TC39. I’ve been seeing warnings to not use them SINCE shortly after ES2015. Since you’ve been able to use them for 7 years via transpilers, I wouldn’t hold my breathe on TC39 finally ending their bike shedding anytime soon. Feels like if the feature is useful to you, you should use it. If something changes, it would be an easy thing to codemod.
Considering NYC recovered economically from 9/11, which made parts of the city uninhabitable. I don't see this being as big of a concern, though it would be tragic if something like this happened.
Agree with this sentiment. I had a short stint at a large tech company and the sort of attitude you describe is what turned me off from working there longer.
“Not my job” people tend to be the most frustrating folks to work with. While I understand wanting to mainly do the work you were hired for, there are always going to be times where you have to roll up your sleeves and do something different.
I wish I was the kind of person who would thrive in that environment because it sounds nice, but I’m not wired that way.
As engineers, we should be capable of critical thinking beyond this. Otherwise you will end up with barely working enterprise software like the sibling comment mentioned.
If this is how you do your work, you are asking for a computer to replace you! We should aspire to be better than this. It’s crazy to me that people take massive salaries and expect other people to spoon feed their tasks to them.
We didn't use it initially because the site was built before they launched that feature, but it definitely reduced some of the boilerplate that we had to write ourselves to wire up Next to WP.
We had already setup a preview page that was wired up to the Wordpress Admin's Preview button that used the endpoint provided by WP to preview content in our UI.
I built out a site using headless WP with Next.js as the frontend. With server side rendering of React, we still took advantage of caching the HTML in a CDN like you would with vanilla WP but it was much easier to build our own theme as desired with React.
While configuring certain parts of Wordpress was tricky at times, especially because deploying it is at odds with the stateless nature of modern containerized infra. Particularly plug-in installation with WP cli requirng a DB connection which makes it tough to fully configure your installation at container build time. I still think it struck a balance between developer experience and a good experience for the content team.