- When a test is especially short or simple compared to the application code it tests, lean toward writing the test first.
- When the desired behavior isn’t yet crystal clear, lean toward writing the application code first, then write a test to codify the result.
- Because security is a top priority, err on the side of writing tests of the security model first.
- Whenever a bug is found, write a test to reproduce it and protect against regressions, then write the application code to fix it.
- Lean against writing tests for code (such as detailed HTML structure) likely to change in the future.
- Write tests before refactoring code, focusing on testing error-prone code that’s especially likely to break.
— Michael Hartl, Ruby on Rails Tutorial
“You don’t know what’s going to be the big hit. Just ship it. You can’t be second guessing yourself all the time. Consistency trumps perfection, so make sure you’re always just publishing. You just have to leave it up to fate to decide what will happen with that post.”
Inspiration to keep me working!
So, I think that’s a really good question. And I think it depends on where you are in your career. I think when you are just starting out you have to dig deep, because it takes a while. You haven’t really done, I’m not talking about you particularly, but people in general who are just starting out, you’re learning a whole lot of things at the same time. And as a beginner, you’re going to have to learn those by experience. You’re going to sit there and try it and do different things, and put in the hours. So, maybe learning Ruby and Rails to the point where you are comfortable I think is the trick. So, the point where you can sit down and write an app and most of it just flows. And yeah, you got to stop and look up an API every now and then, but pretty much you know where you’re going and what you’re doing.
At that point of comfort, I think you then do two things: you carry on doing what you’re doing, but at the same time you fork off a little process I yourself to go and look at doing something else. And what you’ll find is that the second time you’re doing that deep dive, then it’ll be easier, because you’ve learned the techniques of learning, a little bit. And then the third time would be easier still. So, I think that as a beginner, you go deep. And you get to the point where you’re comfortable. And then you got to move back to something else where you’re not comfortable, do it again. And if you keep doing that, after a while it gets a lot quicker to pick these new things up because you’ve shown yourself how to do it.
I really like this articulation of how to balance depth with breadth and new things as a new/beginner programmer.