There's probably more than one way. But let's start off with the three programming virtues - laziness, impatience and hubris.
Of these, the most important (in my opinion) is hubris. Until I've convinced myself that I'll be able to do it, I can't start. My worst example of this was the several months that it took me to convince myself that I could write a program to run on a PC, to emulate a PC. One day I'll explain why I needed that. Once I'd gingered myself up to do it, it only took me a week to write and about a day to debug.
So once you've braced yourself to the task, where to you start? For me, stage one is to design the data structure. Usually, I use a simple flat file, although I do have one scheme where I wrote a database that could handle 109951162777 records. The difficulty was that this is two to the power forty, so I couldn't use 32 bit integers.
I had to write software to handle 40 bit integers. To do the lookups, I indexed the data, then I indexed the indices, then I used the Berkeley DB to access the indexes of indexes. It all worked (and has done for the last 15 years) - anyway, the point is, the starting point was the data structure.
Then choose your programming language. The best language is the one that will make your program easiest to write (laziness), which often means looking for a library that does much of the job for you. I use Perl a lot, and Perl has a shedload of libraries - whatever it is you want to do, there's usually a library for it. And sometimes I use Perl to call a command line program. So, for example, I have a thing that monitors the number of alarms that my alerting system generates. When that's more than 100, I want it to start speaking to me, in case I hadn't noticed. To do that, I use espeak, a command line program that voices the message. It's a *lot* easier to use espeak, than it would be to write software to voice messages.
The next stage is twofold. There's the overall program, with difficult bits left for later (that's laziness). And then there's the difficult bits, which are often written separately and tested (impatience) before stuffing them into the main program.
The thing there is to think about the tricky cases, the ones that are most likely to fail. And there's more of them that you first think. And more will turn up later.
But there's probably more than one way to program.