Ask Slashdot: Getting Feedback On Programming?

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?"

Comments

Contribute to open source projects

[dwmw2]

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.

Re:Contribute to open source projects

[buchner.johannes]

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.

Re:Contribute to open source projects

[wrook]

When asked this question, I often think, "How do aspiring writers learn their craft?" People who study English read ridiculous numbers of books. This gives them a base to start from when they are writing.

Writing your own code is invaluable, but when you are just starting out it helps not only to contribute to open source projects, but also to read, read, read. I recommend going through some interesting projects and then forming an opinion about which ones have the best code. Don't just look at it superficially; try to form opinions on specific practices, idioms and designs. Then choose a project to work on and try to follow those ideas. From that point the feedback will be more valuable.

One of the things that Kent Beck said one time (possibly in an interview with Floss Weekly; I can't remember) was that his level really improved when he sat down and really thought about what he was doing. He just kept writing things over and over again until he could say exactly why he did everything. IIRC, he wrote down all his ideas and put it in a book on Smalltalk coding practices (which I haven't read yet...) I've been trying to do the same thing lately and it is really beneficial. Forming your own ideas and *then* getting feedback seems to be more productive than writing "just to make it work" and getting feedback.

Just be open minded when you think you have it all sorted out, but someone else thinks your ideas suck ;-)

Post it

[datavirtue]

Go ahead and post it. We'll offer plenty of........critique.

Re:Post it

[Anonymous Coward]

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.

dont worry so much

[Anonymous Coward]

don't worrry so much about improving. you've probably been coding for 2 years or so (given you're in college) and have made amazing progress in those 2 years. the most important thing you can do is use existing libraries. when you reinvent the wheel, no one understands your code. when you use standard libraries, people still may not understand it, but it's going to be faster and more stable than equivalent code you wrote.

i've been coding for 8 years and as long as your code is maintainable, works, commented, and capable, you're doing a good job. also, for the love of god, don't hardcode your file paths or operating system. use a standard library, never do a system call. when you have do, error check it.

Re:dont worry so much

[History's Coming To]

You're right, and I agree, but please humour me with a little devil's advocate...

I recently worked on a pub website that needed to change to reflect the weather (they've got a big beer garden). My first stop was some code I'd written a couple of years back which parsed METAR data from airport weather stations - I'd already done most of the work I needed to do, but there were a couple of bits that I needed to add. Not wanting to use a bunch of (billable) time I had a look around and found a PEAR module that did much the same, plus a lot more. But it was pretty heavyweight for what I wanted, it was producing four dimensional arrays for example, when all I needed was $wind[speed], $wind[direction] and so on.

In the end it turned out to be far simpler to hand code my own, an entire PEAR module was replaced by 20 odd lines of code.

As I said at the start, I generally agree, it's important to be aware of resources like PEAR, CPAN and the like, but (especially when you're learning) you can progress by leaps and bounds by doing some things yourself. Plus sometimes there's a 5 minute solution compared with 20 minutes figuring out how Module-X works and how to integrate the results.

Re:dont worry so much

[wrook]

i've been coding for 8 years and as long as your code is maintainable, works, commented, and capable, you're doing a good job. also, for the love of god, don't hardcode your file paths or operating system. use a standard library, never do a system call. when you have do, error check it.

It's hard to comment based solely on what you have written because I've never seen your code. But I have to question the level to which you are aspiring. There is a huge gulf in quality between code that works and code that is minimal and obvious. You say "maintainable, works, commented and capable". Unfortunately, that could describe code that is barely acceptable all the way up to excellent. I don't really know what you mean, so this might be superfluous to you.

Code that works and is understandable is the minimum quality of code that I think is acceptable. But when you are designing (or refactoring) code, the decisions you make can have a large impact on the rest of the system. Because I read a lot of the original papers on design patterns, I tend to think of code as having a shape (a lot of the earlier descriptions used this kind of metaphor). Code that has an appropriate shape fits nicely with the rest of the code. It has a minimal complexity (i.e., the code is no more complex than the problem it is trying to describe). It also doesn't complicate other code that needs to talk to it.

On the other hand, code with a shape that is not appropriate does not fit in. It introduces complexity based on its shape alone (independent of the problem it is trying to solve). Code that needs to talk to it often has to do something extra, or carry around some extra data to make it work. This creates an inappropriate shape for this new code. When you have one thing that doesn't fit well, it can have a ripple effect that increases complexity all through the code. Not only that, but there can be a multiplying effect. Each work-around that you introduce to accommodate inappropriate code causes more and more complexity.

When I look at large software projects, most of the complexity usually comes from dealing with other code rather than solving the problem. The more code you have, the more complex your system becomes. Most software projects actually solve simple problems, but are still very, very complex. You might think that there is nothing you can do about this, but if you look at system libraries they often simplify your life. This seems opposite to the "more code = more complexity" argument. The difference is that these system libraries usually have an appropriate shape for what they are doing.

Your advice is generally sound. Learning to use appropriate idioms, learning to use appropriate reuse libraries, writing understandable, working code is the basis of programming. But there is another level beyond this. Choosing appropriate code shapes, keeping complexity to a minimum, understanding trade-offs of coupling and cohesion -- This is quite hard and requires a fair amount of practice. Excellent code is not just maintainable and documented, but also minimal and obvious. When other code interfaces with excellent code, it is easy to do so and it introduces a minimum of extra complexity.

IMHO, you should strive for this. If you think that you already accomplish this without thinking about it, then I invite you to look again. I suspect you may be overlooking something.

Learn from others

[Anonymous Coward]

No matter how experienced a coder you are, you can only learn from others. Your code should meet the standards of others - eg look at equivalent source (open source projects). If your code is less than 1000 lines of code, then it can be considered "trivial" - by all means compare with other small projects. But look at 10,000-100k+ line projects and try to understand them. Now, look at your own code, and does it have the same modularity.

Is your code "clever"? Then its wrong. (Vast generalisation, apologies).

Learn the tools to debug and look at memory leaks, bad constructs, coverage etc. Try them - as many as possible, on your code.

And when you have done all of this, if you believe your code is good, then go back to the start of this subject and start again.

Additional points: measure your code quality after you have written 100-500 scripts/programs.

Those doing professional programming are never happy with their own code - they want to enhance and improve it continuously. Often, there is not the time to do this.

Guaranteed way to improve your programs ...

[petes_PoV]

So, when you're programming without an experienced manager above you, how do you go about improving?"

Document them.

Write man(1) pages, describe the source code, include hints about WHY you chose the algorithms you used (and which techniques didn't work). Have a high-level document to say what a program is intended to do, in what environment, with what limitations and how the output should be used (this works for "batch" right through to web pages and apps). Show how it should be built, what test data you used, what the results were and how the tests were performed.

If nothing else, yo will learn that writing source code is the easiest 10% of being a professional programmer and that the other 90% is a hard, dull slog. However, it's that other 90% that separates the "play" programmers from the professionals.

Code Review Stack Exchange

[Anonymous Coward]

You can try posting at least some of the code here:

http://codereview.stackexchange.com/

Time and features/improvements

[sunderland56]

Several ways: one is time. When you go back and look at a routine you haven't seen for six months, does it still look good? Or are you tempted to rip it apart and rewrite it? Did you put in adequate comments, so that you can remember necessary details after that length of time? Sure, coding styles change, but you shouldn't hate your old code.

Another is features. When you need to add/change/improve something, how easy is it? Do you need to rip apart old code, or can you just drop in something new with minimal changes? Does it work when the OS is updated?

Another is *user* feedback. If the project works, doesn't crash, and is easy to use, great. If you get questions about "how do I..." or "why does it..." then think about how your code could change to help the end user.

Stick it in a box

[phantomfive]

Stick your code in a box, then forget about it for six months. Then come back, look at it, and figure out what parts make sense, and what parts don't make sense. And what parts you think are entirely horrible. Sometimes this works on a timescale much shorter, I've seen code I've written the day before, and thought, "what idiot wrote this??" Usually it's not that bad, though.

Three principles to follow, though, and if you get them, your code is gold. Make it:

- Work (if your code doesn't work, or is too buggy, nothing else matters, the code is useless).
- Readable (if no one else can read it, then your design principles won't matter because no one will figure them out).
- Flexible (if your code is flexible, then you can easily deal with changing requirements)

If you can get the first principle, make your code functional and mostly bug-free, then you're already in the top 50% of professional coders. If it's readable, you're in the top 1%. If it's also flexible on top of that, then you can write a book that people will admire for decades. Or a programming language. Sad but true.

Interact with people you respect

[Yoik]

You must know other students who code, trade reviews with friends.

One problem is that to do a decent job of reviewing code, you need to know what it is supposed to do. Practice writing requirements, program specifications, design documents or whatever fits the development style you are being taught, but you will probably have to explain a lot verbally to your friend unless you are amazing. Then he can give you a meaningful review and your users will have a more valuable product.

Doing the reviews of a friends code will teach you as much as getting yours reviewed does. You may be surprised at how much work it takes to make good suggestions for improvement. Also, there is a skill to offering criticism in a way that it will be accepted instead of generating anger.

There are development styles based on this practice, I hope you have good luck with it.

Start reading TheDailyWTF

[MrEricSir]

You should start reading TheDailyWTF. If your code ends up there, you are doing something very, VERY wrong.

And if it doesn't, even better -- you can learn from others' mistakes.

Re:Try coding for OSS

[W3BMAST3R101]

Your "idea" doesn't work within his original request. Is that all you fucking retards know is to caw on about open source? A bunch of fucking jokers. If you can't offer up advice to adhere to the original request then shut your fucking ass. Fuck you and fuck your open source. Fucking retarded bitch ass cunt.

Please don't sugar coat it. Tell us how you really feel.

Re:Try coding for OSS

[wrook]

It's going to be nigh impossible to get anyone to review your work code, even though they should.

This is unfortunately all too true in most cases. Most organizations do not understand the benefit of rigorous code reviews. If they review code at all, they often only look to see if there are bugs, or if (usually fairly arbitrary) coding standards are followed. I've been lucky enough to work on a few teams with brutally honest reviews. It can be intimidating, but in the end it is incredibly useful for developing yourself. Things like pair programming can also be very useful in this regard.

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.

For some reason, I often think about programming teams as if they were sports teams. The way most teams are run, you have a manager who knows little about the game you are trying to play and never watches a game. There are no coaches. You performance is loosely evaluated on whether or not your team wins games, but even then the manager usually tries to make it appear that the team won every game whether they did or not. When they try to get new players, they don't bother looking at the success of the player on their previous teams, or even watch them play. At most they set up some artificial 5 minute drill and evaluate that, but usually they base their decisions on a feel-good interview.

It's quite literally crazy IMHO. In the case of sports it is obvious that this isn't going to work. I'm not sure why it isn't obvious for programming teams.

Re:Try coding for OSS

[bloodhawk]

telling someone that wants critique of his current work to go and do a whole new swag of work on some other project while would provide him with feedback (much of it negative and argumentative about style rather than real substance) is really about the hardest possible way to go about this.

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.

Re:Try coding for OSS

[JoeMerchant]

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

[phantomfive]

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.

Re:Try coding for OSS

[cowdung]

Unprofessional programmers are defensive. A good programmer will listen and learn when he can.