Solving problems in programming

Personal notes on problem solving thought process, gathered from different sources of information. Technologies and tools that have been there for a decade or more and being heavily used worldwide have a proven track record of "best practices". Here are some excerpts that are interesting and may be useful.

Food for thoughts.

Perl community

Think before posting !

Please always think before you write; when you write you are taking the time of over a thousand people.

If what you write takes just 30 seconds to read, that's more than 8 hours(!) of time burned that could have been used writing code. :)

Before you write a question please make sure you've checked all the FAQs and the documentation you know of.

Before you write an answer, make sure you that you really are contributing to a solution and doublecheck that no one else already gave the same answer.

understand some problems just aren't solved yet, or haven't been incorporated into Strawberry because current solutions just aren't robust or sustainable enough yet, which is our first priority.

Difference between general purpose programming language and domain specific programming language.

there will always be small, focused, special-purpose languages dedicated to a specific problem domain that are simply more convenient for certain kinds of problems. Perl tries to be all things to all people, but nothing special to anyone. Examples of specialized languages that come to mind include prolog and matlab.

One good reason is when you already have an existing application written in another language that's all done (and done well), or you have an application language specifically designed for a certain task (e.g. prolog, make).

Automate stuff away. Make computer programs do the work for you. ABC: Always Be Coding. Focus on creating value. Be patient! It takes years to succeed.

Get things done quickly, efficiently and move on. Don't do things that don't create value. Start a programming blog much earlier. Release early and often.

I don't enjoy frameworks as it's often much quicker to write a basic version of the same thing than to learn how to use the framework. I love to get things done with the existing tools. The new tools are often confusing, change too fast and/or are too experimental. I only adopt the new tools once they've become old and have survived.

Simplicity is the law. Software should be developed using least amount of complexity, dependencies, effort and using fundamental tools that have been and will be here for the next 20 years. Try to find the simplest solution starting from the core language and core tools and going up. Instead of learning fundamental tools, core computer science concepts, and programming techniques, you spend time learning something specific and generally useless.

You should be thinking:

How do I avoid using this framework ? How many actual features or core concepts do I need from this framework ? Can I implement these features in a hundred lines of code and be done with it and never depend on this framework ?

Frameworks make you dumb:

Whenever you're faced with a problem, you can't just invent a solution: you're limited by what the framework lets you do. You can't let framework authors control what you can or can't do. You should be in control over your product. You should be fighting complexity and not embracing it.

Frameworks go out of business and get abandoned:

You just spent all the time earlier learning the old framework and now it's out of business. All the skills you accumulated are now useless.

Core fundamental tools already let you do everything that these frameworks do and you'll just waste time learning that doesn't solve anything new. Use fundamental core concepts, solid tools and programming techniques that are here for the next 20 years, rather than frameworks and useless libraries. You don't need them.

### Powershell community

### MacOS community

Gimp community

You can do all kinds of things with Script-Fu, but an ordinary GIMP user will probably use it for automating things that:

You want to do frequently.

Are really complicated to do, and hard to remember.


I write open source software to solve my problem. I let you use my solutions because that comes at zero cost for me (well, almost, I still have to pay for the website, you are downloading from. You are welcome, by the way). I also provide the source code, so you can fix things yourself, should my solution turn out to be unsuitable. However, once you come to me with a “bugreport” that doesn’t also include a patch (or at least very precisely pinpoints the problem), then you are basically asking me to look at your problem. At this point, it is no longer zero cost for me and that’s the reason for why I am charging you money: you are asking me to spent time on your behalf. That is commonly called work. And surprisingly enough, work is what people expect to be paid for.

Don’t get me wrong. I’m happy to help. Selling support is what keeps the lights on here (did I mention the cost of running a webserver?). But coming to me under false pretense and/or expecting that I must provide free service on top of a software I gave away without charge is not going to win you any favours.

It stops being free, when it starts costing me! My time is valuable. If you want a piece of it, I want money in return. Period.

Back to top