10 things you could be doing to your code right now(smartic.us)
smartic.us
10 things you could be doing to your code right now
http://smartic.us/2008/9/9/10-things-you-could-be-doing-to-your-code-right-now
17 comments
For the 80% case, cap works fine. It's when you need to do stuff in that last 20% that you have real trouble.
I was in the 80% case when I wrote vlad. cap does NOT work fine. It is a steaming pile of intertwined crap... imhfo.
We got the 80% usage case of vlad covered in about a 3rd() of the code that cap required.
) actually π. In the release notes for vlad 1.1: "The flog ratio between capistrano+deps / vlad+deps is pi (or, damn close)!". Line numbers correlated fairly close iirc.
We got the 80% usage case of vlad covered in about a 3rd() of the code that cap required.
) actually π. In the release notes for vlad 1.1: "The flog ratio between capistrano+deps / vlad+deps is pi (or, damn close)!". Line numbers correlated fairly close iirc.
A list with 7 different ways to do unit testing that doesn't include "N. Adding features to it" is probably not a good list for a startup.
Heh, unless you believe these guys:
http://gettingreal.37signals.com/ch02_Build_Less.php
:P
http://gettingreal.37signals.com/ch02_Build_Less.php
:P
Every once in a while, a seemingly useful piece is posted here at hn that I read and, based on what has worked well for me, I simply don't agree with. This is one of those. Here goes:
1. Upgrade Test::Unit - What, you aren’t testing? You should be testing all the fucking time (TATFT).
Except when you're coding. And then you shouldn't be doing anything but coding. Sometimes you just gotta crank in order to make any real progress. It's a lot easier to test once you have something to test.
2. Try out some TDD - Test Drive Development (TDD) makes for better code.
No. Define your target. Code to it. Deploy. Then test. Lots of quick cycles blow away few slower ones. Just code with your pedal to the floor. Test time is the time for testing.
3. Upgrade your fixtures - I’m not sure I can advocate this approach due to the fact fixtures actually do provide some use.
Just because something provides some use doesn't mean you should use it. Get a good IDE or text editor, a good work area, and a little gray matter; that's all you need. Otherwise, you risk getting caught up in all your cool tools, an easy mistake to make.
4. Install (and learn and use) a SCM - The benefits of having code in some form of repository hugely outweighs it not being there.
Uh, I'd love to argue with this one, but I won't. Good advice. Either get some kind of repository or learn to walk on eggshells. Your choice.
5. Investigate Continuous Integration - ...makes automating your tests to run at checkin next to trivial.
Making checkin trivial is not a goal while coding. Getting something done IS. Anything that is not coding is not helping you make progress while coding.
6. Know your code - It is one thing to write your code, but it is another greater thing to know your code. Four automated tools...
"Know your code" & "automated tools" are mutually exclusive. See my response to #7 below.
7. Automate your deployments - Automation is your best friend.
Wrong. This is EXACTLY to opposite of #6, "Know Your Code". Automation takes you out of the very trenches you have to be in to get to know your code in the first place. The dirtier I get, the better I know my code. (For further reading, Chapter 3 of Founders at Work by Jessica Livingston. Woz (my hero) totally immersed himself in his details without crutches in order to know them as well as anyone ever has.)
8. Collect some statistics
Code now, get something working, and worry about analyzing it later. Again, anything that isn't "coding" is slowing you down.
9. Read other people’s code - You want to be a better developer? Read code. Read bad code. Read good code. Read your code. Read my code. Code reading is a skill that many developers skimp on.
I have NEVER liked this advice. Why? I've never found it the least bit helpful. Either I didn't understand the code or it sucked so much, I was too ill to work the rest of the day. Better: find something cool (on the outside) and figure out how to code it yourself. Ask for help or suggestions if you need it.
10. Blog about it
If you have time to blog, then your project isn't big enough. Code now, deploy, and blog later. Frankly, I don't want to read about your "adventures in development" until you're done and have something to say about your (completed) work.
1. Upgrade Test::Unit - What, you aren’t testing? You should be testing all the fucking time (TATFT).
Except when you're coding. And then you shouldn't be doing anything but coding. Sometimes you just gotta crank in order to make any real progress. It's a lot easier to test once you have something to test.
2. Try out some TDD - Test Drive Development (TDD) makes for better code.
No. Define your target. Code to it. Deploy. Then test. Lots of quick cycles blow away few slower ones. Just code with your pedal to the floor. Test time is the time for testing.
3. Upgrade your fixtures - I’m not sure I can advocate this approach due to the fact fixtures actually do provide some use.
Just because something provides some use doesn't mean you should use it. Get a good IDE or text editor, a good work area, and a little gray matter; that's all you need. Otherwise, you risk getting caught up in all your cool tools, an easy mistake to make.
4. Install (and learn and use) a SCM - The benefits of having code in some form of repository hugely outweighs it not being there.
Uh, I'd love to argue with this one, but I won't. Good advice. Either get some kind of repository or learn to walk on eggshells. Your choice.
5. Investigate Continuous Integration - ...makes automating your tests to run at checkin next to trivial.
Making checkin trivial is not a goal while coding. Getting something done IS. Anything that is not coding is not helping you make progress while coding.
6. Know your code - It is one thing to write your code, but it is another greater thing to know your code. Four automated tools...
"Know your code" & "automated tools" are mutually exclusive. See my response to #7 below.
7. Automate your deployments - Automation is your best friend.
Wrong. This is EXACTLY to opposite of #6, "Know Your Code". Automation takes you out of the very trenches you have to be in to get to know your code in the first place. The dirtier I get, the better I know my code. (For further reading, Chapter 3 of Founders at Work by Jessica Livingston. Woz (my hero) totally immersed himself in his details without crutches in order to know them as well as anyone ever has.)
8. Collect some statistics
Code now, get something working, and worry about analyzing it later. Again, anything that isn't "coding" is slowing you down.
9. Read other people’s code - You want to be a better developer? Read code. Read bad code. Read good code. Read your code. Read my code. Code reading is a skill that many developers skimp on.
I have NEVER liked this advice. Why? I've never found it the least bit helpful. Either I didn't understand the code or it sucked so much, I was too ill to work the rest of the day. Better: find something cool (on the outside) and figure out how to code it yourself. Ask for help or suggestions if you need it.
10. Blog about it
If you have time to blog, then your project isn't big enough. Code now, deploy, and blog later. Frankly, I don't want to read about your "adventures in development" until you're done and have something to say about your (completed) work.
Edw519, I agree with you about a lot of things but for this post I disagree with you in several places.
>2. Try out some TDD - Test Drive Development (TDD) makes for better code.
No. Define your target. Code to it. Deploy. Then test.
You're both right. One of the points of tools like RSpec is to make the "define your target" step and the "test" step so close as to be indistinguishable, thus killing two birds with one and a quarter stones.
>5. Investigate Continuous Integration - ...makes automating your tests to run at checkin next to trivial.
Making checkin trivial is not a goal while coding. Getting something done IS. Anything that is not coding is not helping you make progress while coding.
It seems like you're just disagreeing to disagree on this one. All the guy is saying is to consider having your tests run on a remote server every time you check in so that you don't break the build. This is hardly radical advice.
>6. Know your code - It is one thing to write your code, but it is another greater thing to know your code. Four automated tools...
"Know your code" & "automated tools" are mutually exclusive. See my response to #7 below.
>7. Automate your deployments - Automation is your best friend.
Wrong. This is EXACTLY to opposite of #6, "Know Your Code". Automation takes you out of the very trenches you have to be in to get to know your code in the first place. The dirtier I get, the better I know my code.
How does automating deployment drudgery like checking out code and SSHing into the production box stop you from knowing your code? As a matter of fact, formalizing this process in a central location probably means you'll know your process better than the development lead who has an intern run deployment off a 12 step list scrawled on a Post-It note stuck to a monitor somewhere.
More importantly, if you're using deployment as a learning exercise, you're doing it wrong.
>2. Try out some TDD - Test Drive Development (TDD) makes for better code.
No. Define your target. Code to it. Deploy. Then test.
You're both right. One of the points of tools like RSpec is to make the "define your target" step and the "test" step so close as to be indistinguishable, thus killing two birds with one and a quarter stones.
>5. Investigate Continuous Integration - ...makes automating your tests to run at checkin next to trivial.
Making checkin trivial is not a goal while coding. Getting something done IS. Anything that is not coding is not helping you make progress while coding.
It seems like you're just disagreeing to disagree on this one. All the guy is saying is to consider having your tests run on a remote server every time you check in so that you don't break the build. This is hardly radical advice.
>6. Know your code - It is one thing to write your code, but it is another greater thing to know your code. Four automated tools...
"Know your code" & "automated tools" are mutually exclusive. See my response to #7 below.
>7. Automate your deployments - Automation is your best friend.
Wrong. This is EXACTLY to opposite of #6, "Know Your Code". Automation takes you out of the very trenches you have to be in to get to know your code in the first place. The dirtier I get, the better I know my code.
How does automating deployment drudgery like checking out code and SSHing into the production box stop you from knowing your code? As a matter of fact, formalizing this process in a central location probably means you'll know your process better than the development lead who has an intern run deployment off a 12 step list scrawled on a Post-It note stuck to a monitor somewhere.
More importantly, if you're using deployment as a learning exercise, you're doing it wrong.
9. Read other people’s code - You want to be a better developer? Read code. Read bad code. Read good code. Read your code. Read my code. Code reading is a skill that many developers skimp on.
I have NEVER liked this advice. Why? I've never found it the least bit helpful. Either I didn't understand the code or it sucked so much, I was too ill to work the rest of the day. Better: find something cool (on the outside) and figure out how to code it yourself. Ask for help or suggestions if you need it.
Your advice is bad. Programming is like writing -- you get ideas from reading. Did you learn to write by "figuring things out", or did you learn to write from imitating what you've read?
Personally, I think the #1 problem with programmers is that they are afraid to read other people's code. They treat libraries like they are magic. They aren't, they're just like the code that your app is written in. Finally, if everyone else's code looks really different from yours, you are probably doing it wrong.
If you have time to blog, then your project isn't big enough. Code now, deploy, and blog later. Frankly, I don't want to read about your "adventures in development" until you're done and have something to say about your (completed) work.
But you have plenty of time to get 12000 karma here?
I have NEVER liked this advice. Why? I've never found it the least bit helpful. Either I didn't understand the code or it sucked so much, I was too ill to work the rest of the day. Better: find something cool (on the outside) and figure out how to code it yourself. Ask for help or suggestions if you need it.
Your advice is bad. Programming is like writing -- you get ideas from reading. Did you learn to write by "figuring things out", or did you learn to write from imitating what you've read?
Personally, I think the #1 problem with programmers is that they are afraid to read other people's code. They treat libraries like they are magic. They aren't, they're just like the code that your app is written in. Finally, if everyone else's code looks really different from yours, you are probably doing it wrong.
If you have time to blog, then your project isn't big enough. Code now, deploy, and blog later. Frankly, I don't want to read about your "adventures in development" until you're done and have something to say about your (completed) work.
But you have plenty of time to get 12000 karma here?
Did you learn to write by "figuring things out", or did you learn to write from imitating what you've read?
By figuring things out. Like I said, this is my experience. I understand that others' experiences vary, but I have never gotten any benefit from reading anyone else's code.
But you have plenty of time to get 12000 karma here?
Not even in the same ballpark as blogging. I've been here almost 2 years, dropping in daily with a few submissions and responses. Doesn't take long for karma to add up. If I was blogging, OTOH, I'd have to make a major commitment to make regular high quality submissions. I don't care for irregular or stream of consciousness blogs. I'd rather just code.
By figuring things out. Like I said, this is my experience. I understand that others' experiences vary, but I have never gotten any benefit from reading anyone else's code.
But you have plenty of time to get 12000 karma here?
Not even in the same ballpark as blogging. I've been here almost 2 years, dropping in daily with a few submissions and responses. Doesn't take long for karma to add up. If I was blogging, OTOH, I'd have to make a major commitment to make regular high quality submissions. I don't care for irregular or stream of consciousness blogs. I'd rather just code.
It's a lot easier to test once you have something to test.
Test time is the time for testing
No offense but these comments show us that you aren't aware of what TDD really is. I'm not coming down on you but I think that, if you are going to offer advice and critique on the guy's post, you should at least have knowledge of the topics.
No offense but these comments show us that you aren't aware of what TDD really is. I'm not coming down on you but I think that, if you are going to offer advice and critique on the guy's post, you should at least have knowledge of the topics.
Or (I can't speak for him, but this is what I took away from it) is that he doesn't believe in test driven development. For what it's worth, I think elements of it are nice, but it's often taken too far.
Same here. I agree fully with using version control, and that reading other code is educational (although being bit hard by having to maintain unforgivably sloppy code you wrote a long time ago will teach you some of the same things, i.e., being neat will make things much easier to fix later), but advice that essentially says, "1. Test, 2. Test, 3. Test, 4. Test, ..." isn't advice, it's a sign that there's something suspicious going on.
I think it's telling that the most noise is made about TDD in the Ruby (and to a lesser extent, Python* ) world, but that it hasn't gotten as strong a foothold in many other languages. TDD seems to me to be a way to take advantage of dynamically-typed languages' strengths while compensating for against their weaknesses, but then it only makes sense with certain kinds of languages / styles of programming, and its advocates seldom seem to address this. (Regression tests are more generally useful, for example.)
Also, contrasting TDD against testing styles from other language-cultures may be enlightening. For example, look at QuickCheck in Haskell: Many tests that could fall under TDD are already covered by the type system in Haskell and ML, so instead it focuses on automatically finding edge cases for you and verifying that invariants hold.
* Also, many testing practices, e.g. TDD, automated unit testing, etc., originated with Smalltalk, another dynamically-typed language.
I think it's telling that the most noise is made about TDD in the Ruby (and to a lesser extent, Python* ) world, but that it hasn't gotten as strong a foothold in many other languages. TDD seems to me to be a way to take advantage of dynamically-typed languages' strengths while compensating for against their weaknesses, but then it only makes sense with certain kinds of languages / styles of programming, and its advocates seldom seem to address this. (Regression tests are more generally useful, for example.)
Also, contrasting TDD against testing styles from other language-cultures may be enlightening. For example, look at QuickCheck in Haskell: Many tests that could fall under TDD are already covered by the type system in Haskell and ML, so instead it focuses on automatically finding edge cases for you and verifying that invariants hold.
* Also, many testing practices, e.g. TDD, automated unit testing, etc., originated with Smalltalk, another dynamically-typed language.
...it's a sign that there's something suspicious going on...
Thank you, silentbicycle. That's what I was trying to say, but you said it much more eloquently than me.
I have always looked at "tools" with a wary eye. Are they really a solution to an existing problem or are they aspirin (or a crutch) for a pain without addressing the underlying cause. I realize many people believe the former. I usually believe the latter. They don't call me a caveman coder for nothing.
Thank you, silentbicycle. That's what I was trying to say, but you said it much more eloquently than me.
I have always looked at "tools" with a wary eye. Are they really a solution to an existing problem or are they aspirin (or a crutch) for a pain without addressing the underlying cause. I realize many people believe the former. I usually believe the latter. They don't call me a caveman coder for nothing.
Ruby people praising TDD is like hearing Java people blown away by Design Patterns or C people talk about techniques for avoiding buffer overflow errors: Sure, it's a good thing that they're trying to improve the quality of their software, but to some extent their methodologies are compensating for tradeoffs (and sometimes just flaws) in those languages. The trick is telling when they're genuinely useful techniques from when they're solving problems that could have been avoided entirely.
I don't think that all tools are bad, though; far from it. Just, sometimes it's better to address the root causes of problems, rather than symptoms. (Almost always better, in the long term, but deadlines happen.)
I'm working on a tool right now (not ready to share yet, it's a rare spare time project), working title "dehydrator" (like the DRY principle and hydras, dragons that keep growing more heads) which can scan code (or arbitrary sequences of tokens, really; it's an OCaml functor) and report on heavily duplicated patterns it finds. The motive is to help reintegrate code that has been copied-and-pasted to several places with only small changes. Obviously, the solution is Don't do that!, but the world is full of projects that already have years of cruft.
I don't think that all tools are bad, though; far from it. Just, sometimes it's better to address the root causes of problems, rather than symptoms. (Almost always better, in the long term, but deadlines happen.)
I'm working on a tool right now (not ready to share yet, it's a rare spare time project), working title "dehydrator" (like the DRY principle and hydras, dragons that keep growing more heads) which can scan code (or arbitrary sequences of tokens, really; it's an OCaml functor) and report on heavily duplicated patterns it finds. The motive is to help reintegrate code that has been copied-and-pasted to several places with only small changes. Obviously, the solution is Don't do that!, but the world is full of projects that already have years of cruft.
>> 9. Read other people’s code
> I have NEVER liked this advice.
The only way I'm able to read code is when I'm actively working towards some goal. Usually this is extending or fixing the existing code in some way. Sometimes it's to extract a specific algorithm or technique for some project of my own. That can certainly be enlightening, whereas just plain reading the code sends me to sleep.
Basically, that turns the advice into:
- either participate in an open source project (bugfixing, implementing features)
- or integrate/convert some complex piece of open source code into/for a project of your own
I definitely think there's something to be gained (learned) from read/write hacking rather than (mostly) write-only. Obviously, if you're trying to get stuff done, all that goes out the window, just get the damn thing written, by whatever means it takes.
> I have NEVER liked this advice.
The only way I'm able to read code is when I'm actively working towards some goal. Usually this is extending or fixing the existing code in some way. Sometimes it's to extract a specific algorithm or technique for some project of my own. That can certainly be enlightening, whereas just plain reading the code sends me to sleep.
Basically, that turns the advice into:
- either participate in an open source project (bugfixing, implementing features)
- or integrate/convert some complex piece of open source code into/for a project of your own
I definitely think there's something to be gained (learned) from read/write hacking rather than (mostly) write-only. Obviously, if you're trying to get stuff done, all that goes out the window, just get the damn thing written, by whatever means it takes.
Definitely. Reading other people's code is great advice in the long term (like, Norvig's "Teach Yourself Programming in Ten Years" long term), but you generally need to put some real time into it before it becomes rewarding, so it generally isn't very helpful when a deadline or sudden bug is the problem.
Leave the code for a while, go back home have a rest, dinner, few beers.
Come back tomorrow and sort it...
Come back tomorrow and sort it...
those flog scores interpretation are ONLY valid if you use them on a per-method basis... on a per-file or per-project level they're completely invalid.
For example:
There is little I can do at this time to clean up the monstrous yylex, but tokadd_string, read_escape, and heredoc are all too big and need some attention to clean them up. Everything else is, relative to those scores, reasonable and can be ignored at this time.
I am still chuckling that he recommends capistrano right after pushing tools to fight complexity...