I’m really not a particularly good programmer. I really like programming — or scripting as it were — but my strength is in how I apply it, not my deft code juggling, nor my mathematical prowess. In fact, my brain often locks up when trying to figure out even fairly simple problems, such as how to write a dice probability calculator, and in the long run it often keeps me from actually coding simply because I know how long it takes me to suss out how to do the more ‘complex’ stuff.
But dammit, I like figuring out stuff I can’t figure out, and I found a trick which helps me keep eyes on the ball. I write down what I need to do beforehand, like so:
Create a multi-dimensional array keeping track of skill level vs. results. First array is skill level, under which each element has an array of potential results, which in turn holds the count of how many times the result is likely to be seen.For each skill level, iterate for each set of dice the possible outcomes, then increment the array element of the highest die.
Calculate the percentiles, draw a chart and watch the cash roll in.
Pretty straight-forward stuff when it’s written out in English. And yeah, multi-dimensional arrays, even two dimensional ones like this one, really break my balls. But when I have it written down, it goes down a lot smoother.
If I run into a problem I can’t quite figure out, I do the exact same thing again, and more often than not, it does the trick. Another ‘trick’, is to keep in mind in your writing, the structure of the code that comes after and keep the sentence and paragraph structures so that it essentially reads like a really high-level version of the final code.
What’s your secret?
It’s not too far away from pseudocode, which most programmers use.
I start by breaking down the whole into functions and then those functions into steps with a one-line description. Something like ‘read from file’ or ‘convert to percentage.’
“My strength is in how I apply it, not my deft code juggling, nor my mathematical prowess.”
Same here Michael.
My “way” usually involves a lot of Googling and a trawl of the CPAN archives. My methodology is simple, find code that does what I want to do, or something close to what I want to do. Then study it, rip it apart, reassemble it. Learn its process.
Then, once I’ve mastered it, I can roll my own. Hopefully improving on what came before.
If I can’t find existing code to work from then I’ll use your method. I’ll flowchart what I what to do, then pseudo-code it. It’s usually a lot easier then to write real code, because the process is properly understood.
Writing this, I realise that the key to success is simply understanding. Understanding – in as detailed a set of steps as possible – what I want my code to do, makes it easier to write the code to do it.
Which is basically what you and Lee have already written! :-)
My secret is the opposite of yours :D
I typically, but not always, prefer not to write anything down. Instead I think about the problem until I have a pretty clear idea in my mind on how to go about it. The big benefit of doing this is that firstly I make sure that I understand what I’m trying do to, and not just my own drawings/bullet-points. Secondly any strategy – no matter how good it is – only lasts till the first shot is fired. This means that as you implement you have to adapt and be flexible. A model in your brain is much more workable/adaptable than something on paper. Also, the more in love you are with your own flowcharts and “plain english” the less likely you are to stray from it, even when it’s needed.
My coding style once I get started is prototyping and refactoring until I get to where I’m headed.
Also, I exclusively use Visual Basic which itself is quite close to “plain English” which helps a lot.
My “secret” is to obsess about the problem until the answer has to be delivered, then talk it over with a colleague. Half the time I find that we’ve already solved it in another part of the app, and the central part of the design I end up writing is a description of what to copy exactly, and what to vary compared to the other place(s) we’ve done similar things before.
(Also: “suss out”, not “shush out”)
I do pretty much the same thing, except I keep it all in my head. Works pretty well normally, but sometimes when I’m tired or sick my head doesn’t work right, and then I just have to start at point A and see if I can write some code that gets me to point B.
i hear you Mikey, i hate that feeling when you wake up in the morning and you’re like “damn, i just can’t figure out that dice probability calculator app”. really pisses on my cornflakes. metaphorically speaking. :P
my secret: copy + paste