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?"
Contribute to open source projects (Score:5, Insightful)
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.
It's all in the comments... (Score:4, Insightful)
Learn from others (Score:4, Insightful)
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 ... (Score:5, Insightful)
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.
Time and features/improvements (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Re:dont worry so much (Score:5, Insightful)
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.
Internal code review (Score:4, Insightful)
> Since we're students, though, no one really has the experience to offer major advice or critiques
See how the other students would feel about internal code or design reviews. They may or may not know what it is and they may take it the wrong way or not like the perceived criticism from peers, depends on your relationship with them.
About none of you having much experience -- maybe not, but part of college is wrestling with challenging questions that you don't know the answer to with people who don't know the answers either. If you're working for the college, even better. It may only lead to marginally better code, but hopefully you would all learn from each other. And it would look good on a resume to say you "improved coding standards and helped foster growth among colleagues by proposing and implementing a peer code review system."
Interact with people you respect (Score:4, Insightful)
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 (Score:5, Insightful)
You should start reading TheDailyWTF [thedailywtf.com]. 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:dont worry so much (Score:4, Insightful)
1) to write, debug, and maintain your own code
vs 2) to understand, debug, and maintain (your integration with) someone else's code
The way to get good at estimating those things is to try it. Try integrating someone else's code, and try writing from scratch. After a while, you get a feel for how long each one will take.
Re:Try coding for OSS (Score:3, Insightful)
The quality of open source is usually pretty high, and there is a ton to choose from - from trivial to major projects. Telling someone to look at properietary or closed source code is likely to lead to a dead end.
Contributing to open source is a different issue: there are usually barriers to entry and a degree of "cliqueness", but thats understandable. Open source projects provides a good vehicle for understanding how groups of people interact. Sometimes its not just about coding and algorithms, but also about acceptance by peers.
Re:Document with care (Score:3, Insightful)
Too much documentation in the code renders it harder to read.
Only if you're doing it wrong. If you're doing it right, you won't be adding too much. It just won't happen.
The documentation will eventually become wrong because people change the code but do not then fix the documentation.
Those people should be fired. Preferably out of a cannon.
Man pages - yes
Documentation at the beginning of the file telling how to use it - yes
Those are okay.
Documentation within the code - mostly no - learn to write self documenting code.
This is absolutely wrong and inept. Comments are not for telling what the code does; they tell why it does it. You will never write good code until you purge yourself of the stupid that comes from this fundamental misunderstanding. Once you get this straightened out, you will never produce bad comments again.
Re:Try coding for OSS (Score:5, Insightful)
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 (Score:5, Insightful)
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:dont worry so much (Score:5, Insightful)
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.
Re:Try coding for OSS (Score:4, Insightful)
On the Internet, nobody may know you're a dog, but everybody knows you're an asshole.
Re:Try coding for OSS (Score:5, Insightful)
Unprofessional programmers are defensive. A good programmer will listen and learn when he can.
Re:Comments mean your code is BAD (Score:4, Insightful)
For some reason people on slashdot are super anti anyone that says comments are bad
We are, because it's a stupid opinion to hold. Comments are not bad. Redundant comments are bad. There is a really good, simple, way of judging the quality of a codebase: Picking a random function, how much more code do I need to read before I understand what this function is doing and why it's working that way? Clearly named functions and variables go a long way towards explaining what the code is doing, but not necessarily why. Doc comments mean that you don't need to read any of the other functions that are called, just their documentation.
Comments are also invaluable when the code is buggy. They tell you what the author of the code was thinking and therefore what they intended to write, which makes fixing the code much easier.
I've had to maintain code written by people who think comments are bad. In general, I would consider removing their keyboards a good way of improving overall code quality.