4 ms·

Who said that algorithms are everything? No, of course they are not. In C-languages you have about 50% memory management, then you have code architecture. But a

by morphir 17y ago

Who said that algorithms are everything? No, of course they are not. In C-languages you have about 50% memory management, then you have code architecture. But algorithms are the very heart of programming, and the most important topic. Look, if you have the algorithm to carry out a task, then its just a question whether you have the tools to accomplish it, and if you know your tools to do it. The latter could be the equivalent of knowing your programming language.

djcapelis 17y ago
A knowledge of algorithms doesn't teach you to pick the right problems to solve. Once you get it down into problems like "sort this list" the code practically writes itself and the correct algorithms are simple to determine. Figuring out how to take a complex problem and break it down into problems that you then can throw your algorithm knowledge at is a whole art that takes years of study. A firm grasp of algorithms is essential but not sufficient and it can only help inform your decisions, not provide firm answers. Picking the right problems is the heart of programming. Figuring out which algorithm to throw at a sub-problem is the heart of contract work.
- morphir 17y ago
  "A knowledge of algorithms doesn't teach you to pick the right problems to solve." That is true. To create a application, one needs a Use Case. A Use Case will provide the most abstract solution to what the app will be doing. Then you can take the top down design approach, by dividing the Use Case into a several abstract sub problems. That is known as code architecture and belongs to System Engineering. The System Engineer needs a domain-expert help to identify what problems that needs to be solved. Then.. Programming is carrying out those abstract sub-problems (interfaces) to become a concrete solution using a specific programming language. To complete such a task, one needs a person that knows his/hers algorithms design techniques, sorting, searching, string processing, graph problems, combinatorial problems, geometric problems and numerical problems. And lastly, the analysis of the respective algorithms. Once you know what to solve, its just a matter of being able to carry out the task. I think you might have confused the programmers job with the job of actually creating the entire software - which in general terms is non-sense. To sum up: The software engineer (the project lead) takes care of identifying the sub-problems, after creating the Use Case with the domain expert (often the customer). The programmer solves those sub-problems bottoms up, by focusing on creating the atomic parts as efficient as possible.
  - plinkplonk 17y ago
    "The software engineer (the project lead) takes care of identifying the sub-problems, after creating the Use Case with the domain expert (often the customer). The programmer solves those sub-problems bottoms up, by focusing on creating the atomic parts as efficient as possible." This is how yucky enterprise monstrosities get built. The "software engineer"/programmer division is nonsensical and sounds like something one would find in Wipro or Accenture, not so much at (say) Google or Facebook. "I think you might have confused the programmers job with the job of actually creating the entire software - which in general terms is nonsense." :-D . The term you are looking for (since you seem to be fond of labels to sratify coders), for people who just implement whatever their "lead" tells them to is "code monkey".
    - morphir 17y ago
      Then please tell me how software gets built. Provide me with a methodology, instead of being a arrogant fool like you are now. Yes, a code monkey is a term I'm familiar with. But you need good communication skills too.

by morphir 17y ago

djcapelis 17y ago

A knowledge of algorithms doesn't teach you to pick the right problems to solve. Once you get it down into problems like "sort this list" the code practically writes itself and the correct algorithms are simple to determine. Figuring out how to take a complex problem and break it down into problems that you then can throw your algorithm knowledge at is a whole art that takes years of study. A firm grasp of algorithms is essential but not sufficient and it can only help inform your decisions, not provide firm answers. Picking the right problems is the heart of programming. Figuring out which algorithm to throw at a sub-problem is the heart of contract work.

morphir 17y ago
"A knowledge of algorithms doesn't teach you to pick the right problems to solve." That is true. To create a application, one needs a Use Case. A Use Case will provide the most abstract solution to what the app will be doing. Then you can take the top down design approach, by dividing the Use Case into a several abstract sub problems. That is known as code architecture and belongs to System Engineering. The System Engineer needs a domain-expert help to identify what problems that needs to be solved. Then.. Programming is carrying out those abstract sub-problems (interfaces) to become a concrete solution using a specific programming language. To complete such a task, one needs a person that knows his/hers algorithms design techniques, sorting, searching, string processing, graph problems, combinatorial problems, geometric problems and numerical problems. And lastly, the analysis of the respective algorithms. Once you know what to solve, its just a matter of being able to carry out the task. I think you might have confused the programmers job with the job of actually creating the entire software - which in general terms is non-sense. To sum up: The software engineer (the project lead) takes care of identifying the sub-problems, after creating the Use Case with the domain expert (often the customer). The programmer solves those sub-problems bottoms up, by focusing on creating the atomic parts as efficient as possible.
- plinkplonk 17y ago
  "The software engineer (the project lead) takes care of identifying the sub-problems, after creating the Use Case with the domain expert (often the customer). The programmer solves those sub-problems bottoms up, by focusing on creating the atomic parts as efficient as possible." This is how yucky enterprise monstrosities get built. The "software engineer"/programmer division is nonsensical and sounds like something one would find in Wipro or Accenture, not so much at (say) Google or Facebook. "I think you might have confused the programmers job with the job of actually creating the entire software - which in general terms is nonsense." :-D . The term you are looking for (since you seem to be fond of labels to sratify coders), for people who just implement whatever their "lead" tells them to is "code monkey".
  - morphir 17y ago
    Then please tell me how software gets built. Provide me with a methodology, instead of being a arrogant fool like you are now. Yes, a code monkey is a term I'm familiar with. But you need good communication skills too.