java

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-10-15

Final complete day: 2026-10-15. Attention was 0.4% — this entity appeared in 10 of 2,852 analyzed posts/comments in the seven days ending that day (21 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-10-14 02:56 UTCComment

   Hence *peer review*. It's not no-QA, it's peer-QA. Having one other human, at least, look over your work is the least we can do, not all we can do. I know that it would be great if every dev team had their own external QA team, but not even well funded orgs can always dedicate that many personnel to every project. If that was criteria, then in many cases, there just wouldn't be a project. On a team, we don't all spend our time in the same weeds. I may have spent all sprint in a tetris dream code hole thinking deeply about my cards, but my team mate is looking at it in PR with fresh, objective eyes. Importantly, they have a deep understanding of the systems involved and the context for the work so they'll notice things no disengaged third party would. It's also not clear to me how external QA would work in every context... some tribal knowledge is needed to do the job capably and it seems like a team mate is in the best position to evaluate it. It depends on us keeping each other honest, sure, but over time we can earn and deserve that trust. Do you have QA review every terraform plan? What about OS and server config files? Are they certified in every cloud platform and product any given team might tap? Can they recognize flaws in DB schema changes and migration scripts? Do they all know TS, C#, Java, and Python so they can properly understand the codebases they need to cover? Are they trained in security best practices? Are they going to be content to set aside all of this considerable skill just to be button monkeys running user scenarios in a browser by hand for a living? If they can do all of this stuff, they should be working on a dev team, and someone else should be QAing their work. One solution to this is to break QA up over the organization. A team can be responsible for their own code-level QA (if they have earned that trust) but still be overseen, monitored, audited, gated, etc. For example, security scanners can audit git repos, artifact repositories, cloud environments, etc. Enforcing change through a centralized deployment platform with controlled access prevents devs from directly manipulating prod environments. Raise the critical QA concerns high enough with capable gatekeeping systems and you don't need to dedicate staff to every team.

2. 2026-10-12 21:16 UTCComment

   Exactly, we don’t have to write assembly because we have tools creating new abstraction layers, such as higher programming languages, and our reasoning can be contained to those levels entirely. You don’t need to be able to read or write assembly to create, debug, maintain, expand a Java program. The same cannot be said about AI coding. AI, at least in its current form, doesn’t isolate you from code the same way compilers isolate you from assembly. While you can generate code with AI, you still need to be able to review it, you still receive other pull requests with code rather than AI prompts, you still maintain a codebase in code, it’s still the code that acts as a source of truth for the program’s behaviour, and you still need to navigate it when debugging issues. Therefore we still have to be able to distinguish good code from bad code. And there’s an issue with that - while senior engineers have already developed this sense by writing thousands of lines of code back in the days, junior engineers - less so, and they are also learning it slower simply because they don’t write the code manually. I see it daily at a big tech company myself. This wouldn’t be an issue if the AI isolated as fully from code - but it hasn’t happened yet. And I am not sure it’s going to happen in a foreseeable future, simply because AI is non-deterministic.

3. 2026-10-12 04:09 UTCComment

   I feel like this article is misleading somehow. There's a bunch of red flags in it for me. First of all, if you haven't graduated yet, I'm not sure I would consider you to be a junior developer. Perhaps an aspiring software developer intern. There is a difference. Also I would love to ask the original author some questions like: 1. What was the intern's master's degree in, did they specialize in JavaScript? Perhaps they were stronger and working with Java not JavaScript. I've actually seen quite a few programs focusing more on straight Java. 2. Did the student actually have experience working with JavaScript, or JSON objects? Perhaps they only had one class two years ago on JavaScript and I haven't been focused on that at all since. 3. Did you ask the student why they went to AI first? Perhaps it was something that they thought they were expected to do. 4. You mentioned that you had them working with vanilla JavaScript but then later on talk about using their framework. Which is it? If this is any indicator of the workplace expectations, perhaps the requirements are disjointed or out of alignment somehow. While this post is obviously sparking some valuable discussion, my question the motivations. As a problem solver, as I would hope most developers are these days, I wonder why the author didn't seem to investigate and instead decided to publish a whole blog post complaining about something that they obviously didn't have a whole lot of context around.

4. 2026-10-12 00:27 UTCComment

   I see this comparison a lot and I don't think it's valid Going from assembly to higher level languages was just another abstraction. AI is something completely different. You're not really abstracting away anything... Secondly, going from assembly to C was still imperative programming, and still deterministic, where AI is neither. And no, I don't think assembly coders of old felt any sense great loss like people are feeling now. I think they just moved on to newer languages, like we always have. C, C++, Java, Kotlin, etc... I've used them all over the last 30 years... Never felt any loss like I do now. Anyway, C programmers still use assembly from time to time. Sorry, but I don't think its a valid comparison.

5. 2026-10-11 17:25 UTCComment

   Java gave me nightmares in grad school. Especially as we built with Jakarta EE, Java 8, and GlassFish. So it was so verbose and all over the place. However with Java 21, which I know is slightly behind, it’s way more fun to write code especially considering the use of lambdas. I guess TypeScript has prepared me as well for this second Java mission in that I now appreciate strict typing. Slopping AI code during the day has thought me one thing: I don’t want to have to read verbose code when simpler implementations would have sufficed. Many times I need to refactor code to its simplest form.