Ask Slashdot: Getting Feedback On Programming? 196
jm223 writes "I'm currently a student at a major university, where I do IT work for a fairly large student group. Most of my job involves programming, and so far everyone has been happy with my work. Since we're students, though, no one really has the experience to offer major advice or critiques, and I'm curious about how my coding measures up — and, of course, how I can make it better. CS professors can offer feedback about class projects, but my schoolwork often bears little resemblance to my other work. So, when you're programming without an experienced manager above you, how do you go about improving?"
Re:Post it (Score:4, Interesting)
Seriously, though, the problem is that so, so much about programming structure and form is debatable. Since he's a student, he probably does have some obvious rookie mistakes that can be corrected, but he'll still get told many absolutes that are really not at all absolute among good programmers. Some people will correct you for having variable names over, say, 10 characters; others will tell you NEVER use a goto; others will give you a very hard limit on the number of lines any method should be -- on /., I've seen someone claim no more than 10, which is ludicrous to me. A result of all this is that you should ask for advice but judge the reasoning of the advice rather than accepting it blindly (and re-judge it again when you have more experience), and doing that while also pleasing the person giving you advice can be a tricky social situation.
Re:Contribute to open source projects (Score:5, Interesting)
Contribute to open source projects. You'll get plenty of feedback. Some of it might be quite, erm, 'robust', especially with certain projects. But it'll almost all be useful, and you'll be doing something worthwhile.
In open source projects, there are problems of all scales. As a newbie, and unfamiliar with the code base, you will only be able to tackle few bugs. So choose a project and a bug you are interested in, and get into it. Bug after bug, you will be able to tackle bigger problems, improving your programming skills (reading code, design, implementation, testing, communication, etc.).
Don't get bummed if your first code contribution doesn't work out or a interesting project isn't communicating with you. Just move on or do your own thing if you really think it is worth it.
Document with care (Score:2, Interesting)
Try this experiment (Score:4, Interesting)
(1) Print out your code
(2) White out all the actual code, using Tipp-Ex, leaving just the comments visible
(3) Give the result to one of your fellow students, and ask him to rewrite your code in a different language.
If s/he fails, you didn't write enough comments.
Clean coding (Score:2, Interesting)
The most useful thing that I've recently discovered in my 3 years of professional programming is "Clean Code" by Robert C. Martin. It covers most of the lessons that I've learnt the hard way.
The things that don't necessarily seem important when you're striving to get something working are usually the things that make a difference. Naming of classes, methods and attributes so that code describes what it's doing, keeping your in-code documentation up to date so it doesn't lie and adhering to SOLID principles (http://en.wikipedia.org/wiki/SOLID)
I'd thorougly urge you to read it. My colleagues (whom I respect greatly) have also recommended "The Practice of Programming" by Kernighan and Pike, that's probably also worth a look too.
Re:Try coding for OSS (Score:5, Interesting)
If you really want comments on your work you need to find someone with experience that is willing to give up some time to mentor/review your work. "Sometimes" you may even find the odd lecturer that has some industry experience, though they seem to be pretty rare and many have a highly inflated (and unexplanable) opinion of there own work. Or perhaps look at some of the online programming forums, many people want peer reviews and swapping code for review not only gets your own work reviewed but gives you exposure to what others produce.
This would be great, if you can make it happen. In the world I live in, the number of people available to think about anything - programming, or otherwise, decreases like an e^(-x) curve, thousands will give you the 30 seconds it takes to whip off a quick sound-bite of "what they think" after skimming over your question, hundreds will give an extra 60 seconds to actually read the question skim the reference material and cogitate about what you might want to hear rather than what they want to say, tens might take the time to look at a one page program and think about what you're trying to do, by the time you get to 10 pages of code you'll be lucky to find one (experienced, knowledgeable) person who will actually do it. If he's been programming for long, I assume his projects are getting up there in size.
At least the arrogant pricks defending their OSS fiefdoms will read your code most of the time, if you've submitted it in the proper form. Sure, they'll throw it back in your face if you've used superfluous parenthesis or non-style compliant indenting without even checking to see if it works; but, occasionally, they really do want that bug fixed and they will give you some substantial feedback about your methods. And, if you keep submitting to different projects long enough, you'll eventually find a reviewer who isn't an arrogant prick. The guys at Qt were rather nice about it when they said "oh, nice fix, but we're deprecating that whole branch for version 5, so we're not going to take the time to regression test your code and just leave the 4.x trunk broken for every Intel laptop graphics chipset made in 2008-2010, after all, it's actually Intel's drivers that are buggy."
Re:Try coding for OSS (Score:5, Interesting)
One of the things that always bugged me as a programmer was that never once in 20 years did anyone ever evaluate my performance on the basis of the quality of my code. In fact, it was unbelievably rare when the person who evaluated my performance ever even looked at my code. Many of my immediate superiors would not have had the ability to judge one way or another, but even then they never bothered to ask my peers to look at my code and comment.
It's so hard to do this. I had one coworker who wrote basically unreadable code, that was riddled with bugs. He knew that he had problems, but wasn't sure what. I tried to suggest a few things, but he was really defensive. He disagreed with me, and argued every step of the way. So I took a slow approach, and gave him extremely mild suggestions over time. Eventually he started to improve, but then he quit.
It is really hard to give programmers coding advice, because usually they are defensive, and will defend their code. On the other hand, I did have one coworker who actually asked for advice from time to time, and when I saw places he could improve, I emailed them to him.