A bunch of programming advice I'd give to myself 15 years ago

Post by marcusbuffett » Sat, Jun 29, 2024, 6:58 PM UTC

trashburger wrote: post #130

mannykannot wrote: post #39

I like this a lot. While those commenters who say it is too advanced for novices have a point, I feel these are still issues worth thinking about - and coming back to - as they learn. The one exception is “Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code.” My experience with bad code is that it does not tell me much; instead, it presents inscrutable and baffling mysteries. From t…

I think you got the wrong idea from that sentence; the author is talking more about the feedback you get from your end-users and/or customers, rather than development feedback a la debug info.

Post by cratermoon » Sat, Jun 29, 2024, 7:15 PM UTC

tdumitrescu wrote: post #159

Chris_Newton wrote: post #112

Earlier quoted context omitted.

Possibly my all-time favourite XKCD, Is it worth the time?¹ , demonstrates two important points. If you only do something very rarely anyway, spending time to automate it won’t have a great ROI. But for things you do moderately often that take a minute or even just a few seconds, you can afford to spend a surprisingly large amount of time optimising them and still get a big pay-off over a time frame measured in years…

> If you only do something very rarely anyway, spending time to automate it won’t have a great ROI For code-editing, maybe. But in general software engineering, there are tasks that I have to do maybe once a year or less that are always way more painful than they need to be because I don't remember the details, and anytime I automate even part of them (or yes, just document a little better), it turns out to be well w…

Post by tracerbulletx » Sat, Jun 29, 2024, 7:20 PM UTC

supriyo-biswas wrote: post #84

I wish more articles talked about the usefulness of integration tests over unit tests. Personally, I feel that unit tests are overrated and rarely give the required confidence to inform the team whether something is ship ready, whereas integration tests on the common workflows means that even when a bug is introduced, very few users are affected.

Post by mostlysimilar » Sat, Jun 29, 2024, 7:23 PM UTC

oblio wrote: post #164

999900000999 wrote: post #158

I'll add one point. You are not your job. Don't take things personally at work. And never be afraid to leave if you're not fitting in with your company . I've left jobs over a few reasons, primarily bad managers, increased compensation, and bad code . If people are writing bad code at your company, to the point where you know it's going to come back to haunt you later, it's okay to just walk away . Don't embarrass an…

Unless you have a lot of flexibility in terms of where you work, this type of advice is becoming less relevant in an IT job market that's in free fall. Much fewer devs can just jump ship at will than between 2003 - 2022.

Post by 8n4vidtmkvmk » Sat, Jun 29, 2024, 7:26 PM UTC

j45 wrote: post #137

hamasho wrote: post #11

Most of this advice has already clicked with me, but this part: > If you can't easily explain why something is difficult, then it's incidental complexity, which is probably worth addressing That's a real eye-opener. Hope I remember this next time I implement something complex. The thing is, I don't think this stuff would've helped me much when I was a junior dev. A lot of them are just too nuanced.

'Addressing' can be ambiguous. Writing comments to explain why it's right and needs to be this way? Or changing the code without considering if they have enough knowledge of the rest of the codebase. There's also a chance it's not understood yet to easily explain it. A key part of joining a team is remaining open to the fact that just because I don't understand something, doesn't mean there isn't understanding in it.