Hacker News Reader

Comment by eterm | Hacker News Reader

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.

View on HN

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.

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.

See, I would probably have been the guy that ignores the dest part. On purpose. Just to see whether this pile of poo shits itself and how much.

I would also recognize what happened when I see the error messages though and then silent quit until I've been with you guys for long enough my resume doesn't take a hit just because your interview process duped me into starting at your place.

Yes this sounds harsh. I know. Nothing against you personally. But I've been at too many such places. One can do things better.

haha I would totally empathize with you. But see, you would realize immediately that it doesn't work and why, but you are smart enough to realize it and would just rename the folder (as mentioned in the readme as the very first thing to do), hit build and voila, everything works as expected, instead of sending me log files, letting me debug your errors, ignoring my repeated instructions, waste my time helping you debug, back and forth until finally you just rename and move on. I had to say it 4x before it finally stuck. This guy seemingly wanted to get an initial build done so he could move on to actually fixing bugs. Maybe it's intentional to waste everyone's time so that he can book hours in the system and get paid for futzing around? :shrug:

and btw the system doesn't shit itself that much: the compiler errors are fairly straight-forward: this folder doesn't exist.

Of course everyone can always do better, but it's a legacy inherited system, and works fine, as long as things are named correctly. The readme is actually very short - literally the git commands are there to copy/paste and will create the correct directory names. There are plenty of other things to get hung up on, but naming folders correctly should IMO not be one of them.

Hehehe, definitely been there and dealt with that guy that I definitely didn't let pass his probation period. I see we do understand each other.

And I might not silent quit right away and try to actually improve things and see how it goes/how you "let me".

This does actually remind me of my very first job actually. It's been many, many, many years now. I found a stinking pile of disparate shell and perl scripts that made up the "backend" of the application I was hired into working on. Grown histerically for almost 15 years prior to me being hired fresh out of university. I started extracting common library code out of every single one of these every time that I was tasked with adjusting one of those scripts. I introduced a proper deployment from source control to production the second time I "broke" something, because someone had previously fixed a bug directly in production and forgot to check the fix into source control (and no, I didn't believe that it was not the guy that was working on the project w/ me for one second after seeing how they coded and how they defended everything that was bad about that pile of poo and how "it's too complicated to do X".

Well guess what, this new grad did all of that anyway. Without AI and without IDE refactoring support (I mentioned Perl and shell scripts, did I?) and without a single QA person in sight. And yes, every single one of the readers here very probably has bought a product that was "touched" by that software, without knowing, since it was an in-house administration tool.

I hear you, but I still feel for the coworker, and if I newly joined a company and learned on my first day that they are failing the Joel Test[1] here in 2026, I would get that sinking feeling in my stomach that I made a huge mistake. There is no longer a valid excuse for having a build like that. "It's documented..." and "Nobody wants to touch..." "Not worth it to..." "Can't justify..." are all huge red flags.

1: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Nice list, somehow I missed that one. I love Joel's wisdom.

The full build literally works in one step but the main prerequisite is to perform a few git clone commands which can be copy/pasted from the readme. Can't help it if they want to manually do git clone and let it name folders incorrectly and then subsequently ignore compiler errors and my advice to rename. Changing our antiquated workflow would have required changing a lot of other sensitive dependencies. What ever happened to the old adage "never change a running system" ? ;)

And people here are concentrating on our build system, which I will be the first to admit isn't perfect, but this isn't the only instance of me telling this person how to do things, them not listening to me and doing something else, letting me debug only to realize they didn't listen, telling them how to fix, only to be ignored _again_, rinse and repeat. It's unfortunately a recurring theme. I initially thought it was a communication error on my part, but I've heard similar complaints from several other colleagues as well.

See, you are probably right about that new hire. But the way you say things here, you do come across (at least to me) as "that guy". You know? "That guy" that says "we've always done it this way and that is why it's good and why we still do it that way".

What happened to "never change a running system" is that if the system is barely running at all, you better do change that system.

If I'm the new guy and you tell me how to do things and those things seem bad and there's no explanation for why they need to be that way, I'll also ignore you, coz I know how I want to do things and how things can be done better. Don't tell me to do things X way. Many roads lead to Rome and some are better than others. See my other reply. At my very first job I was also told how things work and how to do things. But things sucked and so I made them better anyhow.

Now, in the other part of the thread you also did mention how they just sent you error logs without reading and thinking about them themselves and such. That definitely is a red flag and the kind of thing that will make me fail someone's probation period. Definitely. But just because someone doesn't think that "the way we've always done things" is a good reason to keep doing something bonkers is where I'm no longer with you. And again, probably just your wording/what you disclose in various parts of these threads but it explains why "we concentrate on certain things only" ;)

> "That guy" that says "we've always done it this way

I most definitely am not, and constantly push back for changing processes, and do make changes when I am allowed, even when it's not budgeted for or even officially allowed, because we have legacy systems that need to be maintained and some things are truly outdated and need some love. In fact, as a new hire in another life, I used to get scolded for changing _too much_ because I like to constantly improve things. The problem is, in order to ship code at our company and within our budget constraints, you don't have time to constantly refactor, unfortunately.

> is that if the system is barely running at all

Our system is and has been running just fine for many years, thank you very much :)

> there's no explanation for why they need to be that way

There is an explanation: There is no shell script because there is no root for all the repos, and some repos are shared across multiple projects.

I hate reiterating this yet again but is it really that hard to copy/paste a couple git commands? The readme is quite short, and once you've done it one time, it's fairly easy and straightforward to understand.

p.s. just FYI but I didn't downvote you.

at the very least there's no excuse for not having a shell script to check everything out in the right places! I've been the new person in teams with this sort of fragile setup and it's no fun whatsoever.

The "excuse" is that there is no root repo :)

It's not fun to copy/paste 3 git commands? What a truly gilded engineering life you must live! :)

it's not fun to have to follow a bunch of finicky manual processes because no one in an actual software company could be bothered to automate them!

This is basically "I should have asked more questions in the interview"

If you aren't willing to fix obvious issues like this it is not somewhere that I want to work.

I agree but it's probably more common than you think. I had a job where the setup involved running one setup command twice because the first time always failed. But that was called out in the documentation so it was fine. The reason it wasn't fixed is because the project was well on the way to being end of lifed so it wasn't worth it at all to fix the crappy set-up process.

> 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.

Git submodules is a thing ...

I'm not a fan of submodules, but indeed that also solves the problem OP described.

Our git master actually considered this, but it would have caused other issues that I can't recall right now, so we got stuck with lots of repos. The readme literally has all the git commands, all they had to do was copy/paste them into the terminal.

The problem with submodules in your scenario might be the mutual dependency of repos, everything else is just extra work with git config.

It's literally made for this specific case.

edit: removed stupid hack that wouldn't work.

> But you know what's also frustrating? Code bases which involve multi-step manual steps to build.

Yes. That's what bash scripts are for.

Reply on news.ycombinator.com