←back to thread

263 points mooreds | 1 comments | | HN request time: 0.208s | source
Show context
jorl17 ◴[] No.45421900[source]
My comment will focus only on a subset of the article: the part regarding AI.

While I agree with the sentiment that AI has changed the practice forever, and therefore it is pretty silly to forbid AI during interviews (much like it was always silly to me to forbid a candidate from googling something during an interview), I haven't really seen evidence that juniors with AI have faster onboarding times.

Onboarding, to me, is about having the new team member adopt the existing team's practices, such as learning preferred code patterns, communication channels, established frameworks, and overall just getting to truly be a part of the team (tech and non-tech team).

In that sense, AI has done very little to help. If, on one hand, AI can help us produce better documentation that will help with this process and studying existing libraries and practices better, on the other hand, AI also enables a new team member to seek others less early on (a point the article itself makes), which I believe makes the onboarding process (according to my definition) slower — i.e. less communication = slower onboarding.

As I mentioned, we can also relate onboarding to getting to know the codebase, in which case AI definitely helps (and as more code is written with proper AI engineering practices, it will help more), but I really feel that this is a small part of the equation.

Similarly, I think getting to know the actual domain of a project (the users, the requirements, the 'language', the problems, etc.) is an important part of onboarding and, again, AI helps here, but not a whole lot. It's about people, not bits.

Sure, if you hire a junior to get him to work straight away on a new project, the new hire will be "productive" faster (therefore seeming to have been "onboarded" faster) than before, because the AI does make them "go faster" than before, but I wouldn't say they were _really_ onboarded.

Perhaps it's just a case of a different culture, a too-rigid definition of "quality", or just a different set of workplaces, but this has not been my experience at all. Most junior hires take at least 6-8 months to produce code with our standards of quality without a decent chunk of supervision. Even a junior with a very solid capability to think the system as a whole has a tendency to over-engineer or place code in the wrong places due to inexperience, which definitely affects their productivity.

replies(2): >>45422478 #>>45433343 #
1. hyperadvanced ◴[] No.45422478[source]
Orthogonal comment here but “onboarding” has always struck me as weird. I’ve only had 3 tech jobs in 15 years and may not need to get another one, but at every one I just showed up on day one and started doing things that people asked me to. Clone the repo, run it locally, deploy a change to dev, poke around at it, read some docs, do a little refactor or comment on other people’s PR’s. There is much to do. I don’t get these people who show up and like.. don’t do anything. Even if you do something dumb and have your PR ready for review EOD it’s all good. I have never seen the effort that goes into these mountains of onboarding docs that some of my coworkers have pay off, I just pair with the new people and we solve things and they learn.