Your Questions: The right way to program?
Catherine Musinsky wrote in with 3 questions, only one of which I’m going to answer publicly.
Catherine, thank you so much for this question. You’ve given me a fabulous gift: the justification to rant!
She writes:
As a former painter and Rubyologist-wannabe, my tendency is to lay down the sketch first and fill it in until the piece (application) is done. I’ll lay down what I want to have happen then run script/server and hit the errors, one by one.
My brother-in-law, a JavaScript programmer, watched me do this one day and laughed in my face—”You’re a circular programmer!”
It’s true! And I’m realizing it’s not the smartest approach—or is it?
What are your thoughts on this, Amy? How does one learn the most useful methodology for building an application?
Oh, lordy.
Smack your brother-in-law for me, wouldja?
No, no, NO, no! Hear me? No!
There is no right way to program.
And, with the possible exception of bashing the keys with live kittens, there is no wrong way to program, either.
Funnily enough, what you describe, Catherine, is the same methodology behind test-driven development—if only you were writing tests instead of application code. Especially the reloading/re-running, solving the immediate problem roadblocking you each time, and doing it again.
Doesn’t sound so silly now, does it?
Burn the zealots!
The world of programming is a world full of zealots, who think they’ve found The One True Way. Sometimes they even call it that. (I’m speaking, of course, of the One True Brace Style. Arrogant bastards.)
The problem with zealots is that they find something that works for them, and immediately decide they have to go convert everyone else to it, too.
Fundamentally, this is a problem with personal or professional insecurity. If you can convert other people, then you’ve got social proof. If you can’t, and you rant loud enough, you can pretend you’re a revolutionary genius ahead of your time.
What, not how
Programming is only a means to an end (see the last headline: If there is one thing…). It’s a tool. It’s a craft. It’s a discipline. Whatever.
It’s not a science.
It’s not falsifiable.
How you do it doesn’t matter.
What matters are your results.
And what you need from your results depends on your circumstance. You must adapt, you must be pragmatic, but you don’t have to be standardized.
Program in the way that feels right to you.
Try other ways, but don’t feel bad if they don’t work for you the way they work for other people.
Experimenting can teach you all sorts of things and help you grow, but there’s no getting around the fact that programming, like everything else, is extremely faddish.
A special note for process zealots
Your process is not special. The adoption of any process can improve your work.
Just like the adoption of any self-help system has been shown to cause improvements in the people who use it.
Why?
Because it makes you pay attention, to what you’re doing, and to yourself.
Simple as that.
Yeah, but sites like The Daily WTF wouldn’t exist if there were not some really really bad programmers! http://thedailywtf.com/
Yes, the process is not that important nor is the particular language but you should at least be writing code efficiently and properly. i.e. use the tools the right way, don’t hammer that nail with the bubble level and don’t use the screwdriver as a pry bar.
If you have a nested "if then" branch that is 50 levels deep, you are doing something very wrong. If you are redefining built-in API calls with your own code and thinking you are smarter then the API library programmers with decades of experience then you are doing something wrong. This is like saying the plywood is not up to par so you’re going to make you own blend of plywood and you end of with something that has the strength of cardboard.
Yes, define your own process. Yes, experiment on improving your process by examining established processes. Yes, use the language that makes sense. Yes, use the tools that work for you. Ignore the editor, IDE, language, and any other tool wars. It’s like arguing between Snap-on, Craftsman, and Mac Tools!
Make sure you learn to program by re-using the pre-built components such as the built-in classes and API calls rather then thinking you know best and replace them with your own code! This one personality flaw is much like megalomania and it results in an enormous industry problem. Don’t become a megalomaniac zealot! Do something about your personal and professional insecurities! Repeat after me, "I am not a wizard", "I am not a genius". Seek help, before it’s too late!
Stop writing code with the intent of obfuscation in an attempt to ensure job security or to differentiate from other programmers so you look like a genius to the clueless management because no one else can figure out your code.
How about some articles on programmers and their personality disorders! Anyone know a psychiatrist who can comment? We need some standardized psychological tests that will reveal personality flaws and mental disorders to be used during the hiring process!
"The problem with zealots is that they find something that works for them, and immediately decide they have to go convert everyone else to it, too.
Fundamentally, this is a problem with personal or professional insecurity. If you can convert other people, then you’ve got social proof. If you can’t, and you rant loud enough, you can pretend you’re a revolutionary genius ahead of your time."
Thanks for speaking it loud for me. People should stop forcing their own preferences onto other people.
However, it is sometimes hard to do when a decision has been made to use a certain tool for a specific task in a team project by one person, and other people think there are better tools to use for that same task. As always, I think a balance is what we need.
Reading this post it seems like it would logically follow to say: it doesn’t matter how you program. I hope this isn’t what you mean. There is a huge difference between code that is easy to understand and work with, and code that is not. Of course the main point of programming is not the code, but what the code does. That’s obvious. But in a real system code that is malleable and enjoyable to work with means you can get more features done for your customers.
Agreed. A potentially good programmer is going to recognise that "the results" may be a broader thing than "shipped once" and that shipping better stuff more often (assuming that you agree that this constitutes "results" for some significant proportion of programmers) requires attention to and continuous incremental improvement of one’s process.
Anyone who derives DRY for themselves is probably on the right track. I did, although it took me more than a decade and I needed the Prag Prog book to crystallise it for me.
Of course, the brother-in-law, on this tiny piece of evidence, appears to be an ass who doesn’t get it at all. (I’m British – that’s a donkey-type thing, not an arse, although he may be that too.)
I absolutely agree.
Except of course for indenting, obviously all sane people use tabs and those few sad souls who misguidedly prefer spaces are infact agents of Skeletor sent from an alternate dimension to try and destroy our networks by multiplying the kilobytes used by our whitespace by 4 (except in case of gzipping I guess).
Chris wrote:
"Reading this post it seems like it would logically follow to say: it doesn’t matter how you program. I hope this isn’t what you mean."
That is exactly what I mean.
Let me repeat myself: It doesn’t matter how you program.
The only thing that matters are your results.
And what you need from your results will vary, from project to project, and as you grow as a programmer.
It’s that simple.
Hey-lo Amy, This is very delicious… If you say there is right way, that in itself is a way… the only truly transcendental way of dealing with this is saying people who say there are right ways are right, too. All things are fine, including those things which exclude all things.
In other words, some people can have right ways, and that’s fine. Even when it’s not fine, it’s alright 🙂
Ironically, results are entirely linked to how you program 🙂
There are generally more effective and less effective methods to do things, and there is the landscape between these extremes. None of this matters in the least unless you have AN AIM.
Now, all peoples’ aims can be different.
There you go 😉
Thomas,
Skeletor walks into a bar. He says, "Gimme a 1TBS and a mop."
(Thank you, thank you, I’ll be here all… uh… eternity!)
Srsly, thanks for that one, you made me truly LOL. 🙂
I recently decided it really was about time I started to write some proper tests for my code. I’d read quite a few articles about testing and decided that I’d give behaviour-driven development a go, and more specifically RSpec.
After doing some BDD for a couple of days I came to the realisation that I had always been doing BDD development anyway, it’s just that I’d never previously been writing the formal tests to go along side it, and had instead basically just been running them in my head.
Yes, that’s right, I had always used to code in the same manner as Catherine, and so I found it interesting that you also pointed out to her that what she is doing is basically the same methodology as test-driven development.
I would though – not wanting to sound like a zealot here – strongly urge her to look into using a testing framework such as RSpec, as now I have started using it I am already glad that I have those formal tests sitting around ready to run all the time (and just really wish I had had them on so many projects – especially team projects – that I had worked on in the past).
Hi Amy,
This was a really interesting post. Thanks a lot! I’ve always thought of the different methodologies of programming to just be tools that apply in different situations (use GR for fast-to-market web apps, but maybe not banking apps. Use TDD for really, really math-intensive stuff, but maybe its overkill for a todo list manager. etc etc). A good box of tools leads to a more pleasant experience for everyone…
Except indentation. 1TBS is the ONLY way. 😉
These photos are abeulotsly amazing. I love them. They definitely are a tear-jerker .in a good way. Kim & Andrew are such an attractive couple. Amy, you are extremely talented and I enjoy looking at your work. Cheers!