hmillison

in reality the question is more so, can the AI do a "good enough" job to not be noticeably worse than a real person?

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.

The city of San Francisco is ~10% of NYC's population so it's not a good comparison.

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.

according to the article, Turbopack is 10-20x faster than Vite. I wonder how they were able to edge it out so significantly!

I would argue that Hanoi is more touristy than Ho Chi Minh so this comparison just tells me the author doesn’t know what he is talking about

That's great news! I missed that in my initial skim of the article.

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!

a lot of people living those lifestyles are living off of credit cards or their trust fund

NYC is one of the only cities in the US with quality transit and really the main one where it's easy to live car free in many areas of the city.

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.

Agree with this 100%. I've seen both in older codebases.

It's even more frustrating when you work with engineers who refuse to believe that any code they write could become technical debt in the future. These tend to be people who overcomplicate systems to anticipate future requirements

Agree with this, it's very important for engineers to own the quality and reliability of their own code. The team I was on that had embedded QA on each team had barely any unit tests because developers were used to relying on QA to catch bugs for them.

When I've been on teams without formal QA teams, the team was focusing way more on having good automated test practices in place.

This also applies from the SDET/SDE separation, which I see someone else in an adjacent thread mention. I've found a lot of value from taking ownership of both the code and the automated browser testing code. I found when those roles are separate, the browser tests end up breaking too often due to developers not being aware of how coupled they are to the current implementation. I also found when a dedicated team is writing browser tests, it becomes easy to go overboard with how much you test.

Other interesting aspect is that they get paid to build features for the browser by companies that want to drive the direction of the web platform.

https://blogs.igalia.com/mrego/2017/03/16/css-grid-layout-is... - Bloomberg paid Igalia to implement CSS Grid in Chromium and Webkit

I thought it was weird to feature Clubhouse when the app launched fairly recently. Feels like this article is a way to market them?

Having just been through the interview process, i ended up having to go through a few coding challenges. Luckily for me, i never got “ghosted” after sending one back.

The important thing to me is that the coding challenges have a reasonable scope. I really appreciated two of the companies that gave me an already set up project (it was not their actual codebase) and then required me to build an addition to it. That feels like an accurate way to test someone’s skills.

As someone who doesnt excel at some of the “leetcode” interview questions as much. I have found challenges to be a welcome alternative when done right.

I did experience some companies who would give a project that was wayyy too complex and they estimated it would only take one hour. Those are the places i would reject without doing it. With the market as competitive as it is, you need to have some limits with these things.

Totally agreed. Unfortunately (and fortunately, depending on how you look at it), there is no single benevolent dictator of JS to help you make your decision like in other communities.

I think this quote from this article is a good summary of this discussion: "Scala people don't have time for redditing and blogging, they're busy getting crap done."

While it might seem like all the JS devs are arguing on here over their choices, there are many folks who are silently being incredibly productive with whatever tool they choose.

Really disappointed they removed all of advanced filtering features (commute time, neighborhoods hightlight, some others i don't remember) that made it the best app for apartment hunting

Do you just create a bootstrap-theme to make it look unique?

I'm interested in learning more about how to take advantage of the good parts of bootstrap without having a site that looks too much like vanilla bootstrap.