Helpful points of view, concepts or ways to think about problems every newbie should know

Question

What are helpful points of view, concepts or ways to think about problems that would help every newbie to solve programming problems more easily and avoid bad code and design?

An example would be to think of data as a blob that can be transformed and shaped into the needed result. Instead of poking at the blob with a ten foot pole and extracting bits and pieces out of it in a hundred steps, think about the end result you need and what the shortest way is to transform the blob at hand into that end result using the tools at hand (functions and algorithms). So, instead of running a hundred different queries on a database and piecing the results together, start by selecting everything and add filter and formatter clauses until you get as close to the needed end result as possible.

I'm interested in these kinds of high-level approaches and what concrete results they can have.

Answer 1

KISS (keep it simple, stupid).

I don't think there's any more important concept in programming. Many (if not most) of the problems programmers run into are the self-inflicted result of trying to do too much.

Answer 2

Make it right before you make it fast.

The correctness of value should be much more important thanthe speed with which the value is fetched.

Understand the probem before you design

Get a real picture of what's the user requirement and then only design your product.

Understand what software engineering is

The application of systematic, disciplined, quantifiable, approach to the development, operation and maintenance of software i.e. the application of engineering to software

Answer 3

Pipelines / Production Lines

One thing doing one job well.

By thinking like this you decompose the problems into smaller, understandable, testable pieces.

Example:

Data comes in from several sources, first step specific transformers "normalising" the data to some single "canonical" format.

Then a calculation step, which only needs to understand the canonical form, no special cases for different sources.

Then some formatters, one per output type, understands only the results of the calculation and the output to be produced.

Answer 4

To generalize the example from the question:

Keep passing one general block of data around

Newbies tend to over-specialize variables. I often see patterns where a block of data is picked apart into dozens of small variables all holding a copy of the data, which are then distributed to different parts of the application, all of which expect some specialized format or other. Often the logic that assembles/disassembles data to pass it around is larger than the parts that do the actual work.

Think of the data as the center-piece of your application, all your code does is move it along and direct it where it needs to go. Standardize all your functions to work with one data structure so you can just keep passing the same block of data around. Unset or change parts of that block only when necessary. Unless we're talking about humungous amounts of data being passed around, this is often the cleanest and most maintainable way.

Answer 5

A "program" or "application" is a collection of subsystems. Stay focused and work on one subsystem at a time. Do not jump around, instead focus on creating small testable units of work. With a lot of green developers, I see that they try to tackle the whole problem instead of logically progressing through the development of interrelated subsystems.

Answer 6

Here is one: It is all common-sense. If you want to properly use a gridview then know how it works. If you do not understand the connection between your code and it's data source then there is a potential bug lurking. Understand the fundamentals of OOP before undertaking a considerable-sized project. Any advice anyone gives you sums up to "duh!" and "use your head".

Realizing it is all common-sense is half the battle. Typing code and dealing with people are the other half. This has helped me a lot and I hope it helps you.

Answer 7

• Don't think of optimizing initialy. Focus on the business logic than performance. optimization can be done later.
• Choose the right tools/language based on task and time frame. E.g If you want to deliver quickly or you expect requirements to change often, choose high level languages. E.g java/python/C# and J2EE/.NET platform where you don't have write everything from scratch. E.g If you write in C/C++, you need to write logging library etc.. but in other language, it's all available.
• If you think requirement will not change often e.g implementing protocols (SIP Proxy) and you need higher performance than you can choose C/C++. But do consider development and maintainable cost.

Answer 8

A few ideas to share:

YAGNI - You Aren't Gonna Need It goes with KISS as being a couple of big mottos or mantras that come to mind.

"My Top 10 Lessons in Life" while not being totally programming related are really good ideas to keep in mind as you develop, both personally and professionally.

"Motivation and Technique" is also possibly useful to remember for both oneself and others.

My general problem solving set of steps:

• Define the problem. What is it that you want at the end?
• Examine what you are given that may be useful in helping build something that you can use.
• Work through using the given along with variables for what you don't know to see if something can be solved. (This is the trickiest part as it requires a lot of work and has many different parts to it at times.)
• Verify the solution and see if the initial problem statement still applies. Many times as you learn more about what there is that can change what you are wanting to have at the end.
• Present the solution in a way that justifies why what you have as the correct answer.

Then there are a few basic algorithm ideas that I find handy but not always the best:

• Design Patterns
• Divide and conquer
• Dynamic programming
• Recursion
• Being Greedy

Last but not least, understand how the following factors are important in solving a problem:

1. Time - Is the solution needed immediately,e.g. someone choking or needing First Aid, in the near term like the next week, or long term like in the next few years?
2. Cost/Money - Is whoever is paying for this wanting a multi-million dollar solution, a few thousand dollar solution or a free solution?
3. People - How many people are needed for a solution?
4. Technology - Of all the different tools and systems, which seems to be the most appropriate.

Sorry for giving such a long answer, I just felt like doing a micro-brain dump.