Agreed. Even self-reviewing a few days after I wrote the code helps me see mistakes.

"I'm capable of not making a fool of myself with UI" does not equate to "I'm a full stack developer"

Of course I don’t browse the web with the command line.

That's my point. Browsing the web with a command line tool is obnoxious - you use a GUI for tasks that you find easier/more pleasant to do with a GUI. The difference is where that line is. When I'm reviewing what work I've done and checking through my code for debugging statements and other cruft I don't want to push, I prefer to have a nice tree view of my change set where I can click on an item, see what I've changed, select lines and stage them, select other lines and revert them, etc. I could do all of that with command line tools (though not that many have mouse support) but I already know how to do exactly what I want with VSC so why would I use anything else?

You’re already programming! Just learn the tool!

If someone is incapable of learning the tool, that's an issue if they're a developer. But your statement implies that everyone should use the CLI for everything. My point is that it's a matter of preference. The CLI is not superior and GUIs aren't superior. They're both just tools and if you can get your job done quickly and efficiently, that's all that should matter.

I have 13 followers on GitHub. A few are friends from college, the rest I have absolutely no clue why.

Systems engineering is an established discipline, one you can get a degree in. It’s not just a random term I’m making up. https://en.m.wikipedia.org/wiki/Systems_engineering

I don’t think you really have a choice TBH. Trying to do something like that sounds like a world of pain, and a bunch of unidiomatic code. If you can’t actually support 4 to 10 languages, maybe you should cut back on which ones you support?

To be clear, the SDKs themselves are hand-written; I'm not trying to do anything fancy there. In terms of designing and writing the SDKs, we can manage that for the 4 we have now. The issue is testing. The main system is a collection of services that are accessed via an API. That API can be accessed directly through function calls, or via HTTP or RPC. Our integration tests interact with the system through that API. The SDKs have a moderate amount of logic so they're not simple HTTP/RPC clients, but maintaining multiple (idiomatic) versions of that logic is not too much of a burden. The issue is that I want a single test corpus that I can use to validate each SDK without having to rewrite that test corpus in each language. Ideally I'd like the integration tests to be that test corpus.

If neither of those approaches works, everything speaks C FFI, and Rust is a modern language that would work well for presenting a C FFI that the other languages can use. You’re probably not hot on the idea of rewriting your Go tests into another language, but I think that’s your only real option then.

I was assuming I'd need to rewrite my tests in Go given that Go's FFI support for anything other than C is not somewhere I want to go again. I have been meaning to learn Rust so I might just do that.

I absolutely prefer using an ORM for querying but I'm definitely never letting the ORM create the schema for me. I will always do that myself and generate the ORM definitions from SQL, and I will never use an ORM that doesn't have that as an option.

I wouldn't say it was a shit university, part of it is that I knew how to write code before I got there. But the CS program wasn't great. My entire point is, if someone has a CS degree from University X and you don't know if that program at that university is any good, the degree is meaningless. If the university's CS program isn't any good, you can't count on the degree meaning anything.

I like .NET, Visual Studio Code, and SQL Server. The rest is garbage.

Many people ‘learn programming’ only in so much as they know how to write code but they can’t solve a problem to save their life.

And while I wouldn’t say anyone is incapable of learning programming, some people certainly have a much, much harder time of it.

Are you saying the only good programmers are ones who aren’t aware of their worth and think they’re bad?

I’d have to be living under a particularly large rock to be unaware of that. “It’s memory safe” isn’t that big of a deal to me. Even building concurrent systems, memory safety has never been a significant issue for me with Go.