Comment by lossyalgo | Hacker News Reader

Comment by lossyalgo | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com