Slashdot Mirror
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?"
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 going to be nigh impossible to get anyone to review your work code, even though they should.
If you want some brutally honest critiques of your code, along with a healthy dose of nit-picking and "cultural bias", try writing for one of the major open source projects like FFmpeg, Gimp, KDE, Qt, etc.
Go ahead and post it. We'll offer plenty of........critique.
I object to power without constructive purpose. --Spock
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.
Ask somebody else to make changes to your code. You'll see plenty of arguments over pre-v-post incrementing or whatever, but the big thing is how well laid out and commented your code is...commercially, the chances of you being the only maintainer in perpetuity are practically nil, so it has to be readable to humans as well as computers. I'm well aware it's my major issue as a programmer, and one that I'm constantly working to improve.
Please consider this account deleted, I just can't be bothered with the spam anymore.
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.
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
You can try posting at least some of the code here:
http://codereview.stackexchange.com/
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.
There is a Stack Exchange site for this -- codereview.stackexchange.com
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.
"First they came for the slanderers and i said nothing."
Why can't you ask your professors to look at non classwork? I on more than on occasion went to my professors for non class related things. It really helped out in their classes, often times they were helpful due to the fact that I took interest outside of class in what they did. Open source is one way to have code review as posted by several other people. I find that my wife is not a good resource... She says things like "You did all that just for that, why not just use something thats already out there..." Work with upper and lower clansmen... While its true they may not have much more experience than you they do have different experience. They often times can see things different than you. Look for mentors in the industry or at work. Lots of people like to hear themselves talk so they are more than willing to ramble on to you.
If you haven't been taught, or feel you haven't been taught, enough about coding conventions (god knows I wasn't), try reading Clean Code by Robert Martin and also Refactoring by Martin Fowler.
A good knowledge of design patterns is also very useful to cultivate. It makes problems easier to handle and solutions faster to devise.
Doesn't your university offer coops or internships? A few months of work in industry should help, even if the wage is shit.
> 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."
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.
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.
There's no -1 for "I don't get it."
Find a mentor.
Join a local user group for the language/technology of your choice and make friends. Find one that is quite experienced and learn everything you can from them.
You make more money if you dont care. And you make less stress.
(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.
In my area, I'm lucky that we have a large number of self-organizing developer groups. I found a bunch through meetup.com, and since I started going I've gotten much in the way of advice and encouragement, and picked up some insight. If you participate, don't just go and hang out -- put together presentations, and ask the audience for their thoughts. Probably lurk a while before doing that, but once you get the flavor of how they are run, put something together that you feel strong at, and present on it.
You see? You see? Your stupid minds! Stupid! Stupid!
We have a saying in bioinformatics: "sadly, that's typical of academic software." It means that the standards the submitter is coding to depend on what field he or she goes into; since we don't know, we can't really say!
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
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.
You just need to maintain/extend the same piece of code for 10+ years. That means calls at 3AM when it doesn't work. It also means having assorted 3rd parties come in and extend pieces of functionality on a regular basis and then leave.
That will teach you more about code maintainability and stability than letting a bunch of self righteous, clever idiots, "review" your code.
Of course, in the meantime... stick to the basics, clarity, consistency, and simplicity. Also, read a lot of other peoples code, you will discover what you like about their code, as well as what you dislike. Then don't write code like the stuff you find hard to understand. One of the big problems with software is that the KISS principle should reign supreme, but everyone thinks they are the next Mozart, and Einstein rolled into one. Rather than building the next Eiffel tower they end up creating the next Rube Goldberg contraption.
Coding dojos do something similar.
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.
I am TheRaven on Soylent News
Mostly because this is something basic you can do for yourself. Can you come back to your old code 6 months later figure out what it does without completely reverse engineering it? I've pointed this out before but I'll say it again. You probably threw away your code 5 seconds after it was graded, right? Well the first thing you'll learn if you go on to be a professional is that you or someone else will be coming back to that code to do fixes and add new features. Ok, it's one of my serious pet peeves is that programmers, codes, software engineers, or whatever you want to call them not writing code to be in any respects readable. So you come back to the code and you can't figure it out without wasting days completely reverse engineering it. (Which is frustrating as hell.) If you can learn to write readable code(so that you can come back some time afterwards and quickly pickup where you left off) you'll be way ahead of the game.(IE you'd be a better developer than most pro's. At least that's been my experience.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
I can (and will) speak only for myself
However, I have the basic philosophy that negative feedback is what improves a product. Kudos feel good, but criticism is what I need to make whatever it is I do, better.
Feels worse, but the results are what I'm after.
Takes a lot of humility, and the ability to look past invective and puerile garbage, to unearth the truth.
Put your stuff out there. There's nothing that geeks like to do more than throw feces at each others' work. Some of that stuff will have merit. Be careful about what you dismiss. Also, be grateful for strokes and positive reinforcement, but also measure that against your own developing sense of aesthetics and style.
You will rapidly learn that there are dozens of ways to do things right. There's a ton of sacred cows and third rails in the IT world (A sacred cow is a concept that is so "holy," that it cannot be attacked, and a third rail is a concept that is so toxic that it should never be touched).
Most of these "hard and fast" rules come from singular events, or as a result of abuse by folks that don't know how to use the tools properly.
Take, for example, C++. There are folks that believe the language is The Manifestation Of All That Is Evil, but I make my living running a C++ shop. I get to hear all the ranting and raving about how I'm contributing to the downfall of civilization, yadda, yadda..
However, it is a very dangerous tool, in the hands of an idiot. Because lots of idiots have blown their legs off with C++, they declare that it is evil.
In some ways, they have a point. If you don't know what you're doing, you can make a fearsome mess with C++. If you decide to become a C++ programmer, then, PLEASE listen to all the negative feedback, and keep it in mind. Be careful in the use of things like multiple inheritance. The Design phase is critical. Far more so, for C++ than for languages like Objective-C.
Know your tools, and put your code out there. Do open source work. Make something that other folks would use. This will result in de facto code review.
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken