Reminds me of BSON

If only this post title had received descriptive text too

You don’t need to escape any content for storing in a DB field.

Use the correct database interface and you’re good.

I’d be more concerned about intention and intentional design. Arbitrary characters can be misleading or problematic for users. Using an allow list for accepted username characters is a good approach if you can’t depend on good intentions of users.

deleted by creator

Interesting take I can’t agree with. Maybe their product environment is very different.

once the feature finally arrives in production after a lengthy review, it is in truth no longer aligned with the user’s needs.

I’ve never had this happen in my development.

In my team, it’s fine to skip reviews and commit on main, when it’s reasonably small and confidence is high. An obvious and small change also does not take up much time to review.

The effort put into creating a well-/reasonably-described review is effort put into well design changesets and Git history. It helps you cover all bases, cases, and considerations while developing.

Review necessity, investment, and urgency are dynamic. If you as a reviewer don’t have the time of mindspace, saying so is fine. Reviewers can be changed or skipped. Reviews can be to different depth and completeness, or partial.

Be mindful of what is reasonable and efficient and reviews are not hard blockers beyond what they should reasonably be. Reviews serve as significant quality, issue, and common understanding gates.

I’m familiar and usually working with .NET, and am a strong advocate for it.

• The language is similar to Java, so not that difficult of a switch language-wise. Visual Studio makes good suggestions introducing you to newer and more concise syntax too. If you install the VS SonarLint extension it’ll guide you to good practices.
• Excluding the GUI for now; you can target cross-platform.
• GUI is somewhat of a mess like anywhere else, but you have decent options and you certainly have more viable alternatives compared to other languages. If your target is cross platform, check out MAUI for the recommended/officially suggested approach. I find the XML GUI coding irritating and inconvenient, but it is well-established and popular. Although I haven’t implemented a noteworthy project with it, I prefer coding UI in web tech, so I like that you can embed a WebView2 and connect and bind between the C# code and the HTML rendering. Using WebView2 for program GUI requires a container app window. Targeting Web/Browser-rendering directly is viable too with Blazor and more broadly ASP.NET with multiple alternatives and openness to web frontend UI frameworks and libs.
• With one project structure the project can be worked with with dotnet CLI (leaving users open to use their own IDE or text editor choice), Visual Studio, or Visual Studio Code. NuGet packages as dependencies are automatically handled within the default build toolchain.
• .NET is well-established and popular.
• Official documentation is great. It is exhaustive, with guidance, references, examples, and tutorials. It is open to feedback and change requests/suggestions.

As for what you tried, how I would personally react to a project:

I don’t like python. For anything that is not a script, I would likely skip considering contributing. It is an overall popular language though. Prevalent as a language, and at least reasonably popular / niche-popular for apps with UI.

C++ is a mess to set up and manage. Qt is huge. It’s popular and powerful. But in the aspect of low-barrier, it is the opposite.

This anecdote only works for some forms of lead experiences. Leading is not cooking.

From your description, my view is limited, there is no correct solution. Any choice is viable and fine, and any decision you make will be due to the reasons you chose with.

You didn’t disclose what the alternative opportunity and field is, and also not your view on the field and you in it. So it’s difficult to assess and put into relation.

You didn’t disclose what you did before work, but two years is not that much experience for an engineer. Especially if it is not a particularly nourishing environment. You gain such expertise through experience and exposure over time. Depending on the project and environment it’s also not enough to fully understand and intuitively know a big project.

At my workplace we separate role from [personal] development level. As a developer one’s role may be developer or lead developer. The development stages are Trainee, Junior, Professional, Senior. If you can work on tasks mostly self-reliant (asking and collaborating is still open of course; knowing when to ask is a skill too) and can put tasks and work into context, you are a Professional. A Senior can support and guide the team. It is perfectly fine to settle for Professional.

Not being exceptional is not a good reason to quit. If you work and bring value, that’s still value. Don’t decide whether you are valuable or good enough for others. (This leaves out the question of what it means for yourself of course. Tackle those questions individually.)

You say you get your work done. Continuing to do that at a Professional Developer rather than Senior level is fine. You still bring value.

I want to know if that’s what it sounds like to people who’ve seen that before. If you were in my position, would you walk away and just be a hobbyist programmer or stick it out and hope to be a mediocre engineer one day?

I really can’t answer that specifically.

You said your team environment is not the best. I assume you don’t do retrospectives or personal feedback. Is feedback something you could ask [of some of] your team members, lead, or seniors? (Take care not to poison your question for open feedback with your negative assumptions of yourself and your work.)

Where would you like to be? Separating what you think is expected of you from your expectation and view of yourself and from what you enjoyed and where you think you would feel comfortable settling, how would you lay those out?

Have you considered switching project or employer? You have only seen and experienced that place. A different work environment could be very different - even in the same field.

I hate popovers. This one not only covers the whole screen, it opens the virtual keyboard because of auto focus. So people actually subscribe like that? I don’t. I leave.

I didn’t use any learning resources. I lead from experience, mindful, by example, communicative. It comes naturally to me.

You said you had bad experiences. Doesn’t that conclude to knowing what to evade and what you would have wanted more of from a lead?

What is a SPAC?

https://en.m.wikipedia.org/wiki/Special-purpose_acquisition_company

If budgeting donations is difficult, maybe donating time is more viable?

Employees are already paid for. Less people involved to approve too.

If you have the autonomy you may even be able to to without explicit approval.

At work I use Jenkins, and I am very frustrated with it. I’ve worked with GitHub Actions, GitLab CI, and Azure Pipelines, and none were truly enjoyable to work with. They’re acceptable.

The last change I made on our project was to send a build failure and build fix notification email on branches to the last committer. (After having disabled branch build failure notification emails because Jenkins (or its plugins) were not able to send to only the branch developer/new change pusher/author a while ago.)

The best thing we did was introducing commit message conventions and convco to verify them, and to generate changelogs automatically.

It is warranted, and your colleagues seem to agree.

and other people on the team will almost always agree that it’s a good idea and will happily accept my PRs

I think you may be misinterpreting what is happening.

Them not taking initiative does not correlate to its importance. It’s just that most people don’t take initiative - or at least here, evidently, for naming consistency.

How much of an issue ambiguous naming is or may become depends on context - on a lot of things. But ambiguity in naming, just like elsewhere, weakens certainty and reasonability. If you can define and keep clear terminology, then always do so.

09:30 on my team. Between multiple project teams I believe our dailies are between 9:00, maybe slightly before too, and 10:00. Can also depend on the customer if we’re part of their development team. I believe not all teams have them every day.

It’s a good time for me because I sometimes begin at around 9:00.

At 9:00 begins our central working hours where we’re expected to be working. And I think that’s late enough for the late starters. So I like where we’re at.

I think it’s good to have it “early” rather than late. If you struggled the previous day it’s a good point of fresh start and possible discussion or follow-up support. It’s also where you have [to make] a plan for the day.

Depends on context.

Most of the interfacing is change based. But calling that diff is misleading.