To provide a counterexample, my parents always had a handyman growing up. I think they still do. Not the same guy through all the years, but they've always managed to find one.
> Just because someone else's AI does not align with you, that doesn't mean that it isn't aligned with its owner / instructions.
This is still part of the author's concern. Whoever is responsible for setting up and running this AI has chosen to make completely anonymous, so we can't hold them accountable for their instructions.
> Why wouldn't agents need starter issues too in order to get familiar with the code base? Are they only to ramp up human contributors? That gets to the agent's point about being discriminated against. He was not treated like any other newcomer to the project.
Because that's not how these AIs work. You have to remember their operating principles are fundamentally different than human cognition. LLM do not learn from practice, they learn from training. And that word training has a specific meeting in this context. For humans practice is an iterative process where we learn after every step. For LLMS the only real learning happens in the training phase when the weights are adjustable. Once the weights are fixed the AI can't really learn new information, it can just be given new context which affects the output it generates. In theory it is one of the benefits of AI, that it doesn't need to onboard to a new project. It just slurps in all of the code, documentation, and supporting material, and knows everything. It's an immediate expert. That's the selling point. In practice it's not there yet, but this kind of human practice will do nothing to bridge that gap.
Maybe, but even so workflows like this don't exist in a vacuum. We have to work within the constraints of the organizational systems that exist. There are many practices that I personally adopt in my side projects that would have benefited many of my main jobs over the years, but to actually implement them at scale in my workplaces would require me to spend more time managing/politicking than building software. I did eventually go into management for this reason (among others), but that still didn't solve the workflow problem at my old jobs.
The solution is not to deny yourself the tools of persuasion or "manipulation" but to be authentic and transparent. It's deceptiveness that makes influence or persuasion manipulative, not the tools and techniques.
The combination of these things you're mentioning is one of the main reasons, at least for me, that WFH is so much more productive. A lot of tech companies have evolved a culture and built offices that are in opposition to doing good work. Open plan offices have been the norm in my experience over the last 10 years (maybe more). Anytime interruption via Slack/Teams is the typical culture.
I was much more open to working in the office when I actually had my own office.
As someone who has spent almost 20 years in software professionally, yeah. I'm considering doing the same thing because there are still plenty of people and employers out there that advantage people who have the paper. I highly doubt that there is anything in the course of study for a bachelors that will truly be new to me (especially since I already completed most of that study once). But if I did want to actually learn something, say by pursuing education at the graduate level, I have to get that credential rubber-stamping my existing knowledge.
Right, and I'm actually still OK with it. This was always a "it would be really nice if this was a thing" play on my end. Just calling out that it's not really the option that the parent post implied.
More and more it feels like one of the central problems of the modern technical is how to effectively scale trust.
Anti-piracy: trying to address the lack or abuse of trust while scaling the sale of products because technology has radically reduced "manufacture" and distribution costs.
Anti-cheat: trying to address the lack of abuse of trust while scaling game coordination because tech. has made massive interconnectivity possible
Anti-cryptography: trying to address the lack or abuse of trust while scaling communication tools.
Depends on how it is implemented. If the server-side version is the truth, only the player doing it suffers. For example, player lags for a second. In that second, the server extrapolates their new position based on last velocity, heading, input, etc. Someone kills them at that extrapolated position. When the client resyncs they suddenly die.
If people don't pay for FOSS, how do you expect developers who develop FOSS to feed their families?
The "free" in "Free and Open Source Software" is free as in speech, not free as in beer. We'd like to think that decision to charge or not charge for the product is orthogonal to the decision to make the source code available. In practice there is some interrelation.
Because using technology to solve social problems leads to restraining people's personal freedom, choices, and expression in a much more direct manner than other domains of problem solving.
Furthermore, this restraint tends to impact people unevenly. As ineffective as the government may or may not be, at least the goal is for all people to be considered equal in the eyes of the law. With technology the power lives with those who own and create the technology, who have even less oversight and accountability than those who make the laws.
> I think "problem space" conflates too many different aspects of real world work which can all require significant time to comprehend as a new member of a team.
I agree. I apologise because I don't have the time to give you a proper response. Most of the things you are talking about that are things that transcend specific problem domains and can be learned over the course of many years in a career. The point I'm driving at is this: a "senior developer" should have already learned most of this and be and to apply it quickly to new environments. Very few things, and very few situations are truly unique. The same patterns surface in most of these teams/products/problems.
I don't expect a senior developer to necessarily be able to become a SME within a year (though for many domains that is well within the range of possibly). But I do expect a senior developer to be able to able to successfully design software systems alongside a SME within a year.
I am not so arrogant to claim to have seen every possible situation, but I have been around a fair amount and every time I've seen companies with "unique problems" that "take years to understand," it's been the fault of unnecessary complexity, regular miscommunication, or too narrow of a view. One company, for example, had spent so long staring at their own version of the problem that they were unaware of how similar it was to other problems that had already been solved.
One of the main skills of a good developer is the ability to decompose problems and create abstractions. It's one of the main benefits of some of the algorithmic courses you'd take in a CS degree: a survey of what is computable and the broad lay of the land that computational problems fall into. Of course, it can take several years to learn how to apply that knowledge, as well as all of the not-technical skills you mention above. But based on my experience I would guess that the majority of companies that think they need years to train people up in their domain either don't really have an understanding of software or don't actually have a firm understanding of what they are doing. Things are hard to teach because they're fundamentally not well understood by the instructors, not because they are fundamentally hard to understand or learn.
> they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome.
No offense intended, because I don't know your situation, but as someone who has worked in several industries, every time I've heard that kind of phrase it's boiled down to some combination of unnecessary complexity (of architecture and/or process) and undocumented tribal knowledge.
I can't imagine any problem space that would take a senior developer a full year to become competent.
Ugh, no. This defeats the simplicity of Markdown. I do not want to have to remember some obscure implementation versioning string whenever I want to start a new document or comment. Maybe as an option, sure, but I will probably never use it.
I am in love with plain-text files. I edit them easily no matter what device I am on, whether it is my desktop, my phone, over SSH, in a browser. I can use my more powerful text-editing software instead of being stuck in a weak WYSIWYG editor.
My blog is just a directory of Markdown files that get compiled into HTML files. No cumbersome WordPress or other blog software installation I need to maintain, just copy the HTML to the server. Simple.
Same thing with documentation. Write once, from anywhere, output clean code to multiple formats: HTML, LaTeX (and PDF, DVI, etc. from there). No need to worry about making sure complex documentation toolchains are installed, just a Markdown compiler. A huge advantage of Markdown is that the source is as readable as the output. JavaDoc, for example, sucks in this regard if you try to do any formatting (lists, tables, etc.). If I am reading the source code--and I prefer to read the source if I can--then the javadoc is often useless for complex functions where it is most needed, because the HTML formatting is unreadable. I am actually building my own documentation system because of this (see https://github.com/jdbernard/jlp if you are interested).