What most young programmers need to learn • Hacker News Board

Re: What most young programmers need to learn

#101

Post by jdmichal » Mon, Jan 05, 2015, 11:42 PM UTC

sophacles wrote: post #93

sanderjd wrote: post #88

Earlier quoted context omitted.

This is a great discussion! I've always thought that after the basic "how do I even do this at all?" concepts of programming, the next most important concept to learn how to wield and to perpetually sharpen is the "don't repeat yourself" principle. Huge swaths of software engineering literature is dedicated (explicitly or implicitly) to when and when not to apply that principle. Your parent's comment addresses by far…

One thing to keep in mind here... some of those "you can't predict" things are utterly predictable in light of experience. That part can't be faked to well, there aren't a good set of rules about it. But experience is a good teacher, and you do eventually learn to be reasonably accurate about when to do C+P vs DRY, even if you can't explain the why of it. I think it comes down to this - when I first learned to code,…

It's actually pretty well predictable if you think about it in terms of encapsulation and core functionality. If this functionality is an external requirement to the purpose of the components, then it absolutely should exist as its own component that coalesces that functionality into a single location. However, if that functionality is core functionality to the components, and they just happen to do the same thing in the same order... Then that's where you'll eventually see divergence if you try to link them to a third component. In those cases, you should either be trying to join the two components into one, or just happily leave them as separate components that just happen to perform some common operations by way of their primary function.

Re: What most young programmers need to learn

#102

Post by frostmatthew » Tue, Jan 06, 2015, 12:13 AM UTC

throwaway3301 wrote: post #100

How does one keep these things in practice in the reality of an over-committed software team with shifting priorities, difficulties interfacing with product management, and bad specifications/requirements that eventually result in significant scope creep? I often feel like I want to refactor code, but the cost of doing so is so high that it would slow me down to the point of missing a deadline. "It works" is usually…

Instead of trying to dedicate time specifically to refactor try to clean up classes as you come across them when fixing bugs or adding features.

Whenever I open a file, I try and take a quick glance to see if there's anything that could use refactoring before working on the actual issue (if it's either a particularly large file or one that hasn't been touched in years I'll check Sonar[1]).

[1] http://www.sonarsource.com/

Re: What most young programmers need to learn

#103

Post by droidist2 » Tue, Jan 06, 2015, 6:17 AM UTC

_greim_ wrote: post #71

Inexperienced programmers sometimes can have a dysfunctional, almost worshipful, relationship with complexity. They're entering an industry riddled with complexity, most of it way over their heads, and they're in awe. So when they write complicated code themselves, they almost take it as a point of pride. I wrote this massive, tangled 300-line function that actually works, by god.

Right, the best code strives to be dead simple, almost boring. It's not like poetry; it's not more fun when it has hidden obfuscated meaning behind it.

Re: What most young programmers need to learn

#104

Post by codygman » Tue, Jan 06, 2015, 6:01 PM UTC

sophacles wrote: post #77

justifier wrote: post #63

Earlier quoted context omitted.

what i understood as the author's issue with copy paste was the knowledge that changes are expected if you copy: do_something(); do_another_thing(); another_call(); a few times in your codebase, but decide that you want to alter that a bit: do_something(); perform_new_feature(); do_another_thing(); another_call(); you can hurt yourself by forgetting that that alteration needed to be done to each instance just easy to…

Yes in that case it's a win, but it becomes an anti pattern when you sometimes want to perform_new_feature() and sometimes you don't. I've seen it happen where you end up with many functions like: def a_and_b_and_c() {...} def a_and_b_and_c_error_checked_internally() {...} def a_and_new_and_b_and_c {...} def a_and_new_and_b_and_c_error_checked_internally() {...} def a2_and_b_and_c And so on. Basically you are just pu…

In at least two of your examples you could pass in an error handling function (or class) and it would still be a net win.

Analyzing this further would require having a more fleshed out example.

Re: What most young programmers need to learn

#105

Post by codygman » Tue, Jan 06, 2015, 6:03 PM UTC

Bahamut wrote: post #80

spacecowboy_lon wrote: post #68

Earlier quoted context omitted.

And knowing when OO is not the right solution to all problems.

In this case, I'm using classes very loosely - the same applies to methods, and when to break them up into smaller methods.

I believe spacecowboy_lon is referring to functions opposed to methods. For those that don't know the difference a method is basically a function that has access to the state of an object (correct me if my definition is wrong or sucks).

Re: What most young programmers need to learn

#106

Post by [deleted] » Tue, Jan 06, 2015, 6:04 PM UTC

jerven wrote: post #98

danieltillett wrote: post #95

Earlier quoted context omitted.

Yes I also think this is what I should do to, unfortunately when I first wrote the code I spend most of my time working on I didn't write unit tests at the function level (all my tests are at the module level). I have been meaning to get around correcting this, but the task is now so huge I fear it would take me more than a year to write all the unit tests :(

IMHO every automated test helps. Don't aim for 100% test coverage aim at using unit tests to develop faster and more efficiently and the test coverage stats will come automatically. I personally need to improve my TDD, but I am quite happy with my test driven bug fixing approach. When working on a bug I first turn it into a JUnit or selenium test, and then fix the bug and make the test pass.

[deleted]

Re: What most young programmers need to learn

#107

Post by eric_h » Thu, Jan 08, 2015, 12:30 AM UTC

loqi wrote: post #81

eric_h wrote: post #48

Earlier quoted context omitted.

We have a saying over here - TWGIF[1]. Any time someone checks in commented out code, they get chastised. 1: TWGIF - That's what git is for

I've gotten in the habit of adding trailing whitespace when I comment out code or do any printf debugging. It's still quick, but then git yells at me if I try and commit it.

That's an interesting way of dealing with it - I have my text editor strip trailing whitespace and ensure there's a newline at the end of the file on every save, so it wouldn't work for me.

That's okay though. I visually review the diff before I commit (almost) every time.

Re: What most young programmers need to learn

#108

Post by BoomWav » Fri, Jan 09, 2015, 8:00 PM UTC

mahyarm wrote: post #84

This list of bad behaviors isn't limited to 'young' programmers either. Which is really sad.

This. I see devs that have been programmers for 20 years and still can't name their methods properly. I see most of the things the article talks about daily.