Forgot your password?
typodupeerror
Education Programming IT

Ask Slashdot: Getting Feedback On Programming? 196

Posted by Soulskill
from the in-search-of-a-guru dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Getting Feedback On Programming?

Comments Filter:
  • by dwmw2 (82) on Saturday March 17, 2012 @06:07PM (#39391715) Homepage

    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.

    • by buchner.johannes (1139593) on Saturday March 17, 2012 @06:50PM (#39391973) Homepage Journal

      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.

    • by wrook (134116) on Saturday March 17, 2012 @07:29PM (#39392223) Homepage

      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 ;-)

  • Try coding for OSS (Score:3, Informative)

    by JoeMerchant (803320) on Saturday March 17, 2012 @06:08PM (#39391719)

    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.

    • by wrook (134116) on Saturday March 17, 2012 @08:03PM (#39392387) Homepage

      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.

      • by phantomfive (622387) on Saturday March 17, 2012 @10:59PM (#39393091) Journal

        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.

        • by cowdung (702933) on Sunday March 18, 2012 @03:01AM (#39393883)

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

        • by PJ6 (1151747)

          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.

          He quit because after a lot of work he was finally able to realize just how bad he was. [wikipedia.org]

          This guy was unusual because that almost never happens.

    • by Anonymous Coward

      Codebases are of vast different quality. For example,

      mplayer - not very nice code base - something I would not want to immitate. Not for beginners.

      Qt - fairy good, sometimes rushed. Reasonaly good architecture. Most recommended out of these 3 for beginners - plenty of documentation.

      Linux - mostly top-notch, especially the core stuff. Recommended for experts - code is documentation.

    • by bloodhawk (813939) on Saturday March 17, 2012 @08:08PM (#39392417)
      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.
      • by JoeMerchant (803320) on Saturday March 17, 2012 @10:41PM (#39393021)

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

  • Post it (Score:5, Funny)

    by datavirtue (1104259) on Saturday March 17, 2012 @06:10PM (#39391729)

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

    • Re:Post it (Score:4, Interesting)

      by Anonymous Coward on Saturday March 17, 2012 @06:35PM (#39391907)

      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.

      • Some people will correct you for having variable names over, say, 10 characters

        Variable length limits are important if you are using a language like C, where the compiler is not required by the spec to use more than the first 31 characters of an external identifier (which is great for obfuscating code with old compilers, where you can use multiple names to refer to the same identifier). This limit exists for some old binary formats that placed a hard limit on symbol table entries. If you are targeting an embedded system, long names for externals can still chew up a lot of space in

      • ... others will tell you NEVER use a goto

        NOooo! That is the word the knights who say "Knuth" must never hear!

  • get involved in a opensource project, the bigger the better, they often do QA reviews and force you to adhere to their guidelines and coding practices. Your ultimate test will be pushing something into kernel.org.

    • get involved in a opensource project, the bigger the better, they often do QA reviews and force you to adhere to their guidelines and coding practices. Your ultimate test will be pushing something into kernel.org.

      X is more difficult than the kernel, and probably more important too.

      • If dificulty of understanding code and getting it accepted is the metric, aim directly to Open SSH or Free BSD.

      • by pclminion (145572)

        X is more difficult than the kernel, and probably more important too.

        You gotta understand that with X, they have to be extremely careful what they accept, or they might end up modernizing the system. Nobody wants that.

  • dont worry so much (Score:5, Informative)

    by Anonymous Coward on Saturday March 17, 2012 @06:13PM (#39391747)

    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.

    • by History's Coming To (1059484) on Saturday March 17, 2012 @06:31PM (#39391885) Journal
      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.
      • by phantomfive (622387) on Saturday March 17, 2012 @07:17PM (#39392133) Journal
        It's a tradeoff. You need to be able to estimate the amount of time required:

        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.
    • by wrook (134116) on Saturday March 17, 2012 @08:35PM (#39392541) Homepage

      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.

    • as long as your code is maintainable, works, commented, and capable, you're doing a good job

      I strongly disagree. Anyone in a CS program can debug code that doesn't work, or refactor code that looks bad. The benefit of experience is being able to anticipate what might go wrong in the future or under different conditions. It's about knowing what to look out for before it becomes a problem.

      I'm sure all the newbie coders whose work adorns The Daily WTF thought their code was maintainable and functional, but it shows up on TDWTF because it broke when conditions changed and someone had to go fix it.

  • by History's Coming To (1059484) on Saturday March 17, 2012 @06:14PM (#39391753) Journal
    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.
  • Learn from others (Score:4, Insightful)

    by Anonymous Coward on Saturday March 17, 2012 @06:16PM (#39391767)

    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.

    • Is your code "clever"? Then its wrong.

      No one ever thinks their own code is clever. Other people's code is clever.

      • by CaptSlaq (1491233)

        Is your code "clever"? Then its wrong.

        No one ever thinks their own code is clever. Other people's code is clever.

        No humble person thinks their code is clever.

    • Nah, you can learn from yourself.

  • by petes_PoV (912422) on Saturday March 17, 2012 @06:16PM (#39391769)

    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.

    • Document with care (Score:2, Interesting)

      by Anonymous Coward
      There are a couple of problems with documentation:
      1. Too much documentation in the code renders it harder to read.
      2. The documentation will eventually become wrong because people change the code but do not then fix the documentation.
      • Man pages - yes
      • Documentation at the beginning of the file telling how to use it - yes
      • Documentation within the code - mostly no - learn to write self documenting code. http://en.wikipedia.org/wiki/Self-documenting [wikipedia.org]
      • Re: (Score:3, Insightful)

        by Anonymous Coward

        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.

  • by Anonymous Coward on Saturday March 17, 2012 @06:17PM (#39391775)

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

    http://codereview.stackexchange.com/

  • by sunderland56 (621843) on Saturday March 17, 2012 @06:17PM (#39391777)
    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.
    • by Anrego (830717) *

      Totally this!

      I'll also add that when you find something that you later decide was written poorly, or is unmaintainable .. don't just bin it and move on.. really look at _why_ it's bad and how you got to that point. Sometimes you were just having a bad day, sometimes it was lack of understanding, but sometimes there are things in your design process that should be fixed. Is the problem due to something you could have foreseen? Why didn't you foresee it then! What can you do in the future so this won't happen

  • by Anonymous Coward

    When I was working IT, we would schedule "walk-throughs", a meeting where other programmers would examine the code and offer suggestions. They never became "walk-ons". It was one of the best experiences I had. I gained respect for other's perceptiveness, creativity, and constructive criticism. Since everyone would eventually have a walk-through, we were professional and gentle, because we knew that we'd be in the hot seat sometime.

  • by Anonymous Coward

    There is a Stack Exchange site for this -- codereview.stackexchange.com [stackexchange.com]

  • The professors work for the university. If the dean tells them to help[ with non-academic projects, they should be willing to help. At least that's how it works in many workplaces.
  • Stick it in a box (Score:5, Insightful)

    by phantomfive (622387) on Saturday March 17, 2012 @06:21PM (#39391811) Journal
    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.
  • 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 ther
  • 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.
  • That's pretty much the way to both start networking, and get some feedback on your skills so you can improve.

  • Experienced? Manger? Experienced Manager??????? Man, i am still waiting to see these two qualities in one man, but nevertheless, what this "manager" wants is to have the program at time, even if it is barely working......eventually...
    • I generally tend to agree with this sentiment, save for the case of my current employer, with whom I've stuck around for several years. First time I've worked in an environment where all managers have bachelors and masters degrees in engineering, physics, or biochem; and either a Ph.D. in engineering or an MBA. Best place I've ever worked at, and could not be any closer to the polar opposite of the typical Dilbert-style office.
  • by Dogbertius (1333565) on Saturday March 17, 2012 @06:28PM (#39391875)
    Doesn't your university offer coops or internships? A few months of work in industry should help, even if the wage is shit.
  • by gratuitous_arp (1650741) on Saturday March 17, 2012 @06:36PM (#39391915)

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

    • by msobkow (48369)

      Aside from asking your peers about whether they'd like to do peer reviews, you could also ask them how much experience they have. Just because someone is a student doesn't mean they have no programming experience.

      I and two first-year friends of mine, for example, pretty much skipped our entire first year programming course except when exams were scheduled (with the blessings of the prof) because we'd all been programming machine language since we were 14-15 years old. By the time we hit university, we

      • by msobkow (48369)

        I'll never forget wishing I could just walk out during the first 2-3 classes before I knew attendance wasn't mandatory. We sat through 30 MINUTES of some stupid humanoid trying badgering the prof as to when and where semi-colons were required. It was a brutal, brutal discussion. This individual was as dumb as the proverbial post, and could not grasp the basic idea that you needed a semi colon at the end of every statement except the last one in a code block. It was scary to think this individual might

        • by msobkow (48369)

          Sorry for all the typos and grammar errors. I've got a migraine from hell and I'm having trouble seeing due to auras, so I'm pretty much touch-typing with my eyes closed.

        • This individual was as dumb as the proverbial post, and could not grasp the basic idea that you needed a semi colon at the end of every statement except the last one in a code block.

          While it's true that the semicolon at the end of the final statement is unnecessary, it's also true that relying on the final statement you write to be, well, final is a really bad idea. Taking "advantage" of shortcuts like this is IMO a terrible programming practice and ought to be avoided. Honestly, sometimes it's easier to deal with out-and-out idiots like your classmate than "clever" programmers who write unmaintainable code full of traps for the person who inherits it.

          • by msobkow (48369)

            Dude, we're not talking "C". We're talking a much, much older language called PL/C. If you put a semicolon at the end of every statement as you suggest, the compiler would barf.

          • Umm, no. The grandparent is talking about a language like Pascal, where semicolons are statement separators, not statement terminators. Placing the extra semicolon at the end may significantly alter the semantics of the code, often in quite subtle and difficult-to-debug ways.
  • by Yoik (955095) on Saturday March 17, 2012 @06:37PM (#39391919) Journal

    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.

  • by MrEricSir (398214) on Saturday March 17, 2012 @06:48PM (#39391963) Homepage

    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.

  • by SQLGuru (980662) on Saturday March 17, 2012 @07:03PM (#39392039) Journal

    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.

    • by xhrit (915936)
      IRC is a good place to network with programmers. FreeNode in specific has a large community of very helpful people who populate the programming channels. slap a snippit of your code up on a pastebin, post the link in a busy programming chan and ask "What am I doing wrong?". Chances are you will get a handful of insightful comments on areas you didn't even know you had a problem with. ^^
  • You make more money if you dont care. And you make less stress.
  • Try this experiment (Score:4, Interesting)

    by Tim Ward (514198) on Saturday March 17, 2012 @07:14PM (#39392097) Homepage

    (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.

    • by dwmw2 (82)
      Hm, I'd have said that if s/he succeeds then you're almost certainly guilty of overcommenting your code. A lot of good code is completely self-explanatory. You really don't want to litter it with pointless comments that just detract from the value of the comments that should have been there.

      Nobody needs to see comments like:

      /* Add one to the count */
      count++;

      Yet without that kind of thing, it would be hard to reimplement the code from the comments alone. (Yes, if you have decent JavaDoc-style comme

      • Yes, if you have decent JavaDoc-style comments describing each function, and you have small self-contained functions, then perhaps they could reimplement each function from scratch just by knowing its arguments and behaviour — they don't need the contents of each function at all.

        Now you got what the GP meant.

        Anyway, I don't know if I agree. Writting such kind of comments sometimes takes more time than writting the code, and the function name should be self explanatory most of the times. For an API, su

        • Writting such kind of comments sometimes takes more time than writting the code

          But it can save your behind when you try to use code that you had written months ago. Documenting each method's pre- and post-conditions has saved mine several times. It may take more time than writing the code, but it takes less time than trying to troubleshoot why it's not doing what you expect and ending up discovering that the caller had not met a pre-condition.

      • by rthille (8526)

        /* Add one to the count */

        Is useless, yes. But a comment explaining why isn't. Rationale is the thing missing from the code, and the thing you need most when it goes wrong. I don't need a comment as to what the code is doing, I need a comment as to what it's trying to achieve by doing what it's doing, and why.

        And comments like "returns the current time in microseconds. Can never go backward" which was patently false can fuck right off! :-)

    • by pinkeen (1804300)
      This should be modded funny or I my world view has just been shattered.
    • by msobkow (48369)

      That depends what your goal is. If your goal is maintainable code, try deleting all the comments and ask people to tell you what the code does.

      If they can't figure it out from the function and variable names, you need to stop using non-descriptive names like "i".

  • by Junior J. Junior III (192702) on Saturday March 17, 2012 @07:15PM (#39392115) Homepage
    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.
  • I'm certain Terry Clarke would never expect his advise to apply to something as humdrum as making a computer more useful; but this is the mantra of all artistic endeavours.

    If you can find talented people to work with, so much the better. Either way read! Read good code. Read bad code. Learn to tell the difference. Open source is a treasure trove; it covers the range. Closed source isn't any better; in fact it is often 'secret' because its embarrassing.

    Read some books on the topic. Not algorithm b

  • Clean coding (Score:2, Interesting)

    by Anonymous Coward

    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

  • There are two ways to improve your coding that I know of, that can be done without someone else's input.

    1.) Download code from the many online repositories, and study it. More experienced programmers have interesting tricks that help make your code both better, and more readable. For instance:

    When I was a novice programmer, I would wrap entire statements in an if{} like:

    if(var == true) {
    doSomething();
    }

    which at first seems ok, until you run into bigger blocks of code. By t

    • To further simplify that code slightly, would

      if(!var)
      {

                return;

      }

      doSomething();

      be as equally valid as the latter example you showed?

  • by bored (40072) on Saturday March 17, 2012 @11:26PM (#39393199)

    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.

  • My criteria for software:
    Is it correct?
    Is it performant (enough)?
    Was it produced in a timely manner?
    Can you or someone else go back in 6-12 months and understand it well enough to extend/fix it?

  • Programming is little more than staring at the computer and telling it that it's not good enough. If you can tell the machine, you can tell yourself. Just don't stop. It's all really easy, just keep going.

  • I've been a professional for a few years now, so I work with other people and we work in the same code framework. Code reviews with others are okay, but I think your best critic will be yourself. Go over your old stuff that you don't remember well, and ask yourself "Does this suck?". It probably does. Fix it.

    A programmer is never happy and never considers anything a finished product. Everything can be improved. Also, go to The Daily WTF and make sure you don't do those things.
  • Looked up jm223 [slashdot.org], because combined with the fact it was the first comment by him, it seemed to be a strange nick, a type of a nick that is used by many local trolls, when they are banned, they take the same base nick and add some numbers to it. However there is no 'jm220' , there is no 'jm100' but there is this character, just jm UID 18663 [slashdot.org], and based on his ID and a few comments it didn't seem [slashdot.org] like he is a student in search of a better form. [slashdot.org]

    So it seems it could be a legitimate question.

    The answer is to wor

  • Have you tried posting this same question on stackoverflow.com?

  • While I agree with many of the preceding comments, particularly the ones regarding documenting your code, one thing I would add: Always take the time go back to your code and ask yourself how you could make it more compact and more efficient, both in execution and resource demands. As you realize new efficiencies, they will inform and optimize your thinking process.
  • by NotSoHeavyD3 (1400425) on Sunday March 18, 2012 @10:39AM (#39395307)
    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.)
  • Post your code and brag about how it's superior to everything else out there. This will enrage all the "someone is WRONG on the Internet" types and you'll get tons of feedback about your code's flaws.

    This was also an effective strategy to get the attention of experts on Usenet groups.

  • 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
  • Now is a good time to start good habits rather then developing bad coding habits.

    Read up on test driven design.

    The biggest fail of any developer is in thinking they should write more code then is required to solve a purpose. Many developers love to create grandiose architectures in order to solve simple problems, and every line of code you write (whether it is impeccable or absolute garbage) can result in a defect.

    Test driven design changes your mindset from "Hey, lets dump a bunch of code into an applicati

Wernher von Braun settled for a V-2 when he coulda had a V-8.

Working...