The main things a social media presence does is give exposure, which can then lead to interest and [mental] investment.

Without those things, the game disappears in a mass of titles on a huge platform. How are people supposed to find it? Luck?

Even if it’s a good game, it’s a harsh environment.

Traditionally, publishers did promotional work to increase exposure. If you publish as an indie onto Steam, without an exposure strategy, you have to have an exceptional product or exceptional luck to be successful.

I can empathize with their frustrations though. Working long and hard on something, especially if it’s a good product, being satisfied with just the fact that it’s a good product, with no/little audience, success, or financial success, is hard to swallow.

The strength of open-source

“Killing” seems like an inappropriate term for end-of-support though. That’s clickbait to me.

How do you intend to present your GitHub portfolio to your potential employers? Nobody’s going to do a full, in-depth, or even basic analysis of your repos unless maybe with automated tools or what GitHub itself provides.

Your CV and interview are much more important. Solutions [and projects] matter much more than details. Experience and that you can talk about your work or experience is much more important than technical details.

A hash table library doesn’t sound like particularly noteworthy expertise. Adding a dependency and calling simple documented methods on it in a simple, standard behavior manner isn’t noteworthy.

If you’re implementing your own, I wonder if “simply” implies a non-noteworthy implementation, or in-depth exploration of hashing and storage indexing. The latter would be a different project though, putting your other on hold.

I don’t see it making a difference for employers what you pick here specifically.

If you’re interested in implementing one or learning about the technicalities of it go ahead. Otherwise use a library and continue with your project or other interests.

Disclaimer: I’m not in the recruiting space nor do I have that much or recent experience being interviewed/the broader companies hiring processes.

Yes, every unfamiliar language requires some learning. But I don’t think the bash syntax is particularly approachable.

I searched and picked the first result, but this seems to present what I mean pretty well https://unix.stackexchange.com/questions/248164/bash-if-syntax-confusion which doesn’t even include the alternative if parens https://stackoverflow.com/questions/12765340/difference-between-parentheses-and-brackets-in-bash-conditionals

I find other languages syntaxes much more approachable.

I also mentioned the magic variable expansion operators. https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html

Most other languages are more expressive.

OP could pick any language and have the same problem. Except maybe Python, but even that strays into symbolic line noise once a project gets big enough.

Personally, I don’t see python far off from bash. Decent for small scripts, bad for anything bigger. While not necessarily natively available, it’s readily available and more portable (Windows), and has a rich library ecosystem.

Personally, I dislike the indent syntax. And the various tooling and complexities don’t feel approachable or stable, and structuring not good.

But maybe that’s me. Many people seem to enjoy or reach for python even for complex systems.

More structured and stable programming languages do not have these issues.

that assumes you don’t write any SQL

I love the description as well. “One.” “Zero.”

I found the comments/answers about backwards compatibility of not defined booleans and negative true interesting and plausible.

What I first thought of was that TRUE and FALSE can be redefined, so it serves as ensurance that within the library consistent values are being used no matter what other libs and callers do with their typing and definitions.

Microsoft SQL Server has a bit type and you always use 0 and 1 and cast/convert them. No native bool type. It’s a hassle.

In your own description you added a bunch of considerations, requirements of following specific practices, having specific knowledge, and a ton of environmental requirements.

For simple scripts or duck tape schedules all of that is fine. For anything else, I would be at least mindful if not skeptical of bash being a good tool for the job.

Bash is installed on all linux systems. I would not be very concerned about some dependencies like sqlite, if that is what you’re using. But very concerned about others, like jq, which is an additional tool and requirement where you or others will eventually struggle with diffuse dependencies or managing a managed environment.

Even if you query sqlite or whatever tool with the command line query tool, you have to be aware that getting a value like that into bash means you lose a lot of typing and structure information. That’s fine if you get only one or very few values. But I would have strong aversions when it goes beyond that.

You seem to be familiar with Bash syntax. But others may not be. It’s not a simple syntax to get into and intuitively understand without mistakes. There’s too many alternatives of if-ing and comparing values. It ends up as magic. In your example, if you read code, you may guess that :- means fallback, but it’s not necessarily obvious. And certainly not other magic flags and operators.

As an anecdote, I guess the most complex thing I have done with Bash was scripting a deployment and starting test-runs onto a distributed system (and I think collecting results? I don’t remember). Bash was available and copying and starting processes via ssh was simple and robust enough. Notably, the scope and env requirements were very limited.

Let’s put a story point estimation on that. Then we can extrapolate time range and risk.

Really cool

I see; it’s not button keys, but axis inputs

/edit: Apparently not just axis, but “3D” / free joypad/stick

There are two very distinct ways of developing software:

I read this as a claim that there is only two. Which seems to match the overall flow of the document, describing only two, and then arguing between those two as if only those two exist.

No, that’s wrong. Especially those two bleak, described extremes. They’re not the only ways to develop software.

The thing is, most humans are laughably bad at architecting software without actually writing it first. […] Agile development “fixes” this. You get to discover your spec on your user’s time and end up releasing faster. In the end (and oddly so if this were the 90s), fast food is indeed faster to make. But is it worth it?

What the heck are they even talking about anymore. Now one is the only feasible one. But then neither are.

Now, by the end, I have no idea what this was even trying to argue. Meant as entertainment, following two theoretical development process extremes? Formulating in the extreme to make a point? None of it seems to apply. No conclusion is made at the end, instead falling further into anecdotes and unrelated, far away equivalences that make the whole thing even more confusing.

The pyramids didn’t respond very well to input either. So maybe the notes app should be running without responding to any modification requests.

That’s the kind of thing I suspect as well. Thank you for sharing your insight/experience. It’s always interesting and valuable to hear others experiences.

How’s it going so far?

The solution to this problem. . .

is that they have to create a support ticket with you, that you then put in progress, and you walk them through your documentation, and then log your time spent onto that ticket. (/s)

There’s an alternative to creating too many tickets that only add overhead and then make it harder to get into the project. Creating a good amount of tickets.

I took the OP reference as demand for ticket creation when they don’t make sense and only hinder development through unnecessary overhead. E.g. creating a ticket before a quick analysis, or creating individual tickets when one story/feature ticket would be enough. Or more specifically in this case, having to create one before fixing a critical blocker.

EoD? End of December? End of Death? (reference to world going to end)

man oregano => https://man.cx/oregano

oregano - GNOME application for schematic capture of electrical circuits

I doubt it is about that though…?