Hacker News Reader

Comment by delusional | Hacker News Reader

We hired a new guy at work. In one of his first tasks he had chosen to write some bash, and it was pure nonsense. I mean it contained things like:

if [ -z "${Var}+x" ]

Where I can see what the author was trying to do, but the code is just wrong.

I dont mind people not knowing stuff, especially when it's essentially Bash trivia. But what broke my heart was when I pointed out the problem, linked to the documentation, but recieved the response "I dont know what it means, I just used copilot" followed by him just removing the code.

What a waste of a learning opportunity.

View on HN

I agree that it's a waste of a learning opportunity, but from my experience it is still often rational.

There were many times in my career when I had what I expected to be a one-off issue that I needed a quick solution for and I would look for a quick and simple fix with a tool I'm unfamiliar with. I'd say that 70% of the time the thing "just works" well enough after testing, 10% of the time it doesn't quite work but I feel it's a promising approach and I'm motivated to learn more in order to get it to work, and in the remaining 20% of the time I discover that it's just significantly more complex than I thought it would be, and prefer to abandon the approach in favor of something else; I never regretted the latter.

I obviously lose a lot of learning opportunities this way, but I'm also sure I saved myself from going down many very deep rabbit holes. For example, I accepted that I'm not going to try and master sed&awk - if I see it doesn't work with a simple invocation, I drop into Python.

I feel similarly that some such learning opportunities are just going to be larger rabbit holes than the thing is worth, but in those cases I'll just prefer to do it a different way that I do know or is worth learning.

E.g. maybe it would be very 'elegant' or rather concise awk if I could overcome the learning opportunity, but like you I would probably decide not to; I'll do it with the sed I do know even if it means some additional piping and cutting or grepping or whatever that awk could've done in one, because I already know it and it's going to be clearer to me and probably anyone else I'm working with.

I think we're saying quite similar things, but my point is I wouldn't be deleting it, dismissing the idea, and disappointing the colleague ready to teach me about it - because I never would've been willing to blindly try broken AI generated (or however sourced) code that I didn't understand in the first place.

I like learning a little about a lot of things as I’m the entrepreneurial type, but I’m really good at very few things. I appreciate having workers who specialize in one or two things really deeply though.

You don't have to master it. But some things are just well worth learning at least the basics of: Your programming language of choice, your shell, your editor, your version control system.

An afternoon learning your way around bash or vim will save you countless of hours of work, just because you will know what the building blocks are, you will be able to ask the right questions directly instead of chasing down alleys.

It's not the same thing as learning yet another language. It's a separate type of tool. Developing software without knowing an editor or a shell is like refusing to learn what a file is or what an ip address is. Sure, you can probably get work done in roundabout ways, but it's certainly not rational.

Everyone working with shell scripts should know shellcheck

And Python...

And of a salary...

Wait until a manager who's evaluating a technical decision you're making copies and pastes ChatGPT's "analysis" of your proposal and asks you to respond to it.

And you didn't sack him?

I don't have hiring privileges. Either way. I like the guy, and I'd rather work to build him up. That doesn't mean it's not frustrating, but I have a process that seems to build a pretty good culture.

https://stackoverflow.com/a/13864829

It is not nonsense. You use that expression if you want to check if a variable exists or not (as opposed to being set to an empty string) which is an extremely common problem.

The +x needs to belong inside the {}, ie. "${var+x}" not "${var}+x"

But I agree I wouldn't extrapolate too much from one such brain fart

That what I meant by "I can see what they were trying to do". It's would have been correct if the "+x" was inside the braces, even in context. He did in fact want to check if the variable was unset and error out, and that's what hurts so much.

There was a real and correct analysis that, hey, I want to make sure the variable is set here. Only to then drop it because you get told the syntax is wrong. The response I'm looking for when I say "This syntax won't do what you're looking to do" would be something like "what am I trying to do? and why wont this do it?" not "well it's just some AI code, I'll just remove it".

Reply on news.ycombinator.com