Well, yeah, but there are only so many people older than me so I took a shot.

Thinking in Unix did a great job of explaining why Unix did what it did, probably still a good read.

I think suzzer's broader point (or maybe I'm extrapolating) is getting lost in the details - maximizing individual developer freedom and productivity in the short term is not the same thing as maximizing output at the team level in the long run.

As for the unix philosophy, there are some elegant aspects to its design but its success is mostly about worse is better - because it's easy to implement (in part because its design is kind of broken), so many more unix variants were implemented.

I guess my broader point though is that maximizing output at the team level in the long run requires allowing individual developers freedom in a lot of dimensions - including their unix configuration scripts.

I was talking more about the syntax of bash scripts than I was the Unix philosophy. Small things that do simple things and can be piped into other small things is brilliant.

Well the specifics are team and organization dependent so I think it's pointless to argue about bash configuration scripts in particular - my powerline ain't setting itself up - but my thought is that generally speaking developers are going to be biased towards believing what you just wrote, because they benefit from the freedom but don't bear the costs.

With that said, I hope we can all agree that it's broken that bash is configured via a series of imperative commands, not through a declarative configuration file.

yes what kerowo said. i'm not comparing it to the ideal possible OS. but they got composition of the tools right. it's such a big deal that all the failures almost don't matter in comparison. you're only allowed to ***** about unix if you understand that overarching fact imo.

i'll agree with that.

I disagree, and disagree that the developers don't bear the cost. Although obviously also very team & organization dependent.

I was at a meetup once and was going through some stuff on my server with a guy who's a total long-beard in spirit, though not in body. He owns a startup he wrote in Perl, which he recently started.

I was using tab-complete to go through the file system and he says: "Oh, you know about tab-complete."

I looked at him like he was nuts, but he told me that most programmer have no idea that you can do that. Here I thought most programmers would have done this naturally.

I think that suzzer doesn't want these people to build up bash configs, as it's more likely they copy / pasted something from the internet than something they thoughtfully built themselves.

Does this matter?

There's lots of good stuff on the internet, why not use it. My first powerful bashrc file came from a co-worker. It helped me out enormously even though I didn't understand a lot of it. And sure, some things broke over time, and I had to figure out how to fix them (or give up and remove them) but it was a pretty good head start. I wouldn't have even known I could do half the things in the file - let alone how to do them.

Learning stuff can be hard and cause problems. Sometimes its worth it and sometimes its not (for the individual, the team, the company, etc.).

I think this is a case where the cost is worth it in the majority of situations.

jfc is there anything worse than incompetent or maybe intentionally obtuse offshore QA? Like if you can't pay enough attention to what I say on calls or in emails to have to ask me over and over if something is ready or whatever and can't follow simple instructions then how in the world are you able to do QA that leads to product acceptance?

Agree w this.

Yes, I will bring that up with my company's leadership.

In the meantime you have to make due with what you have.

We have a "technical" sales guy like this.

This morning he responded to a month old thread where I said that I had done something to ask whether I had done the thing I said I had done.

He's supposed to be technical enough to help customers with API integrations and yet engineers are constantly having to explain **** like why a customer's xml request to our json API is failing or what the error message "invalid phone number" indicates is wrong with a request...

I don't understand.

I worked on an incredibly productive team for 5 years+ where everyone (devs, SQA, PMs) got along and socialized together. Because of this, we trusted each other and worked harder than we would normally because we didn't let the team down. You can't calculate the productivity gains from a spot like that - where you can spend 100% of your effort on building something, and 0% on covering your ow ass.

The factors that contributed to this were a) dumb luck of a bunch of great people and b) SQA completely embedded with each project team. They sit next to each other, and at least an SQA lead is on every meeting. Most meetings all of SQA is on them.

The bolded makes such a gigantic difference. There's almost no friction of communication, domain-knowledge-discrepancies, or human interaction problems caused by SQA being off on some other floor (or other time zone - ugh). I never want to work any other way.

Last year I worked on a team in a different department where SQA is still split off on some other floor. Every non-obvious bug turned into a passive-aggressive game of who's going to get up and walk over to the other person's desk to figure it out. So they just sit there for days until something forces the issue. Which eventually creates an under-current of hostility between the two groups.

I don't either, I guess I misinterpreted your point to mean that I should get better devs.

Anyway bottom line is if you know what you're doing - customize away.

If you don't know what you're doing and I'm going to have to spend hours trying to figure out why your machine is acting weird for you - then don't **** with it.

I don't think some of you realize how clueless most offshore devs are. Imagine teaching Computer Science 101. Pretty sure those teachers don't want every student going in and tweaking their dev environments to the point that they all behave differently.

Luckily however once we trained up the onshore devs (where the good ones stayed and the bad ones went home), now we make them train all the offshore devs. But it took a while to get to that point. We had to go to India and set up a training program among a bunch of other things.

Maybe if you let them set their own config you'd have better devs!

Why stop now...

I think it matters. A team has to be on the same page, IMO. I think suzzzers point is that you have to be familiar with your tools. He's not trying to be someone's teacher, and he's not interested in doing remote debugging. I think your disagreement stems from a reasonable fear of a very low common denominator.

My perspective probably comes from using Arch and Fedora, which are both insanely solid and dependable distros, but they also allow you many ways to shoot your own foot off. When documentation says "do not run this command until you understand what it means," that's not a off-hand remark. Copy /pasting system code is... I think it's absolutely irresponsible.

You can also take Grue's example. Two posters pointed out that there are better / more conventional ways. Even among 3 reasonable developers, we have 3 different perspectives on correct. Suzzer appears to be working with remote devs who aren't reasonable. In my personal experience, the average dev isn't reasonable either. I think it's somewhat misguided to not embrace a LCD attitude at times. We still have experienced devs who think clicking endless drop down menus is faster than hot keys and snippets. Is a bashrc file really going to help these people?

That's why I didn't go with Arch. If I were more advanced, and not the type of person to accidentally shoot my own foot, I would've. I went with Ubuntu instead.

Dave, sure, I guess there are situations where LCD is the right attitude. I don't have a sense of what the actual percentage of times where its true is though. I'm lucky enough that I likely will never have to work in places where that's true.

I eyeroll at the "Copy /pasting system code is... I think it's absolutely irresponsible.".

The take away from Grue's post isn't that "There's multiple ways to do something, so we shouldn't do any of them until you understand all of the details". For a lot of people it should be "Cool, there's a way I can make shortcuts for commands I run all the time!".

tbh I had no idea you could put bash aliases in a .gitconfig file but does it really matter?

Neither did I, but my preferred way to do it is to create another script file, and add some comments in the .bashrc file that you launched your external file in there... that way it's all traceable. I wouldn't add any actual commands in .bashrc except to call scripts for me. So having a .gitconfig makes some sense. So far I've only used .bash_aliases, I think, which plugs into .bashrc. I don't see why you'd need to modify it very much, and it's better not to touch in most cases. I mean, your make files can do your environment stuff.