What most young programmers need to learn • Hacker News Board

Re: What most young programmers need to learn

#61

Post by jimmaswell » Mon, Jan 05, 2015, 4:50 PM UTC

vog wrote: post #3

> Code in comments [...] When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code. To my experience this is a common symptom of not using a version control system. You change a line of code, but you want to be able to undo if it doesn't work, possiblay half an hour later when you changed other places of your code (so your editor's undo is…

Maybe for just a small code segment, a comment is a lot more convenient than going all the way through git for it?

What if there's some functionality in a method you're not sure you want to take out or change or not, but you've also added to the rest of the file, so you commit it with a small code segment commented out and a short explanation? That's not hurting anything and it'd be a PITA and overkill to put it in a different branch or make a separate commit only including it or something.

Re: What most young programmers need to learn

#62

Post by balabaster » Mon, Jan 05, 2015, 4:52 PM UTC

tragic wrote: post #60

Bahamut wrote: post #57

From someone who started as a developer only 2 years ago, I found the stuff about how to properly design classes to be the hardest part. There is not enough touted articles on it on the internet. For example, how would a developer know to break [insert functionality] into a separate method? It is not always obvious to junior developers to break a method into smaller chunks, especially when they understand every line…

A common approach is to describe the functionality aloud. If your description includes the word 'and', then there may be a problem ("this method increments the foo counter, and makes the tea").

I don't think there's anything wrong with any method that also makes me tea :P

Re: What most young programmers need to learn

#63

Post by justifier » Mon, Jan 05, 2015, 4:56 PM UTC

freework wrote: post #55

I disagree with his last point. There was once a time when I was obsessive about not copying pasting code. Over time I eventually learned that sometimes it better to just copy+paste a code snippet a few places than being dogmatic by making sure that nothing is ever duplicated. My rul of thumb is that if there is branching then don't copy, if there is no branching, then you can copy+paste it. This snippet should only…

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 maintain if you do this:

    function dodoan() {
      do_something();
      do_another_thing();
      another_call();
    }

then copy paste dodoan() as many times as you want

though i do agree all rules have their exceptions and should be handled in such a way that allows for future alterations stead some obsessive mindless adherence

Re: What most young programmers need to learn

#64

Post by codyb » Mon, Jan 05, 2015, 5:14 PM UTC

grimborg wrote: post #51

The Clean Coder is a good read for starting programmers. It goes beyond code to what it takes to be a software professional. http://www.amazon.com/The-Clean-Coder-Professional-Programme...

As well as the extensively reviewed, recommended, and appraised "Code Complete" [0] by Steve McConnell

I'm working my way through it now (1+ year of professional experience) and it is a magnificent way to improve the quality of your code. I read it off and on, my goal is only 40 pages a week so that I'll make sure to find the time to do it (I'm doing a masters program and enjoy living in NYC too so setting huge goals doesn't work well for me).

Every time I crack it open, I find myself inspired to write better, clearer, and more concise code. Sometimes you just need a nudge to get back into doing things you already know you should be doing.

Finally, constantly learning, I think, is the best way to become a proficient, and then skillful professional software engineer. Many programmers become proficient and then level off. And that's good enough. But if you truly wanted to become one of the top 5% in your field you need to do something called deliberate practice. Reading 'Talent is Overrated' [1] really exposed me to the theory of constantly challenging yourself in order to grow. I really recommend it, I find myself trying to apply the theories to all areas of my life.

[0] - http://www.amazon.com/Code-Complete-Practical-Handbook-Const...

[1] - http://www.amazon.com/Talent-Overrated-Separates-World-Class...

Re: What most young programmers need to learn

#65

Post by Bahamut » Mon, Jan 05, 2015, 5:24 PM UTC

tragic wrote: post #60

Bahamut wrote: post #57

From someone who started as a developer only 2 years ago, I found the stuff about how to properly design classes to be the hardest part. There is not enough touted articles on it on the internet. For example, how would a developer know to break [insert functionality] into a separate method? It is not always obvious to junior developers to break a method into smaller chunks, especially when they understand every line…

A common approach is to describe the functionality aloud. If your description includes the word 'and', then there may be a problem ("this method increments the foo counter, and makes the tea").

It is the minute details that are sometimes the problem. For example, if a developer is iterating over an array to do something to each element, there is a good chance that that iterator should be separated out in the event that it may be reusable (if using something like map).

Re: What most young programmers need to learn

#66

Post by mod » Mon, Jan 05, 2015, 5:37 PM UTC

k-mcgrady wrote: post #58

TeMPOraL wrote: post #26

Earlier quoted context omitted.

> I also see this from people who are using VCS, but that's mostly because they are overcautious and/or have not really gotten "warm" with the VCS. Yeah, that could probably describe me. Reverting a particular piece of code back from VCS seems like more work (the kind of "I need to think about it" work), which is enough for me to leave bits of code commented when working on some particular task. I never leave them th…

This is what I do as well. I use VCS but it's more work. If I'm just refactoring a piece of code I comment it out while I work on the new stuff and test it. It also has the added benefit that I can reference the old code easily if needs be. Occasionally I will commit with the commented code still in place (until I'm 100% confident with my new code) but I usually follow that up quite quickly with a commit removing it.

I'm roughly in this boat as well, though I don't want to be.

I'd rather be intimate with git.

Re: What most young programmers need to learn

#67

Post by mod » Mon, Jan 05, 2015, 5:42 PM UTC

innguest wrote: post #44

dschiptsov wrote: post #10

Scheme. As still the best "small" language to teach fundamental principles (everything is a first-class value, symbols are references to values - naming, procedure composition and nesting as the basic building block, ADTs, immutability of the data, evaluation strategies - eager and lazy, and what is meant by "mostly functional language", etc.) and shapes of data structures (list, three, table). It will pay back with…

I agree with everything you said here; I particularly agree with the part where you say that after knowing Scheme and Haskell everything else becomes easy and boring. Does it ever. Makes me question why I got into programming now that I see the bigger picture of what I have been diligently trying to master for over 15 years. To the beginner I'd say: study Scheme and Haskell. Understand them. Once you do, look at othe…

Maybe it's like cheating in video games.

Maybe we should all play the normal game instead of turning on god-mode Scheme?

I'm not going to lie: I don't want to be bored or burnt out.

Re: What most young programmers need to learn

#68

Post by spacecowboy_lon » Mon, Jan 05, 2015, 5:44 PM UTC

Bahamut wrote: post #57

From someone who started as a developer only 2 years ago, I found the stuff about how to properly design classes to be the hardest part. There is not enough touted articles on it on the internet. For example, how would a developer know to break [insert functionality] into a separate method? It is not always obvious to junior developers to break a method into smaller chunks, especially when they understand every line…

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

Re: What most young programmers need to learn

#69

Post by bpyne » Mon, Jan 05, 2015, 5:45 PM UTC

deeteecee wrote: post #21

I'm a junior programmer still so I'd like to share my thoughts regarding this post. I'd actually like to say that I've been aware of all these (code commenting, incorrect function names, etc.) and the thought of changing them is always "it takes up time" or "you don't know if it's worth the time." But I'm always asking my superior that specific question: "can I get rid of this?" Unfortunately, wherever I've worked, I…

Just a few points...

I'm happy you are not afraid to call yourself "junior". Humility goes a long way to becoming a great programmer.

Asking permission is obeisance but it is also communication. Whoever you asked may have knowledge of dependencies upstream or downstream. By asking, you gave that person the chance to add a little context to the change you propose to make and, quite possibly, prevent the team from working overnight to correct an issue you created. Even with 25 years in the field, I still ask other engineers about changes I want to make. Quite often we talk through any ripple effects before I set hands to keyboard.

Be especially careful in modifying interfaces, library calls, etc. Basically, any module that other systems depend on should be modified with a lot of caution and testing. Your caution should grow at least linearly with the dependency graph.

Over time you will develop a sense of which changes you can make without asking, which changes you should talk with others about, and which ones to stay clear of.

Your primary responsibility is creating good software. Your second responsibility is staying employed. Don't fret over every oddity you see in a code base. Refactoring is good for all the reasons people listed in the comments. Figure out which ones have the highest value and talk with the other developers about them. ("Live to fight another day")

Re: What most young programmers need to learn

#70

Post by gknoy » Mon, Jan 05, 2015, 5:49 PM UTC

UrMomReadsHN wrote: post #46

danieltillett wrote: post #9

Earlier quoted context omitted.

I am guilty of commenting out code when I am working on a problem, but before committing I remove it unless it is the simple version of some function that I made way too complex in order to improve performance. I find it easier to understand later what the complex code is supposed to be doing if I have the simple implementation in the comments.

No... you are making your code hard to understand to others by doing that. Thats if you check it in like that. Nothing wrong with leaving it there during development.

I disagree. If I see 25-40 lines of something that LOOKS like it should be simple, it's tempting to replace it with the four line version. A comment which says, "You might think this would be better as {{4 lines}}, but it is too slow... because this/that/etc" can be VERY helpful, so that one doesn't reproduce the problems (and the time fixing) that caused the initial un-simplification in the first place.