Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Getting Feedback On Programming?

Soulskill posted more than 2 years ago | from the in-search-of-a-guru dept.

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

cancel ×

196 comments

Sorry! There are no comments related to the filter you selected.

Contribute to open source projects (5, Insightful)

dwmw2 (82) | more than 2 years ago | (#39391715)

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 (4, Interesting)

buchner.johannes (1139593) | more than 2 years ago | (#39391973)

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 (0)

Anonymous Coward | more than 2 years ago | (#39391999)

I was going to say there the best way to improve wpuld be to solve problems, eligantly and concisely, but parent is exactly right solve open source problems elegantly and consicely. Mod parent +1.

Re:Contribute to open source projects (5, Informative)

wrook (134116) | more than 2 years ago | (#39392223)

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

Re:Contribute to open source projects (-1)

Anonymous Coward | more than 2 years ago | (#39393031)

My vote is similar- find a major tech site (hard forum, arstechnica, etc) with a forum, and ask a professional from one of the major it/cs companies to comment and critique. I work for one of them and I promise others do too, and they're always looking for bright new minds to help out :)

Try coding for OSS (2, Informative)

JoeMerchant (803320) | more than 2 years ago | (#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.

Re:Try coding for OSS (-1, Flamebait)

Anonymous Coward | more than 2 years ago | (#39391749)

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.

Re:Try coding for OSS (5, Funny)

W3BMAST3R101 (904060) | more than 2 years ago | (#39392015)

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 (3, Insightful)

Anonymous Coward | more than 2 years ago | (#39392173)

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:Try coding for OSS (0)

Anonymous Coward | more than 2 years ago | (#39392465)

Your comment is very similar in style and content to the feedback the OP can expect to receive from the OSS community when submitting any patches.

Re:Try coding for OSS (3, Insightful)

philip.paradis (2580427) | more than 2 years ago | (#39392665)

On the Internet, nobody may know you're a dog, but everybody knows you're an asshole.

Re:Try coding for OSS (5, Insightful)

wrook (134116) | more than 2 years ago | (#39392387)

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 (2)

Anonymous Coward | more than 2 years ago | (#39392397)

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.

Re:Try coding for OSS (0)

Anonymous Coward | more than 2 years ago | (#39392683)

You should, however, imitate the proper spelling of imitate.

Re:Try coding for OSS (4, Insightful)

bloodhawk (813939) | more than 2 years ago | (#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.

Re:Try coding for OSS (4, Interesting)

JoeMerchant (803320) | more than 2 years ago | (#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 (5, Funny)

datavirtue (1104259) | more than 2 years ago | (#39391729)

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

Re:Post it (4, Interesting)

Anonymous Coward | more than 2 years ago | (#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.

Re:Post it (2, Funny)

NicknameAvailable (2581237) | more than 2 years ago | (#39392109)

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

More easily.

quite obvious (0)

miknix (1047580) | more than 2 years ago | (#39391733)

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.

Re:quite obvious (1)

buchner.johannes (1139593) | more than 2 years ago | (#39392031)

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.

Re:quite obvious (1)

marcosdumay (620877) | more than 2 years ago | (#39392281)

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

dont worry so much (5, Informative)

Anonymous Coward | more than 2 years ago | (#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.

Re:dont worry so much (4, Insightful)

History's Coming To (1059484) | more than 2 years ago | (#39391885)

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 (3, Insightful)

phantomfive (622387) | more than 2 years ago | (#39392133)

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.

Re:dont worry so much (1)

Anonymous Coward | more than 2 years ago | (#39392581)

I completely agree. you have to pick and choose which modules you reuse excessively. eventually you'll get a feel for it.

however, if you ever parse a nastran file (a structural analysis fortran based format), you can use a library that supports everything or you can code exactly what you want to support. it's a library dependency vs .100 buggy lines of code. i've replace so many of the 100 lines of code with the sledgehammer library that i've learned while it may not always be as fast, it's always going to be more robust. you'll end up fixing bugs you didnt even know you had.

Don't listen (-1, Troll)

Colin Smith (2679) | more than 2 years ago | (#39391983)

This guy clearly has no idea how software development works in the real world.

Re:Don't listen (2)

Samantha Wright (1324923) | more than 2 years ago | (#39392119)

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!

Re:dont worry so much (4, Insightful)

wrook (134116) | more than 2 years ago | (#39392541)

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:dont worry so much (0)

Anonymous Coward | more than 2 years ago | (#39392875)

if you want an example of my code, check out pyNastran. it's my little open source project. it's not perfect, it's got plenty of areas that are hackish, but "perfect" is the enemy of "good enough". that said, because it's open source, i have infinite budget and can rework those areas. on open source projects, "perfect" is the enemy of a "new features".
http://code.google.com/p/pynastran/

Re:dont worry so much (1)

Capt. Skinny (969540) | more than 2 years ago | (#39392545)

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. Bottom line: if you don't have a lot of coding experience, you don't have the experience to judge your own work.

Re:dont worry so much (0)

Anonymous Coward | more than 2 years ago | (#39392777)

Thank God not everyone believes in not reinventing the wheel. Imagine where we'd be if we were still using the original STL implementations...

It's all in the comments... (3, Insightful)

History's Coming To (1059484) | more than 2 years ago | (#39391753)

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.

github (0)

Anonymous Coward | more than 2 years ago | (#39391759)

(open source contribution)

Learn from others (4, Insightful)

Anonymous Coward | more than 2 years ago | (#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.

Re:Learn from others (1)

phasmal (783681) | more than 2 years ago | (#39392837)

I think the "only learn from others" here is overselling it a bit.

On one hand you'll miss something is you only learn when others learn from your code. You'll miss the ability to learn from how others code. I suggest reading about developing software. Note that this doesn't mean "read about X language" - I mean read articles and blogs about what makes code good.

To take it further, though, you'll miss an opportunity to learn *more* from others, as well as learn on your own if you don't take it further and be introspective about your performance and your code.

The idea is to try an idea or technique out - even take it too far - and simply see what the results are yourself. Read your code after writing it. Read it straight away, and read it much later after you've been doing something else. Spend time thinking about coding, how you've approached things and what the result has been.

Put these three things together (learning from others looking at your code from parent post + looking at others ideas + developing your own) and you'll become a better programmer.

Re:Learn from others (0)

Anonymous Coward | more than 2 years ago | (#39392889)

No matter how experienced a coder you are, you can only learn from others....

Uh huh. Never crashed the most important system in the enterprise, now have you?

Guaranteed way to improve your programs ... (4, Insightful)

petes_PoV (912422) | more than 2 years ago | (#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 (2, Interesting)

Anonymous Coward | more than 2 years ago | (#39392051)

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:Document with care (3, Insightful)

Anonymous Coward | more than 2 years ago | (#39392183)

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:Guaranteed way to improve your programs ... (1)

Anonymous Coward | more than 2 years ago | (#39392359)

Rather than man pages, he should write executable documentation, a.k.a. unit tests.

If you can't write unit tests easily, it's likely that your code has problems. If you notice where you're having problems writing tests, it will point you to where the problems are in your code. On the other hand, if you've got comprehensive tests and they're easy to write, chances are your code is maintainable, which is 90% of the way to being good.

Re:Guaranteed way to improve your programs ... (1)

Anonymous Coward | more than 2 years ago | (#39392793)

petes, your comment about writing out documentation is crap. To the OP, while others are riding the waterfall down to irrelevancy, try MAKING SOMETHING. See if it works. Better yet, test it. Also, instead of WRITING A BUNCH OF CRAP DOCS THAT WILL BE OUTDATED, why not write tests (a la Test Driven Development). Then give it to your peers and see if they can USE it. I'm not talking about the whole program, I'm talking about your code/libraries/mixins/macros/WTFelse you write.

Code Review Stack Exchange (5, Informative)

Anonymous Coward | more than 2 years ago | (#39391775)

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

http://codereview.stackexchange.com/

Time and features/improvements (4, Insightful)

sunderland56 (621843) | more than 2 years ago | (#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.

Re:Time and features/improvements (1)

Anrego (830717) | more than 2 years ago | (#39391883)

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

Don't agonise over it though. Sometimes it's just bad luck, lack of sleep, lack of time, etc..

General advice wise, I like to keep checklists .. and tend to add steps from previous mistakes. A quick little "have you ..." list takes very little time to run through, and can catch a _lot_ of stuff!

Walk-throughs (1)

Anonymous Coward | more than 2 years ago | (#39391799)

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.

Code Review Stack Exchange (2, Informative)

Anonymous Coward | more than 2 years ago | (#39391801)

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

Why so rigid? (1)

hackwrench (573697) | more than 2 years ago | (#39391803)

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 (4, Insightful)

phantomfive (622387) | more than 2 years ago | (#39391811)

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.

Read "Code Complete 2" (0)

Anonymous Coward | more than 2 years ago | (#39391815)

Read Steve McConnell's "Code Complete 2", then do everything it says. It's like packing 5-10 years of experience into 1 book, and it is by far the best book on the subject.
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670

read professional work (0)

Anonymous Coward | more than 2 years ago | (#39391817)

Find and read bodies of code you really like. Compare it with your own work. If you want to sound like a rockstar you might not be able to get them to comment on your demo tape, but you can listen to thier work. Also when joining a team the first thing you should do is survey the scene and adapt.

Why not professors? (2)

buzzsawddog (1980902) | more than 2 years ago | (#39391825)

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.

StackExchange site just for this (-1)

Anonymous Coward | more than 2 years ago | (#39391829)

http://codereview.stackexchange.com

bit of reading (2)

lynnae (2439544) | more than 2 years ago | (#39391845)

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.

forrst (0)

Anonymous Coward | more than 2 years ago | (#39391851)

You could try posting on forrst to get constructive feedback.

https://forrst.com/

get a summer internship (1)

Surt (22457) | more than 2 years ago | (#39391855)

That's pretty much the way to both start networking, and get some feedback on your skills so you can improve.

Read lots of other peoples code, rewrite it (0)

Anonymous Coward | more than 2 years ago | (#39391859)

See what makes other peoples code hideous and hard to read, go about properly formatting/commenting it as you are trying to understand it, and see if there are better ways to reorganize it and possibly refactor duplicate code with defines or templates; basically, spend a lot of time cleaning up crap code.

Manager??? (1)

stanlyb (1839382) | more than 2 years ago | (#39391869)

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

Re:Manager??? (1)

Dogbertius (1333565) | more than 2 years ago | (#39392245)

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.

Coop (2)

Dogbertius (1333565) | more than 2 years ago | (#39391875)

Doesn't your university offer coops or internships? A few months of work in industry should help, even if the wage is shit.

Generic advice (1)

Anonymous Coward | more than 2 years ago | (#39391877)

Study hard and stay in school!

Crap (2)

SnarfQuest (469614) | more than 2 years ago | (#39391913)

It's crap. If you continue on programming, come back in seceral years and you'll agree. Very few people write code in their first few years that they don't come back later with that opinion.

Internal code review (3, Insightful)

gratuitous_arp (1650741) | more than 2 years ago | (#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."

Re:Internal code review (1)

msobkow (48369) | more than 2 years ago | (#39392147)

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 had 3-4 years of programming experience and were way beyond our classmates who were still learning basics like how to work with arrays and how to code loops.

Keep in mind, though, that we had no experience with the professional aspects of code. In other words, we didn't know how to document worth shit.

Re:Internal code review (1)

msobkow (48369) | more than 2 years ago | (#39392195)

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 some day be a programmer.

But we need not have worried. The bozo was failing so bad two months into the course that they quit. The classmates who had to attend lectures to learn the details of programmer were greatly relieved to have monkey-brain gone. None of them could ask real questions because yoyo would not STFU and let anyone else ask a question that went beyond the most basic syntax clarification.

BTW, despite wasting 30 minutes of the prof's time, wank-meister got a whopping 5/50 on their first lab because even with feedback from the compiler, they could not figure out where to put the semicolons. It was pretty pathetic. They'd done so bad the lab instructor held up their work and used it as an example in front of the whole class of how not to write code.

Re:Internal code review (1)

msobkow (48369) | more than 2 years ago | (#39392209)

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.

Re:Internal code review (1)

Anonymous Coward | more than 2 years ago | (#39392559)

please do yourself a favor and turn off everything with a blue led then go to bed !

Interact with people you respect (4, Insightful)

Yoik (955095) | more than 2 years ago | (#39391919)

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.

learn by refactoring.. (0)

Anonymous Coward | more than 2 years ago | (#39391941)

look at your code and honestly answer the question: can someone else understand this? refractor your code until you answer yes.
are there any duplicated code? I.e. cut and pasted or similar code? refractory till answer is no.
this will help you to improve. good luck!

Start reading TheDailyWTF (4, Insightful)

MrEricSir (398214) | more than 2 years ago | (#39391963)

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.

Well... (0)

Anonymous Coward | more than 2 years ago | (#39391965)

When I was having a particularly difficult time writing poetry, my professor told me: stop writing and read. Maybe it works for code, too.

I don't know about feedback per se, but for improving (and learning fun math along the way) try Project Euler [projecteuler.net] . You'll be able to see how other people completed the same problems (and in different languages). It's not really about "what is the right way to do this" but "why is it done this way and not that way."

Read popular software already written (0)

Anonymous Coward | more than 2 years ago | (#39391993)

I learned a LOT by reading the MediaWiki and WordPress sources.

Review it yourself (0)

Anonymous Coward | more than 2 years ago | (#39392007)

After you write a block of code, wait six months and then go back and review it. Chances are if you're improving and learning and gaining experience as you should be, it'll look terrible. You'll be able to critique your own work, learn from your mistakes and learn to avoid problems in the future.

Review your old code!!! (0)

Anonymous Coward | more than 2 years ago | (#39392017)

Read code you wrote 6 months ago, a year ago and two years ago. If you don't see the difference you have not improved....

befrend a professor you respect (0)

Anonymous Coward | more than 2 years ago | (#39392019)

Outside of the intro classes (run by people usually just happy to get the paycheck) there are usually a few professors that actually do open source coding and/or research into programming... they seem to usually teach advanced coding/algorithms. Just network with them, find/ask for something you can maybe help them with and/or ask for suggestions in code that you've written.

Usually these people don't want to withhold knowledge, they wouldn't be in academia if they did, and as long as you aren't completely annoying about it they will most likely be happy to help you with whatever questions they can spare time for. They are there to teach you after-all.

The one regret I have in my college experience was that while I was better then most of my peers at stuff like coding the concepts discussed in class, it meant I wouldn't hit up professors in office hours like the suckup morons, that were in there every time they had office hours to suck up and try and get their programs done for them. Those same professors can be very helpful in recommending smart people later on, since most universities serve a regional community plus a lot of ex-students now in hiring positions looking for people from professors they stayed in contact with.

Review your own code!!! (1)

CiarnOS (1325141) | more than 2 years ago | (#39392027)

Re-read code you have previously written.

Start with code two years old, then a year old, then 6 months old. If you do not see an improvement you probably have not improved....

Re:Review your own code!!! (0)

Anonymous Coward | more than 2 years ago | (#39392069)

My thesis advisor told me this. There is no such thing as good writing. There is only good rewriting. The same applies to code. Go back over old stuff and try to improve it.

Find a mentor (2)

SQLGuru (980662) | more than 2 years ago | (#39392039)

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.

Re:Find a mentor (1)

xhrit (915936) | more than 2 years ago | (#39392319)

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

I work in the industry (1)

Ryanrule (1657199) | more than 2 years ago | (#39392049)

It doesnt matter. You wont be attached to any project long enough to make a difference. Keep your head down, and leave for 20% more pay in 2 years.

Stop caring. (2)

Ryanrule (1657199) | more than 2 years ago | (#39392057)

You make more money if you dont care. And you make less stress.

Try this experiment (3, Interesting)

Tim Ward (514198) | more than 2 years ago | (#39392097)

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

Re:Try this experiment (2)

dwmw2 (82) | more than 2 years ago | (#39392201)

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 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. But that's not quite the same thing.)

Re:Try this experiment (1)

marcosdumay (620877) | more than 2 years ago | (#39392343)

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, surely, the docs are a must have, but for internal code that only one module will touch? I think the answer is not universal.

Document each entry point. It'll save your behind. (1)

tepples (727027) | more than 2 years ago | (#39392973)

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.

Re:Try this experiment (1)

pinkeen (1804300) | more than 2 years ago | (#39392519)

This should be modded funny or I my world view has just been shattered.

Re:Try this experiment (2)

msobkow (48369) | more than 2 years ago | (#39392539)

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

Re:Try this experiment (0)

Anonymous Coward | more than 2 years ago | (#39392899)

The last time i checked, comments were tossed by the compiler. All this is just intellectual masturbation. The other way around is more useful. Strip out the comments, and if someone can't piece together what each function is doing, you coded it incorrectly.

Look for professional meetups (2)

Junior J. Junior III (192702) | more than 2 years ago | (#39392115)

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.

If it's small, crowdsource it (0)

Anonymous Coward | more than 2 years ago | (#39392197)

There's a lot of people on http://codereview.stackexchange.com/ that are happy to critique your code.

imitate, assimilate, innovate. (1)

mevets (322601) | more than 2 years ago | (#39392203)

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 books - although you should read those too - but "Elements of Programming Style", "Software Tools", "Programming Pearls" ( the latter has nothing to do with that baroque version of awk, btw). These books focus on developing the craft.

Yeah (1)

Ryanrule (1657199) | more than 2 years ago | (#39392235)

"So, when you're programming without an experienced manager above you, how do you go about improving?" You dont, you either do jackshit, or change jobs.

LKML (1)

Anonymous Coward | more than 2 years ago | (#39392351)

Post to LKML.

Clean coding (2, Interesting)

Anonymous Coward | more than 2 years ago | (#39392469)

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.

Run your code, and analyse it (0)

Anonymous Coward | more than 2 years ago | (#39392663)

One of the best ways to measure the quality of your code is to run it. This might sound obvious, but in a corporate environment there is a lot of pressure to develop software quickly. If you spend a lot of time making your code perfect to read, and extend, you may not be making the best use of your time.

The iterative development methodology is a good way to develop software, I feel. You write enough to get your software working, and deploy it to be tested as soon as possible. If it works, then you are doing a good job. If it doesn't you still have time to improve it. You will need to monitor the performance of your code when it is running, and make adjustments, if it's not meeting your expectations though.

Next time you go to write a similar functionality, you will know from experience what worked, and what didn't.

If it does what it is supposed to... (0)

Anonymous Coward | more than 2 years ago | (#39392717)

and doesn't crash randomly while doing it, I am sorry to say you will be ahead of almost everyone these days, proprietary and open source alike. It really pains me that computers seem to becoming slower and less stable, even as hardware becomes faster and more resiliant.

static analysis (1)

Anonymous Coward | more than 2 years ago | (#39392735)

Look for a static analysis tool for the language you are using. That should give you plenty of feedback that is generally accepted among veteran software developers.

The answer (0)

Anonymous Coward | more than 2 years ago | (#39392753)

Let me save you alot of time. Your code is shit. Does it work? If so its passable shit. Does it make us money? If so, its good shit.

Just use me as a reference (1)

Billly Gates (198444) | more than 2 years ago | (#39392799)

I am a badass coder and here is some of my awesome code from my login page in php 4 that is super secure

$query_login="select * FROM user";
$result_login = mysql_query($query_login) or die("Your passwrod is might be bad I think"); //$login_check = mysql_num_rows($result_login);
while($row=mysql_fetch_array($result_login))
{
$username=$row["username"];
if ($username==$username1)
{
echo "";
echo "window.location.href='login_error.php?rec=qq';";
echo "";
exit;
}
}

Certification (0)

Anonymous Coward | more than 2 years ago | (#39392983)

Certifications, such as Oracle Certified Professional Java Programmer, aren't extremely popular, but studying OCPJP (then SCJP) forced me to learn a lot of bizarre intricacies of Java we glossed over in college (i.e. { byte a, b; a = b = 1; a = b + a; } fails to compile because + returns an int, so you need a cast a = (byte) b + a;).

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?