5 with reasonable acceptance and use, even advocacy, for up to 1. I don’t see a difference between 4 and 5, though.

Reviews should be the norm. Even for simple changes, a simple code change should be simple to review and approve, too. At the same time, some formatting changes or small or minimal changes with high confidence can be pushed to main without review - that’d be just wasted time and effort on the reviewer’s side. High urgency can also warrant an immediate push to main, or live hotfixing on prod if possible, with a corresponding PR still open.

It’s a tool that adds yet more complexity to our profession. More choice, more cost-benefit-analysis, more risk assessment, more shitty stuff to inherit and fix, more ability for shitty code producers to hide incompetence, more product and data policy analysis, more publisher trustworthyness and safety analysis, more concerns regarding what tooling sends into the cloud and what it can access and do locally, a significant “cheap and fast solution” you will be compared against requiring more communication, explanation, justification, new attack vectors to protect against, …

My team and some others [can] use Copilot at my workplace. I haven’t had or seen significant gains. Only very selectively. Some other senior devs I trust are also skeptical/selective. We see the potential opportunities, but they’re not new solutions. Some other colleagues are more enthusiastic.

What it does is make me question bad code from review request authors. Whether they missed it, are this unobservant, or incapable, or used AI. Quality, trustworthyness, and diligence are concerns anyway, but now I can’t really assess how much care and understanding they actually take, if they’re misled, take shortcuts, and how that changes over time - other than asking of course.

I’m not scared for my job. It already changed the field and industry, but not in a net quality productivity gain. And will continue to in one way or another. There are many parts of and surrounding software development that it can’t do well.

I obviously don’t know your environment, but I don’t think a manager needs access or knowledge to git to effectively manage teams, hear and understand team member concerns, and to steer guidelines and guardrails.

if I could stay later when there’s broken things in prod

In general, or on this instance?

Do you have team retrospectives? That’s where I would bring it up in my team. Raise my concerns, explore and understand what team consensus is around this topic, around risks, quality, etc.

If the team consensus and/or management consensus is YOLO - then I try to protect myself from personal investment and going beyond contractual obligations. Because I already know what will come and how it will negatively affect me personally.

It’s possible a honest discussion with management about goals and risks could lead to clarified guidelines, requirements, and goals. If it doesn’t, I’d probably be looking for a better job/environment. Because I’ll be miserable if colleagues YOLO, no matter how careful I am personally.

Some people are more receptive to these kinds of things than others. Not only in terms of open mind but also how they are able to apply it (or capable of applying it?).

I wish agreeing on intentions and improvements in terms of scoping and description would be met. Same with unnecessary, obvious issues showing up costing review time and iterations. I just don’t get how these are issues - but they are - for or with some people.

I never thought I would move away from FOSS/AGPL by default. The more I read about this issue, the more I consider providing free services instead of FOSSing. It’s a shame.

FOSS is still important and necessary to a degree, for auditability and self-hostability, very important for security and control, even as a conscious/careful user.

Maybe this puts us more towards “pay to free the code” or something, so there is at least some compensation. Won’t make verbatim regenerated AGPL to MIT any less hurtful though.

If you publish a free service, at least they’re not feeding from your code too.

Tragic.

I find “from scratch” a questionable claim as well. The model was probably trained on the code it is supposed to replace. Interfacing with the concrete tests and interfaces makes the result even more likely to be and puts it conceptually closer to the original code fed as training data.

The CLA can never override the code license. It handles the transition of your code into their code, and what they can do with it. But once it’s published as AGPL, you or anyone else can fork it and work with it as AGPL anyway. The CLA can allow them to change the license to something different. But the AGPL published code remains published and usable under AGPL.

I’m usually fine with contributing under CLA. A CLA often make sense. Because the alternative is a hassle and lock-in to current constructs. Which can have its own set of disadvantages.

A FOSS license and CLA combination can offer reasonable good to both parties: You can be sure your contribution is published as FOSS, and they know they can continue to maintain the project with some autonomy and choices. (Choices can be better or worse for others, of course.)

I’m a bit confused by them publishing their personal essays on their htmx project page. This essay certainly doesn’t have anything to do with htmx directly. Either way, valuable content and possibly their strategy to get people to htmx, or reuse a domain and website they already have.

abstracting away determinism /s

The article doesn’t even mention this critical risk and history. Huge gap.

Think about whether TODOs will be revisited, and how you can guarantee that. What do you gain and lose by replacing warnings with TODOs.

In my projects and work projects, I advocate for:

• Warnings and TODOs are fine only in initial development before release/stability and in feature branches during development
• TODOs are almost never revisited, so document state and information instead of hypotheticals; document opportunities over TODOs, document known shortcomings and risks, etc
• If there is good reason to keep and ignore warnings, document the reasoning, and we can update our CI/Jenkins quality gate to a new baseline of accepted warnings instead of suppressing them (this pretty much never happens)

Dotnet warning suppression attributes have a Justification property. Editorconfig severity, disabling, suppression can have a comment.

If it’s your own project and you know when and how you will revisit, what do you gain by dropping the warning? A no-warning, but then you have TODOs with the same uncertainties?

We onboarded our team with VS integrated Copilot.

I regularly use inline suggestions. I sometimes use the suggestions that go beyond what VS suggested before Copilot license… I am regularly annoyed at the suggestions moving off code, even greyed out sometimes being ambiguous with grey text like comma and semicolon, and control conflicting with basic cursor navigation (CTRL+Right arrow)

I am very selective about where I use Copilot. Even for simple systematic changes, I often prefer my own editing, quick actions, or multi cursor, because they are deterministic and don’t require a focused review that takes the same amount of time but with worse mental effect.

Probably more than my IDE “AI”, I use AI search to get information. I have the knowledge to assess results, and know when to check sources anyway, in addition, or instead.

My biggest issue with our AI is in the code some of my colleagues produce and give me for review, and that I don’t/can’t know how much they themselves thought about the issues and solution at hand. A lack of description, or worse, AI generated summaries, are an issue in relation to that.

/edit: Here is my comment on the post four months ago.

And it’s so popular! It must be good!

This doesn’t seem programming-related. Am I missing something?

When I was researching keyboards recently, I stumbled over a pro gamer (I believe) YouTuber who was quite vocal about pretty much all gear marketed as “gaming gear” is overpriced marketing bullshit. Apparently, they tested dozens of keyboards, mice, and headsets over the years. It certainly matched my impression of reading tests about products previously.

“Gamer” chairs are racecar chairs meant to keep you from sliding sideways, not being fit for long sitting sessions on a PC. Prefer a good or decent office chair. “Gamer” headsets are worse and more expensive than other headsets. Keyboards and mice are mostly marketing. etc.

Regarding input, they made a point about physical human limitations and state like sleep and caffeine intake having much more of an effect than the hardware you use.

2022 update

So this article is quite old. There are keyboard switches now that activate as soon as you activate the key, and that can recognize lift and press without passing a trigger point. If you want that kind of edge, those are the top performers right now. I’d be more interested in the technology and maybe playful capabilities than the performance they add.

I’m always way too thorough when researching products before buying…

I thought I remembered a standardized metadata file format you can place on your website, but I can’t find it.

GitHub defines FUNDING

Brave webbrowser attempted something like that with Brave Rewards, but through ads, and basically collected for themselves until the websites actually signed up for Brave Rewards.

I remember Flattr.

“Yeah, I can do that task. I’m very experienced in struggling to implement stuff like that.”

I totally get that. Technical and implementation exploration doesn’t necessarily correlate with publishability. :)

I find itch.io to be a great resource not just for games as a “finished product” but for prototypes as well. The regular gamejams contribute to this - a platform of many prototypes. They don’t need the polish and coherence you’d want to invest and publish on Steam.

Have you considered publishing your prototypes?

Even as only a player, some prototypes make for very interesting playful exploration, even if it’s short. For a technological, creative, and inspiration they can be a treasure trove as well.