How to write programs in reasonable time?

I joined the CC forums 2 years ago

Since then, I have published the following:

One program that I then removed because it was horrid
One program that I only partially finished
A few APIs that nobody really ever cared for

That is all, and yet I feel as if I spend forever on the computer

I have had other ideas, but then I spend months trying to write them until eventually get bored with them

How do other people write programs so quickly?
Also, with all these ideas that pop into my head, how do I focus on one project at a time? I get them quicker than I make them

Just allocate like an hour per day to writing just this one program or something. Many programs might not even take that long, if they're simple enough.

But you'll never make everything. I have dozens of projects that never made it to the forums or are on indefinate hiatus.

Start by figuring out what and why - you need to know the scope of the project you're undertaking. If you can't say to yourself "I am going to code this in order to accomplish this" then you're not going to get anywhere; you need to have a clear mental image of what your finished product will look like before you can work towards it, and you likewise need to know what purpose it'll fulfil before you'll be motivated to work towards it.

This is why most OS projects don't work out: their authors usually have absolutely no idea where their goalposts are, let alone what'll happen when they reach them.

In terms of writing the actual code, don't overthink things too much. If you just plonk down the first bit of logic that comes to mind, then yes, you'll probably find yourself going back to re-write it later on… but it's often much faster to figure out "the proper way to do it" by coding something and seeing how it works (or doesn't work) than it is to try and plot out your full program logic within the confines of your head. Writing a rough draft is better than writing nothing at all, even if only because the next step will seem so much more obvious afterwards.

Avoid distractions. Lyrical music is a big one - most of my playlist consists of video game music, which is typically instrumental. Slow ambient pieces work well, the longer the better. Think "strategy games". This sort of stuff.

If you find that you can't stop tabbing out to your browser or whatever (as I often do when I can't figure out a bit of bugged code), force yourself away by getting up and going for a walk. Sometimes you just need to disengage your mind and let it free wheel.

Here is my concept:

1. Think about what you will do, untill you have a clear image like BB said.
2. Think about the details. Details is what you program will look like at the end (Let's take an example: GIMP. GIMP isn't just a photo editor. It gives you tools which will make you able to draw and to transform things and filters give the pictures the wanted look.) Try to think out for what purposes your program will be used to. The more you know the details, the more you know what makes your program different from others, the clearer will be your idea and the better the result.
3. Okay, now you know where your program will lead to. Decide now if it is a special purpose or a more general purpose. If it is more general, think of an API (e. g. encryption) otherwise create a program. If you aren't sure if it should be an API then think of a program with a good interface for other programmers like shell does, but you can also use arguments (like git does). Arguments has revolutionised the software industry.
4. Now you have a clear plan what your program (or API) will look like, and how you will access them as a user or a third party programmer. Now happy coding.

Last thing, you should allways start at the beginning. I can't explain it, so here is a example code:

-- Program:
-- Right way:
while true do
  -- start here
end
-- wrong way
local function clalculateSomething()
  x = x + 1
end
-- API
-- Right way
os.loadAPI("api")
-- or
local api = dofile("api.lua")
-- Wrong way
function api1()
  --crazy shit
end

Hope i could help and please exucse my mistakes, if there are, i am not a native speaker.

Bomb Bloke, on 04 September 2018 - 10:06 AM said:

Start by figuring out what and why - you need to know the scope of the project you're undertaking. If you can't say to yourself "I am going to code this in order to accomplish this" then you're not going to get anywhere; you need to have a clear mental image of what your finished product will look like before you can work towards it, and you likewise need to know what purpose it'll fulfil before you'll be motivated to work towards it.

This is why most OS projects don't work out: their authors usually have absolutely no idea where their goalposts are, let alone what'll happen when they reach them.

In terms of writing the actual code, don't overthink things too much. If you just plonk down the first bit of logic that comes to mind, then yes, you'll probably find yourself going back to re-write it later on… but it's often much faster to figure out "the proper way to do it" by coding something and seeing how it works (or doesn't work) than it is to try and plot out your full program logic within the confines of your head. Writing a rough draft is better than writing nothing at all, even if only because the next step will seem so much more obvious afterwards.

Avoid distractions. Lyrical music is a big one - most of my playlist consists of video game music, which is typically instrumental. Slow ambient pieces work well, the longer the better. Think "strategy games". This sort of stuff.

Yea, I get distracted easily, and I think it out in my head first…

Bomb Bloke, on 04 September 2018 - 10:06 AM said:

Start by figuring out what and why - you need to know the scope of the project you're undertaking. If you can't say to yourself "I am going to code this in order to accomplish this" then you're not going to get anywhere; you need to have a clear mental image of what your finished product will look like before you can work towards it, and you likewise need to know what purpose it'll fulfil before you'll be motivated to work towards it.

This is a very important thing to do. This is exactly where Touchpoint came from, and it's one of the best pieces of software I've written, in a number of ways. I wrote it because I got tired of supporting DW20's button API in Ask a Pro and wanted something that was written with Lua idioms, that would be easier to support, and that would support a large proportion of the most asked-about additional features. It took just a couple of hours to write and test the initial version, and it's only been modified a couple of times after that to add new features. It's become probably my most widely-used software project, and it requires minimal maintenance on my part because it just works. I fully credit that to starting out with an extremely clear scope and allowing only very carefully considered expansions to that scope.