5 ms·

Ugh... we have a new colleague who does this repeatedly. Most recently, I said in order to build, you need to do this: - git clone <repo1> <dest1> - git clone

Ugh... we have a new colleague who does this repeatedly. Most recently, I said in order to build, you need to do this: - git clone <repo1> <dest1> - git clone <repo2> <dest2> - git clone <repo3> <dest3> What do they do? git clone repo1, 2, 3 without giving <dest> parameter, which clones into default folders named after the repos. Build fails of course because repo1 depends on repo2 and 3 being named specifically. He sends me the error log (remote colleague, yay) and I say: you gotta rename those folders. Instead of renaming them, tries other things for hours, then comes back and shows me other build errors. I look over the errors and realize, again, the folders are still named incorrectly. Rinse and repeat 2 more times before finally the build process works. Lost a few hours to this. This kinda stuff keeps happening with this colleague. It's really a huge time-sink. If I had more time, I would do remote call and watch over them, but I'm so deep in my own stuff that I don't have time to babysit (not to mention calls take 1-2 hours with this person just trying to explain really basic things, over and over and over again).

ikiris 6mo ago
Dude, this sounds more like a build problem than a new guy problem. Your process sounds completely broken.
- lossyalgo 6mo ago
  Yes and no. My retort is here: https://news.ycombinator.com/item?id=47841520 https://news.ycombinator.com/item?id=47841520
onli 6mo ago
If he is young enough he probably did not know how the file systems worked (and I mean: what a directory is, what files are). Supposed to be quite common now for people using only mobile devices. So he lacked the fundamentals to understand what you wanted.
- lossyalgo 6mo ago
  That's definitely a valid argument, but I highly doubt it since they know their way around Windows and Linux just fine. I honestly think it might be related to attention span, miscommunication, language barriers and/or maybe a heavy reliance on AI tools (though to be honest, even local LLMs would have spotted the error immediately).
eterm 6mo ago
Sure, that's frustrating. But you know what's also frustrating? Code bases which involve multi-step manual steps to build. You should be able to get a working local environment with a single command. You should be able to get a working local build with a single build command. If you have depedent projects, they should either be in a monorepo, or delivered through a packaging system so they are not depend on the specific local naming of other repos. Having a repo depend on a different repo being in a specific place on the file system is bad, having multiple of them is terrible. Stick what's needed in an onboarding script, and make sure it works before onboarding someone. Ideally that script should be kept to a minimum, if it grows too large that's a sign you've split things artificially instead of finding natural splits.
- lossyalgo 6mo ago
  I agree, and there are other fun gotchas that even more frustrating and convoluted. But everything is thoroughly documented and I even explicitly pointed out those potential issues before I gave them the assignment. When the errors first occurred, I pointed out the fix, which was ignored, multiple times. Should it be that difficult to rename a couple folders? The compiler errors were fairly easy to understand: can't find repo2. Is that too much to expect from someone? In an ideal world and in retrospect, you are right. But the build process is very old, created by someone long gone, of which multiple projects depend upon, each with minor tweaks and always reliant on the same hard-coded paths which IMO isn't that bad and can easily be rectified - it's really not worth the time or energy to allow dynamically named folders, not to mention dangerous since it's a critical production system that's worked forever. Nobody wants to break a running system, nor has the time to clean things up properly, especially since there are tons of build scripts that all rely on these paths, and trying to fix all of them would be a huge amount of work, spread across multiple projects, all requiring sign-off from higher-ups who will never be able to justify the cost to fix something that already works.
  - jamesfinlayson 6mo ago
    With you on this one - I worked with a hopeless tester years ago - gave him a detailed test plan with a nice sequence of steps to follow to set up the scenario. I have no idea why but he decided to do the steps out of order, then wondered why my patch didn't do what it was meant to.
mixmastamyk 6mo ago
Available now, can follow directions, and yes write scripts to automate that: https://news.ycombinator.com/item?id=47609859 https://news.ycombinator.com/item?id=47609859
- lossyalgo 6mo ago
  Nice try :) Actually the hard part isn't creating a script to automate 3 git commands - it's that there is no root repo to put such a script, hence the need to manually do it.
  - mixmastamyk 6mo ago
    repo1/bin/build_all .

ikiris 6mo ago

Dude, this sounds more like a build problem than a new guy problem. Your process sounds completely broken.

lossyalgo 6mo ago
Yes and no. My retort is here: https://news.ycombinator.com/item?id=47841520 https://news.ycombinator.com/item?id=47841520

onli 6mo ago

If he is young enough he probably did not know how the file systems worked (and I mean: what a directory is, what files are). Supposed to be quite common now for people using only mobile devices. So he lacked the fundamentals to understand what you wanted.

lossyalgo 6mo ago
That's definitely a valid argument, but I highly doubt it since they know their way around Windows and Linux just fine. I honestly think it might be related to attention span, miscommunication, language barriers and/or maybe a heavy reliance on AI tools (though to be honest, even local LLMs would have spotted the error immediately).

eterm 6mo ago

Sure, that's frustrating. But you know what's also frustrating? Code bases which involve multi-step manual steps to build. You should be able to get a working local environment with a single command. You should be able to get a working local build with a single build command. If you have depedent projects, they should either be in a monorepo, or delivered through a packaging system so they are not depend on the specific local naming of other repos. Having a repo depend on a different repo being in a specific place on the file system is bad, having multiple of them is terrible. Stick what's needed in an onboarding script, and make sure it works before onboarding someone. Ideally that script should be kept to a minimum, if it grows too large that's a sign you've split things artificially instead of finding natural splits.

lossyalgo 6mo ago
I agree, and there are other fun gotchas that even more frustrating and convoluted. But everything is thoroughly documented and I even explicitly pointed out those potential issues before I gave them the assignment. When the errors first occurred, I pointed out the fix, which was ignored, multiple times. Should it be that difficult to rename a couple folders? The compiler errors were fairly easy to understand: can't find repo2. Is that too much to expect from someone? In an ideal world and in retrospect, you are right. But the build process is very old, created by someone long gone, of which multiple projects depend upon, each with minor tweaks and always reliant on the same hard-coded paths which IMO isn't that bad and can easily be rectified - it's really not worth the time or energy to allow dynamically named folders, not to mention dangerous since it's a critical production system that's worked forever. Nobody wants to break a running system, nor has the time to clean things up properly, especially since there are tons of build scripts that all rely on these paths, and trying to fix all of them would be a huge amount of work, spread across multiple projects, all requiring sign-off from higher-ups who will never be able to justify the cost to fix something that already works.
- jamesfinlayson 6mo ago
  With you on this one - I worked with a hopeless tester years ago - gave him a detailed test plan with a nice sequence of steps to follow to set up the scenario. I have no idea why but he decided to do the steps out of order, then wondered why my patch didn't do what it was meant to.

mixmastamyk 6mo ago

Available now, can follow directions, and yes write scripts to automate that: https://news.ycombinator.com/item?id=47609859 https://news.ycombinator.com/item?id=47609859

lossyalgo 6mo ago
Nice try :) Actually the hard part isn't creating a script to automate 3 git commands - it's that there is no root repo to put such a script, hence the need to manually do it.
- mixmastamyk 6mo ago
  repo1/bin/build_all .