Jul
30
Memo #13 – I’m doing it wrong?
Filed Under Startups
Chris Cummer, a guy with a blog that got linked in News.YC, thinks that he can tell when “You’re doing it wrong.“ Okay, I’ll bite. If only because I worry that some of the smart-but-inexperienced YC folks might actually believe what he writes.
Not everything he says is wrong, but enough of it is. So without further ado:
He says that You’re doing it wrong if…
- You’re not building atop an open-source framework
-
- Whatever, it’s okay not to use a framework. And if you don’t count Smarty as a framework, then you really don’t ever need a framework.
- You’re writing your own framework upon which to build
-
- Agreed, that’s probably stupid.
- You’re not using an ORM layer
-
- Wrong. You do not need to use an ORM layer. If anything, your life will be more painful later as you figure out that many of your bottlenecks are abstracted out of sight and are hard to uncover.
- You’re writing your own ORM layer
-
- Agreed, but only because you don’t need an ORM layer.
- You believe you can write it faster or better or more efficiently than any available library
- You have more than one developer on your project and no written coding style guidelines
-
- A style guideline won’t make up for crappy programmers.
- Your bug tracker serves as your functional scope or your development roadmap
-
- A tool is just a tool. It’s how you use it that matters.
- You aren’t using source control
-
- This is to vague to be useful. There are also crummy forms of source control, sadly.
- You comment the what but not the why
-
- If you have to comment the why, you are definitely doing it wrong.
- You tend to pass properties instead of instances to functions
-
- Maybe in your language.
- Your “deployment procedure” involves any combination of FTP and/or drag n’ drop
-
- Protocols are irrelevant, process is what matters.
- You write code in a manner that cannot be unit tested
-
- If you rely on unit-testing, you are setting yourself up for a rude awakening.
- Your primary method of code reuse is copy/paste
-
- If you spend half your time ensuring you DRY, you are wasting your time.
- You don’t read any development blogs focused on your primary and secondary languages or technologies
-
- You are probably spending too much time reading blogs.
- You are probably spending too much time reading blogs.
- You haven’t been to a conference or birds-of-a-feather meeting in the past year
-
- Once you become the expert, the value of most conferences approaches zero, unless you use it as a recruiting tool.
- The only code you read at work is your own
-
- Agreed.
- You worry that some day someone else will read your code and know it was written by you
-
- This is not a problem. Everyone has a coding style, it’s like a fingerprint. Don’t try to avoid it.
I’m curious to see what you have to say. Agree with Chris? With me? Or maybe you disagree with both of us…
Comments
12 Responses to “Memo #13 – I’m doing it wrong?”
Leave a Reply
No disrespect intended but you misunderstood a good number of the points I made, for whatever reason. I’m just going to point out one that you’re the only person to pick up on:
>”You write code in a manner that cannot be unit tested”
>
>If you rely on unit-testing, you are setting yourself up for a rude awakening.
I chose the wording of that point quite specifically to not say “You must unit test”. The “cannot” in there is quite deliberate.
I don’t care if you unit test or not but if your code is written so poorly (copy/paste, spaghetti, procedural all the way down, muddying of business logic & presentation, pick your poison) that it could not have tests written again it, that code will come back to bite you.
The rest of your counter-points just made me laugh.
I just re-read my comment and the “made me laugh” part comes across as really mean when I didn’t intend it to be that way. Apologies for that, I probably should have written “chuckle” instead.
I don’t fully agree with either of you.
However, you didn’t really add anything other then “NUH UH!” to his article. I figure you’re just fishing for News.YC credit, huh?
If you cared about impressionable News.YC readers, you would have went to the trouble of explaining what you think is right. Right?
Regarding frameworks: all general purpose frameworks will eventually slap you in the face. My homegrown framework for writing web apps is just a couple of files, might be 100 lines of code and is designed to stay out of my way.
Regarding programmers who want to use an ORM: GTFO.
When your designing something that will never see more than a dozen users or a sucessful exit, all his points are totally valid. It was geared for the news.yc audience.
@MilesZS — I’m still getting used to blogging. I went from just writing rants to at least putting thought into it. Based on that trajectory, I should start actually contributing something useful relatively soon!
Chris — I’m glad I was able to give you a laugh.
As usual, the truth is somewhere in the middle.
“If you have to comment the why, you are definitely doing it wrong.”
If you were concerned about the inexperienced, this did nothing to help. Too many developers perpetuate the myth of terse comments and “self-documenting code”. Most performance enhancements, bit-twiddling hacks, and other not so straight forward implementations need, even require, comments about the why. That’s just off the top of my head. Many more scenarios should have why comments as well.
It’s fine for pet projects, but disastrous for team development. Also, Mike D was absolutely right about the target. Even though I didn’t actually agree with everything in Chris’ article, you could do far worse than follow his advice.
@bullseye — Just read this: http://www.codinghorror.com/blog/archives/001150.html
Also, MikeD was being sarcastic and making a dig at News.YC saying that most of the stuff kids develop who read that site will never gain traction.
@davidu — I like Atwood’s blog too, but you have to take everything he says with a grain of salt.
I’m certainly not against method names that describe work being performed. However, in that post, his solution is apparently to break every complex segment of code into its own method, even if it is not reused elsewhere. Rather than add a line or two of comments, he changes the flow of the application. Not the most impressive strategy.
Honestly, I don’t really care how people write code, provided I never have to read it. Productivity-wise, I’d much rather view a 12-line method with a comment every three lines than a method with 4 private method calls. Maybe I’ve just had the (mis)fortune of working with various teams of developers, but I largely prefer the ones that understand how to properly tell a story via code.
At any rate, this is one of those topics that gets beat to death every so often. For every Jeff Atwood, there is a Donald Knuth.
@bullseye — Agreed, 100%.