• Solve the problem directly in front of you. You are not as good at predicting the future as you think you are. (aka: YAGNI)

• Organize your code around the problem domain, and name things accordingly. As a basic razor, consider someone seeing your codebase for the first time – they should be able to easily glean what your app does, not just what language (Java) or frameworks (Rails) or design patterns (MVC) you might be using.

• Each function must Do One Thing. And yes, each test case is a unit, too.

• It must be clear to someone reading a function call what is expected to happen. Only use positional arguments when this is true and when order matters and is reasonably intuitive. Otherwise, always use named arguments.

• Your tests must run quickly. Your code must build quickly. Your CI/CD pipelines must be measured in seconds, not minutes or hours.

• Take nothing for granted. Declare all dependencies, and avoid implicit globals.

• Use a linter, and enforce compliance. It doesn’t matter what the rules are, but once established, avoid changing them.

• Never isolate yourself from your team for too long. If you’re working on a multi-day implementation, check in with the people who would be reviewing your code at least every couple of days. The longer you isolate, the more exhaustion and conflict you can expect during review, for both you and your reviewers.

• Learn to work iteratively, validating minimal implementations that fall short of the full feature as requested, but which build up to it. As opposed to One Big Release. It helps everyone to experience and validate early and often how the feature feels and whether it’s the right direction.

• Never rush. Always take the time to build properly. Your professionalism and expert opinion is non-negotiable, even if (especially if) there’s a deadline. I’m not saying to say “no” – rather, just give honest estimates and offer functional compromises or alternatives when possible. Never “try” to do more than is reasonable.

A lot of this, I attribute to Martin’s books (“Clean Code” and “The Clean Coder”) and his Laracon talk from several years ago (you can find it on YouTube).

Every now and then this question comes up. It’s a timeless software engineering conundrum. Kind of like how med students might start to think they have all kinds of diseases and conditions because they’re learning all these symptoms.

Software engineers, especially new ones, tend to be heavily biased toward applying technical solutions to non-technical problems. Most never actually grow out of this.

I’ll advise what I advise every time someone approaches me or one of my peer groups with this very question:

Get yourself a notebook and a pen.

I’m dead serious, not trolling, and not some kind of technophobe zealot.

When it comes down to it, if you let go of what you think you need in a to-do list app, you’ll find that what you actually need is much simpler.

Notebooks are e2e encrypted. Self hosted. Offline. As ephemeral as you like. Indexable for search. Versatile. Take a picture of a page if you really want to. OCR it if you need to.

Pen and paper.

Tor comes packaged with torify which you can prefix any CLI command with to have it route through Tor and resolve onion sites properly.

No, you’re not looking to understand. You’re looking to persuade.

love it.

Seems like something you may need to change in Transmission’s configuration, somewhere. Because it’s Transmission that is redirecting you and what you want is for that redirect to include the uri prefix.

Otherwise, I see two options:

• use a regex location block and match against all expected patterns
• use a dedicated subdomain (i.e: server block) for this (each) service you want to proxy and just proxy all traffic to that domain with a root location block.

The latter is what I would do.

Ohh, they must be using “trans” as shorthand for transPHOBIC.

SSH is all you need. You can clone directly from one .git directory to another.

e.g

git remote add desktop git@desktop:project/.git
git push desktop main --set-upstream

“Rep. Anna Paulina Luna (R-FL) blamed “hateful rhetoric from the left” for the killing.”

Every accusation is a confession. I never cease to be amazed how universally this applies to conservative-led discourse.

Not to be That Guy, but with kindness I offer a small correction: “out away” -> “outweigh”.

Exactly this. I doubt the effectiveness of a measure like this. Without enforcement, explicit and public cooperation from AI scrapers, consequences/accountability, and legal backing, it’s just theater.

The equivalent of a strongly worded letter.

It’s complementary to robots.txt.

• It’s weird that it’s XML, in 2025.
• It’s weird that it doesn’t use the .well-known/ prefix which has trended in the last decade for placement of files like this.
• It’s weird that it canonically uses the generic “license.xml” file name instead of “license.rsl” or “rsl.xml” or something that more clearly indicates its semantics.

But I do like the idea of having some widely adopted conventional way of expressing, in unambiguous terms, which usages are expressly prohibited, and that AI training is among them.

Good luck finding someone with all those qualifications, with at least three projects that meet all the criteria in their portfolio, and willing to work in NY for $100k. The caliber of candidate they seem to be looking for is easily worth over twice that.

That said, the market is full of desperate job-seekers who might take the bait.

The way this comment is written doesn’t sound anything like the OP or the GitHub issue. Different tone, different dialect/spelling… lot of linguistic red flags. Not that I’m judging either way, it’s just suspicious how vastly different they are.

Are the release notes AI generated? It reads like it.

In years past, I’ve used Elasticsearch and Kibana. The learning curve is steep and the system resource requirements warrant a dedicated machine, but once you get it dialed, it’s really effective as a centralized logging server.

Prometheus and Grafana are for time-series data (metrics), not logs. If you’re already getting that from netdata, don’t bother with these, as they’d be redundant with what you have.

syslog is about as idiomatic as it gets for log management in linux, but i don’t have enough experience using it effectively to give any pointers there. If you don’t really know what you want, yet, and just want to collect logs from all the things and see them in one place so you can begin to try and make sense of them and make refinements from there, then syslog seems like an excellent place to start.

I’ve installed Debian Linux on over 50 devices by now. A vanilla configuration with GNOME works pretty much out of the box for me on a high-end desktop with a modern NVIDIA graphics card.

I’d say the biggest part of the learning curve is figuring out which apps are good and suitable for what you’re trying to do. Just like with Windows and macOS and Android and iOS, there’s only a handful of viable options among an overwhelming sea of poor ones.

There are many wrong ways to install NVIDIA on any given Linux distro and architecture, and only one functional way. As others here are saying, that’s on NVIDIA, not you or Linux.

General advice: whenever possible, strongly prefer your distro’s standard package manager to install things over any other method. With Ubuntu, I believe that’s either apt or snap.

Also: if you find yourself poking around in some obscure system internals while troubleshooting an issue, you probably took a wrong turn somewhere.

RE autoscaling: effective distributed systems design isn’t really language-dependent. Java apps can scale just as well as ones written in Go. That said, I can see there being a case for Java apps not making it as easy to build that way. There’s definitely a lot of mainframe/monolith-oriented patterns in both the standard library and in enterprise Java culture.

As for the job market and career investment, I’d say this:

• Keep investing more deeply in what you’re good at. That’s your foundation and what sets you apart.
• Avoid chasing the “next big thing” based on speculation and trends alone.
• The next step in your career hinges more on your ability to think and design at higher levels than it does on lateral moves to another programming language.
• Explore languages and technology that you think are interesting, relevant, or can provide value or elevate what you’re already doing. The main benefit of doing this is to engage your brain differently and encourage change, improvement, and growth. This will indirectly improve your work and help your career.

I’ve written a lot of Java in my career and studied it in college, and I’ve written one app professionally and several hobby projects and utilities in Go. There’s a lot to like about it, regardless of its marketability on a resume.