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.


Back to top