Often enough, the old code is so badly intertwined that it’s impossible to actually test. Those are the moments where all you can do is nuke it from orbit.
That’s why everyone switches jobs every few years.
Sure, the increased pay is nice, but the real benefit is not having to deal with the catastrophically awful code that you’re forced to write because product wants to ship this 3 months ago and you haven’t been given enough time to design and implement the system in a way that actually makes sense.
At this moment, I am staring at a 200-line block of postgresql that has about 40 JOIN clauses. It is not trivially or realistically debugable, testable, or extensible by anyone, including the people who wrote it (and no, I didn’t write this shitshow). There are basically zero nuanced tests around it, despite the fact that that’s a banner I’ve carried in a pretty militant fashion since starting at this place about 2.5 years ago, meaning that I trust this baroque confluence of relational db logic about as far as I can throw my car. It was done this way because “we’ll have time to go back and optimize it later (oh, sweet summer child)”.
Oh, I was fearing we worked together, so I just went to check one of my workplace’s megaviews. But no, it’s 448 lines.
I wrote its first version a few years ago, with less than 100 lines, then I rewrote it with common subqueries so it could be actually maintained. It was much larger by that point. Later I removed some of the ambiguous (and subtly bugged) subqueries and rewrite it to use only about half of them. Looks like I need to do something about it again.
My consolation is that I’m not the one maintaining it.
Today we have chatbots. Yesterday we had search engines and stack overflow. Before that we had books. And before that? Well what do you know… software programming is a relatively novel field. It’s almost as if nobody has perfected how it should be learned.
The most valuable knowledge comes from experience. I copied plenty of code around during my learning days as well, and I still do it today. The most important part however is trying to understand the code you’re working with. If you can understand it, know when it fails, test it in the right way, etc., then sure, you could probably learn to code from chatbots. They provide the information, and you’re at liberty to do what you want with it. If you just copy it and forget, you’ll be a bad programmer. But it’s not like you couldn’t do that before either with the other sources that were available - there were plenty of bad programmers before we had these tools available too.
That said, there is a risk that these chatbots do not provide any useful context around the code that they produce. When you learned from a book or stack overflow, you were reading from a reasonably authoritative source that could explain the code that was produced. But the authority behind the code from chatbots is probably much weaker than what we have from stack overflow, which in turn was probably also weaker than what we have from books. Does it have an effect or learning? I have no clue. But I still think you can learn from chatbots if you use the output that they provide in the right way. (Disclaimer: I have never used one of them and have no experience with them.)
I literally cannot comprehend coding with ChatGPT- How can I expect something to work if I don’t understand it, and how can I understand it if I don’t code and debug it myself? How can you expect to troubleshoot any issues afterwards if you don’t understand the code? I wouldn’t trust GPT for anything more complex than Hello World.
Just yesterday, I wrote a first version of a fairly complex method, then pasted it into GPT-4. It explained my code to me clearly, I was able to have a conversation with it about the code, and when I asked it to write a better version, that version ended up having a couple significant logical simplifications. (And a silly defect that I corrected it on.)
The damn thing hallucinates sometimes (especially with more obscure/deep topics) and occasionally makes stupid mistakes, so it keeps you on your toes a bit, but it is nevertheless a very valuable tool.
That only really works, if the method is self-contained, and written in a language that GPT has seen often (such as python). I stopped using it, because for 1 in 10 successful tries I waste time for the other 9 tries…
If I’m writing something slightly more complex, ChatGPT(4) is mostly failing.
If I’m writing complex code, I don’t even get the idea of using ChatGPT, because I’m only getting disappointed, and in the end waste more time trying to “engineer” the prompt, only to get disappointed again.
I currently cannot imagine using ChatGPT for coding, I was excited in the beginning, and it’s sometimes useful, but mostly not really for coding…
If you’re already knee deep in existing code and looking for bugs or need to write quite specific algorithms it seems not very useful. But if you for some reason need to write stuff that has the slightest feeling of boilerplate, like how do I interact with well established framework or service X while doing A, B C it can be really useful.
Also it’s often doing a great job if you paste a stack trace into it and maybe some surrounding code. I used it to fix someone else’s Java code as well as to upgrade some 3rd party Wordpress junk to latest PHP. I barely know Java and stopped following PHP news around version 5.6.
You shouldn’t use code that you don’t understand. Chatgpt outputs quite readable and understandable code and makes sure to explain a lot of it and you can ask questions about it.
It can save quite a lot of effort, especially for tasks that are more tedious than hard. Even more if you have a general idea of what you want to do but you’re not familiar with the specific tools and libraries that you want to use for the task.
It’s also wrong a lot. Hence the requirement for understanding. It can be helpful to get through a stretch but it will fuck up before too long and relying on it entirely is a bad idea.
Often the code is self explanitory. I understand the code very often, but I still couldn’t write it correctly from scratch. You never feel like that?
This is how code examples in books works too. You get some code to look at and try to understand it. Otherwise it’s like you would ignore code examples while learning programming.
I haven’t been in web development in over 20 years; thanks to ChatGPT, I was able to get up-to-speed and start building websites again, when in the past I would have never been able to do so.
GPT is a powerful tool that can allow anyone to do anything if they’re willing to put in the effort. We should be praising it, not making fun of it. It’s as revolutionary as the internet itself.
I use it to give me prototypes for ansible because Ansible is junk. Then I build my stuff from the mishmash and have GPT check it. Cuts a lot of time down that I’d rather be doing any-bloody-thing else with.
As someone who is learning, I think it’s imperative to understand that chatgpt has limitations that cannot be overlooked. It’s pretty good if I make some silly syntax or formatting errors, but at the core I have to understand what I’m working with if I want to be a better programmer. I love the conversational nature because I often have a hard time wording questions, so it helps me in that regard as well. Idk if you want to be truly good at something you have to be more reliant on yourself than external tools.
The thing is, in some fields like devops, there are so many tools that you can’t remember or know all of them very well. So asking chatgpt how to do something saves very much time. It can write ansible playbooks, docker files, web server configurations etc etc. They almost never work perfectly but they give a very good starting point to modify.
It used to be that you could be very good at specific languages or tools but today, there isn’t enough time. Everyone is always in a hurry to get something out as quickly as possible too.
Correcting the reviewer.
Notes: “should of” isn’t valid, should implies a verb, of isn’t a verb. I expect you meant “should have”. Please recall this in future submissions.
A question mark does not fit the sentence, which is a statement (“they should.” rather than “should they?”). While question marks are commonly used to demonstrate a rising tone at the end of a sentence, its not considered correct for formal writing.
A-ha, but this most decidedly not formal writing! UNO REVERSE CARD.
But on a more serious note, I did intend it as a sort of question because I’m not 100% sure, because the rules for quote use might well be different in English than my native language. I actually also don’t know the rule for question mark usage in English; is it generally considered a crime against orthography to plonk a question mark on something that’s a statement, or is it valid in some cases?
It’s totally valid in most cases. It’s technically only supposed to be used for a question, but language is based on how it’s most commonly used, with those “rules” only applying in extremely formal situations. With the prevalence of informal text-based communication, many people use it to indicate being unsure, like how you used it. I just wanted to continue the chain of grammar corrections (which is why I used the wrong “its”/“it’s” at one point). Also, you were right about the quotes.
It’s technically only supposed to be used for a question, but language is based on how it’s most commonly used
Ah, I see you’re also a descriptivist 😀
But yeah I know you were just continuing the joke; I’m a language nerd (well, general nerd really) and I just got curious about what the rule actually is. While English orthography rules related to punctuation usually seem to be pretty much the same as with Finnish, the rule for question marks seems to be more relaxed in Finnish because it can “officially” be used to mark any expression as a question. The rules for commas are also different, ours are closer to German and we tend to spray commas everywhere
They should of course keep that in mind, but it’s not that “should” should always be followed by a verb directly. The problem is that “of” in this context is a mishearing/spelling of “have”, so they should in this case have written it like that instead.
I would argue that “should of” is just a naive written rendition of the spoken contraction “should’ve”. They are homophones, so it’s a completely understandable error among those without the relevant education or background. I know only English and was in Grade 9 at a different school before someone corrected me.
In that spirit, I will call attention to your first sentence, specifically the comma. In my opinion, that can be improved. One of three other constructions would be more appropriate:
I am really happy when people are quite strict in code reviews. It makes me feel safer and I get to learn more.
I am really happy when people are quite strict in code reviews, because it makes me feel safer and I get to learn more.
I am really happy when people are quite strict in code reviews; it makes me feel safer and I get to learn more.
The first of my suggested changes is favoured by those who follow the school of thought that argues that written sentences should be kept short and uncomplicated to make processing easier for those less fluent. To me, it sounds choppy or that you’ve omitted someone asking “Why?” after the first sentence.
Personally, I prefer the middle one, because it is the full expression of a complete state of mind. You have a feeling and a reason for that feeling. There is a sense in which they are inseparable, so not splitting them up seems like a good idea. The “because” explicitly links the feeling and reason.
The semicolon construction was favoured by my grade school teachers in the 1960s, but, as with the first suggestion, it just feels choppy. I tend to overuse semicolons, so I try to go back and either replace them with periods or restructure the sentences to eliminate them. In this particular case, I think the semicolon is preferable to both comma and period, but still inferior to the “because” construction.
I’ve clearly spent too much time hashing stuff out in writers’ groups. :)
I agree with most of that. In formal settings, I prefer full sentences with conjunctions; however, choppy sentences are the ones that often end up in my Lemmy comments.
Reviews have to be balanced to circumstance. There is a big difference between putting out the sales brochure and the notice on the bulletin board. Likewise in coding a cryptographic framework for general consumption and that little script to create personal slideshows based on how you’ve tagged your photos.
As a general rule, wider distributions, public distributions, and long-lived distributions need more ambitious reviews. If the distribution is wide, public, and permanent, then everything needs very detailed scrutiny.
I have found some success in starting with and occasionally revisiting review goals. This helps create and maintain some consistency in a process that is scaled to the task at hand.
Notably, a good code review should also bring up the good parts of the submission, and not just concentrate on the errors. Not only does it make the recipient feel better to get positive feedback among the negative, but it helps them learn about good practices too. Just concentrating on the errors doesn’t really tell them which things they’re doing well.
Many reviewers concentrate on just finding mistakes, and while it’s useful it’s sort of the bare minimum; a good code review should be educational. Especially if the submitter’s a more junior coder, in which case it’d also be a good idea to not just outright tell them how you’d fix some problem, but sort of lead them to a solution by asking them questions and pointing things out and letting them do the thinking themselves. But still, experienced coders will also benefit from well-structured feedback, it’s not like we’re “finished” and stopped learning.
Yes, I tend to do that, and thankfully some of my colleagues do too. Clever but readable solutions, following good and relevant practices, clear documentation, making a good MR description that makes it easier to review, and more.
That’s great to hear. It’s thankfully becoming more common in general, and we can all do our part in spreading these practices.
I tended to actively evangelize for it when I was managing coders or teams. Unfortunately it’s still not all that uncommon for coders to be downright offensive when giving feedback, like not necessrily quite Linus-level rants but things like “this is idiotic, this is stupid, that’s shit, why would you do that” etc etc. The usual explanation I’ve gotten is that they’re just being “honest” and saying what they think, and it’s not their problem if the reviewee (is that even a word‽ I can’t English today) gets offended. Some even get all huffy about it, like “oh we’re just supposed to coddle them and never say anything negative so their little feefees don’t get hurt?” And I mean, yeah, getting honest feedback definitely a good way to learn, but it’s not like the only way to point out errors or problems is to be a cunt about it.
Assuming you have competent leadership, then it wouldn’t be merged if you missed something obvious. I guess you’re saying that you want more positive reinforcement.
Yeah, I learn so much from code reviews and they’ve saved me so much time from dumb mistakes I missed. I’ve also caught no shortage of bugs in other people’s code that saved us all a stressful headache. It’s just vastly easier to fix a bug before it merges than once it breaks a bunch of people.
Ohh! Thanks, I mean, I had already got the grammatical meaning, but I just wasn’t sure what “chexp” was, I thought you were talking about some obscure Unix command… so it was just the same phrase all along, lol
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.