How do you know if you are a good programmer?

February 19, 2013 9:15 AM

I was a comp sci major in college. That was 12 years ago. I graduated and as careers often do, I never programmed seriously again since... until now. I've spent the last 2 years teaching myself LAMP and jquery. It was like riding a bicycle. The data structures theory and other small things I managed to retain from my comp sci courses proved useful and in a very short amount of time I was able to rebrand myself a programmer. It's much easier and faster to create powerful, useful software these days than it was 12 years ago. Thing is though, and I imagine a lot of developers do this, the internet has made me more of a code aggregator than a programmer. I have 4 windows open at all times: coding window, app window, the jquery API and stackoverflow.com. Whatever I don't know how to do, I find very quickly on stackoverflow. I copy and paste the code directly and modify it as needed. Done. But I want to be better than that. I follow the general rules of good programming practice as much as I can... don't repeat yourself, be efficient, make your code neat, clean and easy to read. Without having a mentor or a guru around you, how would you know whether or not you are a good programmer or if you are a total hack???
posted by postergeist to technology (19 answers total)

One way of many: if your applications work and are reliable, your clients are happy and you're getting paid, you are a good programmer.
posted by klanawa at 9:30 AM on February 19 [6 favorites]

Here's Joel Spolsky answering this question.

Requisite disclaimer: I am not a programmer, but a lot of programmers I know revere Spolsky.
posted by dfriedman at 9:31 AM on February 19 [1 favorite]

The proof is in the pudding: once your code is released, how many bugs get found? how fast can they be fixed? When, inevitably, your clients want upgrades, how easy is it to add features?
posted by Chocolate Pickle at 9:38 AM on February 19

One of the big challenges of being a programmer is that it's hard to know when you're doing something wrong, because its easy to make poor-quality yet still strictly functional code. The best way is to surround yourself with other competent programmers. This is why many software companies have engineers code-review each other's work - because if one person makes a poor design choice, hopefully another will catch it, or if one person does something well, someone else will read and understand it, and everyone gets a little smarter.

On your own, this is harder, because you have nothing to compare yourself to. Participating in an online community or open source project might help.

You can't really just say, "it works, therefore I'm good". This is how you end up getting hacked and having a bunch of plaintext passwords leaked. It was because "it worked" right up until someone noticed you'd done it the wrong way, and then you find yourself in a really bad position. I've seen lots of poor design decisions and security oversights and such that will generally work until you either add a lot of data, or someone tries to break them. I saw a PHP site a lo time ago that allowed users to upload files into a directory on the server. You could upload almost any file you wanted, including ones named *.php, which instantly became executable. I found out about this when a friend wanted to know how his site got hacked. I saw an auto-complete function that was essentially:

for (i in all_possible_suggestions) {
  if (i.starts_with(string_typed_so_far)) {
    matches.push(i);
  }
}

Which worked fine when there were 10 possible autocomplete options but not so much when there were 10,000.
posted by tylerkaraszewski at 9:42 AM on February 19

IIRC, some forms of 'review my stuff' questions are OK on AskMe--check the FAQ, compose an answerable question within the rules, and show us some code to comment on.

Other than that, conform to guidelines on style and best practices (for Javascript, Idiomatic JS), write code for work and for fun, and read from good sources for ~15-30 minutes a night (any really in-depth source that challenges you).

You may not be a great programmer, but you'll be better than most very quickly.
posted by Monsieur Caution at 9:50 AM on February 19

It might be easier if you have a more clearly defined goal. Some of my goals, over the years:

- Contribute code to a couple open source projects.
- Build a prototype web application in a day or two.
- Make a tool that other people can use.
- Learn enough about a technology that you can be helpful in IRC.

Don't feel guilty about using APIs when you're coding. Almost every programmer works on code that's powered by more code that someone else wrote. That said, I think it helps to be curious about how your tools work and why they're designed a certain way.
posted by yaymukund at 9:58 AM on February 19

Make sure to test your code. Said the software tester. :-) It's important to have comments and cleanly formatted code but "it don't mean a thing" if you pull it up in a browser and get an error!

More seriously speaking, it sounds like you're relearning on your own instead of on a team, and I'm not sure what you are programming: an end-user application? Something on the back end? So I can only make a few general recommendations.

*) How thoroughly have you thought about what your error conditions/corner cases might be?
*) Are you handling those error conditions/corner cases?
*) If you have an end user in mind, how could that person potentially "misuse" the program?
*) What kind of data is coming into your application? How could that possibly go wrong?

You'll definitely see an "unhappy path" orientation in my bullet points but many times those things get neglected at the requirement or design level, and then there are bugs galore.

If you get a job as a programmer, don't rely on your BA or business SME to come up with requirements that contain error handling instructions, ESPECIALLY for back-end or highly technical scenarios. Also, don't throw the happy-path code over the wall and expect the tester to find all the unhappy path conditions that you didn't code for. Take the lead on thinking these scenarios through. A good software tester is a great person to brainstorm with, so you don't have to do it alone.
posted by Currer Belfry at 10:11 AM on February 19 [3 favorites]

Read Clean Code by Robert Martin and see how much of it you already do.

Read up on the idea of Software Craftsmanship.
posted by matildaben at 10:15 AM on February 19 [3 favorites]

Pass some of your code to another programmer and see if they can tell you what it does.

Read through some of your older code and see if you can improve it. Hint: If the answer is "no", you should examine if that's because your old code is perfect, or if you are stagnating.

Look through your current code and see if you could implement the same thing in a different way. Ask yourself which method is better, and why. "Because this is what was posted to stackoverflow" isn't a good enough reason.

Really, it's okay to copy and paste. Just understand WHAT you're copying and WHY. Learn what each line does, so that you can use it again the nest time you need to solve a similar problem.
posted by specialagentwebb at 12:54 PM on February 19 [2 favorites]

So here's the thing: what's your definition of good?

Most developers actually have a hard time with relativism. Incredibly shitty code might just, in fact, be shitty. It might also have had to serve other concerns beyond the Platonic Ideal of What Real Code Should Be - like shipping on time.

Good programmers know how to extract and balance all the bounds placed on a particular piece of code to minimize time (along all relevant axes - time to develop, time to test, time to debug, time to ship - you name it) - for the context in which that particular piece of code lived, as well as a reasonable guess of the contexts that code might need to deal with in the future. Maybe that means copying from SO.

Maybe that means you ship something knowingly flawed - but where market experience will show exactly how it should be improved. Maybe you're in aerospace or medical devices and you absolutely have to get it right or people die. Applying either set of programming standards to the wrong context is...well, wrong.

tl;dr - get stuff done, quickly and with a minimum of future technical debt. Not some ivory tower framework or phd dissertation and not some heap held together with duct tape, bailing wire, and shame. Others will have opinions about your work that may or may not be fair - extract the opinions that matter and use them to get better. Don't just sit there waiting for specs - provoke the specs to be as well thought out as you can manage at the time.
posted by NoRelationToLea at 2:28 PM on February 19

You should work on projects with other programmers and read+criticize+extend each other's code.
posted by value of information at 2:54 PM on February 19

If you took a twelve year hiatus, and have only been back for two years, I don't think you can consider yourself an expert. Past that, I don't know what we can say about whether you're "good" or not (although extensive copy/pasting is a red flag). What's more important is (as others are saying) whether you're finishing projects on time and within budget, satisfying clients, and producing code that can be maintained and upgraded.

If you're interested in getting better, contribute to open source. When you find a bug in a library you're using, fix it, submit a pull request, and get it merged. If the library is good, it'll be well made, and you'll learn a ton from trying to improve it.

Unrelated: I'd consider migrating away from LAMP. There's still tons of PHP work, but the community is a wreck and the platform isn't moving forward. Only a fool would start an engineering-heavy new project on PHP today. Python, Ruby and Node, and just as importantly the frameworks that sit on top of them to make your life as a web programmer easier, are all thriving.
posted by tsmo at 3:25 PM on February 19 [1 favorite]

There are many ways to judge "good". One is code readability. Look at code that you wrote a year ago (or long enough that you don't remember it very well). Can you still understand it, either because of how it's structured or because of comments you added, or both? Knowing what you know now, would you have written it any differently?

Another way is code performance. You haven't mentioned any problems making your apps run fast, so either you have that part down, or you haven't run into any issues yet. Making an app perform well is fairly well understood (measure and optimize, repeat), so it's a skill you can acquire on your own if you haven't already. (There are more advanced things to do to make an app run fast, but I wouldn't say it's necessary for a good programmer to know them, at least to start off with. Note: I don't work at embedly, I just really liked that post.)

Another way is code stability. One good way of measuring that is automated testing of some sort. If you've structured your code reasonably well, it makes it easy enough to test individual methods. Testing (like performance) is fairly well understood, it's just a matter of getting into the habit of always writing tests, at least for any kind of significant change.

Another way is your own ability to crank out code quickly. Part of that is knowing the programming language well, but I personally discount that, because on average I've had to learn a new language every 2 years. But another part of fast coding is being able to quickly translate what you perceive as needing to be done into actual code. If you're good at this, you can know only the basics of the language and still code quickly, because you only need to look up specific classes and method calls to use. But I don't know how to measure that, so as long as you feel like you're coding fairly quickly, you're probably doing fine.

Another way is how current your knowledge of your stack is. How often do you discover some new feature of php or mysql that you might have used a month or two ago, had you known about it? If the answer is "all the time", it probably means you're still pretty inexperienced. If the answer is "not in a while", that's bad too because you're probably not keeping up with changes the way you should. Finding blogs or other sites that talk about new features, and following them regularly, is a great habit to adopt.

These things often interact. A less experienced programmer might worry about optimizing something that might not actually be a problem, so they produce code that is hard to read but *fast*. A more experienced programmer will write the simple version and put stuff to maybe optimize in a separate method, so if it needs to be improved it's in a closed-off area, and they can add a long comment describing the ugly hack they had to put in to make it run faster.

I wrote this long answer because I used to have this nebulous goal of becoming a master programmer. I kind of feel like I am one now, but haven't really reflected on exactly why I feel that way. So these are the things that seem most important to me.
posted by A dead Quaker at 5:46 PM on February 19

Another crucial component is your debugging skills. When something strange and subtle goes wrong, how good are you at (a) noticing there's a problem, and (b) tracking it down. Especially in cases where you don't have access to a debugger, are you able to think your way through the code to see how it got from the input to the bad output? Do you have a mental arsenal of "things likely to go wrong in this sort of situation" that you can work your way through from most likely to most farfetched to help you find the source of the problem?
posted by Blue Jello Elf at 6:20 PM on February 19

Look, if you're copy-pasting code from anywhere for much of your work, you're almost certainly a hack. If you're coding by yourself and have never worked with others in a professional (or major open source) programming setting, you're almost certainly a hack. Getting to be a truly good programmer is basically apprenticeship work. A CS degree may mean that you understand more than others why what you're doing works in certain ways, but academic programmers are almost entirely terrible hacks, so knowledge is not sufficient to escape that curse.

The only skill that you might be able to learn on your own to raise you above hack is testing. If you are regularly writing code that has test coverage sufficient to catch most major bugs before the code is run, you may still write ugly code, but you've risen somewhat above the level of simple hack. Mostly because good testing forces a level of quality on code that few other things can force.

But if you really care about becoming more than a hack, you have to work with other people.
posted by ch1x0r at 7:00 PM on February 19 [3 favorites]

I think it is important to do something other than contemporary web programming, which tends to promote gluing framework code together until things seem to work, if you really want to develop your coding skills.
posted by thelonius at 4:40 AM on February 20

Ok so its possible I may be a hack. That's fine.. its good to know where you stand so that you can do something about it :)

I often wish there was a site you could submit your code to purely for the purpose of peer review. Does anything like that exist?

I guess in one way, i'm about to have a proper learning experience for the better: 2 of my applications are going to be used by thousands of people and I have no idea or not whether they will hold up to the pressure.

There's probably that point where you are a "good enough" programmer, which I think I probably am for most scenarios. However, with anything I do, I believe in craftsmanship. I may not produce works of genius but I definitely don't want anyone to look at what I do and say "this guy has no idea what he's doing".

Since I don't have the opportunity to work in a team, sounds like one of the resounding suggestions is to contribute to an open-source project. I like the idea a lot. How do you get started doing that? Do you just ask to be invited to participate? hows it work?
posted by postergeist at 7:03 AM on February 20

Regarding open source: It's purely volunteer.

Do you use any php or javascript libraries/frameworks to support your work? These are open source projects. Use them long enough and you'll run into a bug, or a feature you were expecting or would be helpful but is missing. Fix it and submit a pull request. See: http://github.com
posted by tsmo at 7:40 AM on February 20

- Old-ish but invaluable advice from Norvig
- Don't mistake knowing a framework with knowing a language: jquery != javascript
- You have the academics, but understanding data structures and algos in an applicable way is crucial
- Poke around C2 and read about everything you don't understand
posted by j_curiouser at 7:49 AM on February 20