Your Code Sucks
girldeveloper.com
girldeveloper.com
The jwz-documented Netscape rewrite debacle is brought to mind by the original posting.
The other extreme of leaving the code to rot is just as bad. "It works... for now."
There are too many little changes that occur in either the larger system itself, the platform, or even the OS (and of course the customer) to just say "it works." This then leads to, "Well it should still work" as time goes on.
I really think the problem is that most devs don't know how to read code. Sure there are some programs that have pathological problems in them, but those are relatively rare. It is often just design choices or programming patterns that a particular dev doesn't like or understand.
I was dealing with some CSS recently that was just odd. Everything (yes, every single block element) was a float resulting in a soup of fixes and workarounds because of the oddities they introduced earlier. In rewriting it, I managed to lose more than half of the CSS statements and make it be an almost pixel perfect match and be more browser compatible.
It was written by another contractor and I was contracting. Handling the politics delicately was the real problem.
But I've seen code that really does suck, too, and I still had to understand all of it to really know the code is solving the wrong problem or alternatively not solving any problem at all.
Personally, my worst experiences have been inheriting software written by kids just out of school who have read a lot of books on design patterns. On the bright side, I've learned some really interesting things from these guys here and there, they are typically really, really bright and extremely well read.
I've had instances where I rewrote core code from these type of guys and gotten it down to 30% of its former size, much more understandable, much faster, and much more flexible. But if we went into a meeting to discuss which is the better way, they would likely blow me out of the water (despite public failure) because they are young, inexperienced, and supremely confident.
I think maturity of attitude in software developers typically doesn't set in until 10+ years on the job. So many of the young people entering the field are all educated on the new "yet another revolution" practices (TDD, Agile, etc), and they are so confident, because they are smart and educated (which they are) that it makes interacting with them almost impossible. I've dealt with junior and intermediate developers that seem to think its impossible they could be wrong, they will cling to an idea even though you can easily give several examples where their theory breaks down.
I guess this is just the nature of our business, it is a bit too abstract, and education can be too easily mistaken for knowledge.
That said, there's no doubt there's code that definitely sucks. Some of it is mine, too. If I wrote it last year, it sucks. If I wrote it yesterday, it's really great. You can really see how much I've learned in a year when you compare it with my previous sample. At least if I have to rewrite the old code, I'll know what traps and special scenarios I need to watch for if I properly commented it.
A lot of people think code sucks if they simply can't understand it at a glance. Of course you think yesterday's code is awesome, you just worked on it yesterday. But in 6 months, with the issue completely out of your mind, even if you haven't advanced, you might think it sucks.
People who don't do this: please don't underestimate the importance of this.
Be descriptive as possible with the comments on possibly clever/incomplete code - you will thank yourself months later when you realise:
x += 1 # border
Yes, at the time you wrote the code, it's perfectly obvious to you, but you will forget it and think to yourself next time: 'wtf is this being incremented by 1 for, what about the border, is the border being incremented?'
If you hesitate even for a second about the possibility of your code being misinterpreted in the future, either fix it on the spot or add a damn descriptive comment.
Comments are better for explaining the rationale behind seemingly arbitrary or crazy design decisions - "I would have done obvious thing X, but that causes huge problem Y". Why, rather than what. For things that provide important context, but could not be expressed in the language itself.
Many "what" comments should instead be static typing declarations, asserts, or tests. At least that way, people will notice when they no longer hold. Comments are just declarations the language ignores. (Citations, like "implements algorithm X, see Okasaki 1999", are fine though.)
Good programmers leave comments saying "this is ugly because X".
Bad programmers will always have a reason to call everyone else a bad programmer, because that's the easiest excuse for sucking.
Also, about half the lines of the script was other very similar blocks of code that had been commented out.
When I hear about bad code, I'm thinking about code that is not scalable or unmaintainable. Or, it doesn't follow a proper design pattern or maybe trying to be too clever coding. Or, maybe have resource leaking. Somethings just would never cross my mind.
I need to get out more.
'Your Code Sucks' can be shorthand for 'not-invented-here', 'I'm not able to grok your datastructure' or 'I don't have experience enough to take this all in but if I scrap it and rewrite it it will be on my level' as frequently (or even more frequently) than that it really means your code sucks.
I'll say 'my code sucks' easily (especially the morning after), but your code might need some incremental improvement until I understand it thoroughly enough to make a judgement call. And in the interest of diplomacy I'd probably give you a hand refactoring it instead of passing judgement. I might even learn something.
I don't disagree that often I fail to understand why someone did something a certain way, on the first reading. But after I understand all the logic, and have run test cases etc., the fact that code is poorly structured, buggy, full of duplication, excess global variables, etc. is sometimes unavoidable. When that happens, I have to conclude that it does indeed suck.
I got a copy of the code, and it all looked like boilerplate Rails stuff, pretty much by-the-book generated stuff. A first thought was, well, how freakn' long could it take to produce this? But it occurred to me that when you look at code (good or bad), there's often no way to know how the author got there. How much code was scrapped? What ideas were explored? Even when you have the repo history there's still no way to know what might be missing.
It's hard to look at code and make any judgments about the developer, since there are often numerous details that informed the decisions made along the way.
"I've had a chance to look through the existing codebase, and I'm sad to report that it's in pretty bad shape. I'm afraid we're going to need to rewrite a bunch of it before we can even move forward."
However, some code does suck. There is a certain type of easily preventable badness that slowly manifests itself in a project that isn't being effectively maintained. Case in point in my current world of "joy":
public class MainForm
{
public static Form FormInstance;
public MainForm()
{
FormInstance = this;
}
}
This code does in fact suck unambiguously.
And what exactly does "At this point I wasn't decimating things all together" mean? Should "decimating" be "denigrating"?
The ability to tell the difference comes with experience, as does the ability to abide the first three.
However, I have found that experience has changed my approach to the last away from "complaining" and toward "fire and brimstone sermon".
Oddly, I've found that experience has changed my approach in the exactly opposite way.
- Indented in another way than I preferred to or the format was in some way not the way I do it (camelCaps, spaces around parenthesis.
- The code was doing to much in a single line. Preventing readability, etc.
- It had inline HTML or just anything less than 100% separation of code and presentation.
- I didn't understand it
These days I almost never think anything sucks, even though it's written by some beginner right out of grad school. However there are exceptions and now the things that make my dislike some code might have something like:
- Big huge functions that do too much without splitting it up into smaller chunks
- Things done in many lines of code that can be done in a single line [in a simpler/faster way].
- Obvious slowdowns, such as way too many SQL queries than needed, for loops that go through 10,000 cycles when you can get the same result in 15 cycles, etc.
I'm guessing in the future it will be something else entirely that I will look at and vomit. And it will most probably be my own code.
But "I showed that code we paid you for to someone else and they said it sucked" is unprofessional and pointless.
The only response I can think of was "That's interesting - could you perhaps give me some feedback as to what ways you were dissatisfied with the app?"
Either way, sometimes I do in fact see code ('not-invented-here') that clearly does not suck. It's concise, modular, comprehensive, and easy to trace and modify. There's a consistent and seemingly effortless balance abstract and domain-specific functions and logic. There might be jokes and humor in the code, but nothing that ever gets in the way of understanding. Nothing like "hmm I don't really know what to call this temporary variable so I'll make up a funny name for it"
That said, I sympathize with anyone who is doing iterative client work on an hourly basis, and is called out on re factoring. Explaining the cost and benefit of refactoring work to clients can be a hard upsell, and IMHO helps separate great clients from not-so-great.
Some code really does suck.
I've read a lot of code in my lifetime, and some of it genuinely sucks. There is a such thing as a bad developer. There are people doing programming who really have no talent for it, or for some other reason are just really bad at it. Sometimes it is due to lack of experience. Sometimes it is due to the person not caring at all. And I am sure there are plenty of other reasons. It doesn't mean that a person can't get better, often they can get much better, but people do write code that sucks.
Understand, I think I am now much slower to be harsh toward other people's code than I used to be. In fact, I regularly give people the benefit of the doubt. Why? Because I've worked for that megalomaniac that wants done yesterday what can't possibly be done in a month's time. You know, the one that thinks that because his work consumes his entire life, and causes him to neglect his family and other responsibilities, so should yours. I've worked in multiple high-pressure situations, where no one cares what the code looks like, as long as it is done tomorrow. And you know what? Sometimes in situations like that people slap together whatever they can (as fast as they can) with duct tape and chewing gum, whatever it takes to get that unreasonable person (or people) off of their back. The results are often ugly, and you can argue whether the person could have done it better in the same (or even less) time. But I think it is worth cutting the other guy some slack. Thankfully, I no longer work for the megalomaniac (and haven't for many years) :-D
However, getting back to my original point, there is code that sucks. It may not be as prevalent as some think that it is, but believe me, it is out there (even after giving the other guy the benefit of the doubt).
Geez, what's up with me and the parenthetical kick today (perhaps I've been writing too much Scheme code recently). :-) <- got one last one in there.
Notice how your navigation elements are 5px larger than the body text. But when we think about it, the primary use of a blog is for people to read the content - not navigate around. I suggest bumping the body p's font up from 12px to 15-16px.
Here are two screenshots, one of the default rendering in Safari and one with the Reader feature turned on. Notice how much larger the reader font is than what's specified on the site.
Browser: http://imgur.com/18wIi.png
Reader: http://imgur.com/HqnKY.png
a developer is a developer! and she should be judged by her merit, and she's intentionally fooling us to read just ok content. (mainly guys in tech)
I have an interest in a female peer's perspective on our industry. I have yet to work with a female coder and feel my working environment would be improved with a better male to female ratio.
I don't see how she's intentionally fooling you. The URL is girldeveloper, she has a picture plastered on the right (like a ton of other blogs I might add). I guess I'm confused by your reaction.
By positioning herself as a "girl", I think of her as a girl first, and a developer second. What qualities do I associate with girls? Not the qualities I look for in a programming blogger. Is that prejudice? I guess so.
I clicked the link because it had a catchy title, not because it was from a site "girldeveloper". That I'm not even thinking about the content of the post anymore speaks volumes.
Women are a significant minority in software development. This in itself means that a woman's experience of the field I work in every day must be different to mine. You're more likely to learn something new from someone looking at the same things you do from a different perspective than you are from someone who shares your POV and is more likely to just tell you things you already know.
The blog still has to be interesting, but "girldeveloper" is as good a hook as any.
I did: "I think" "I associate" "I look" "I clicked" "I'm not"
Her github: http://github.com/nataliepo
Even if she did does it matter what some random person on the internet says? Really?
On the other hand if she did improve her text color a bit then it would be awesome. I loved her theme though. It's quite pretty in a girly girl sort of way.