Speaking as someone with an Electronic Engineering rather than Computer Science degree, what is the one bit of computer science I should know to make me a better real world programmer?
(By real world I mean something I'm going to use and benefit from in my day to day job as a programmer - for instance I'd suggest understanding database normalisation is of more practical use than understanding a quick sort for which there are lots of libraries).
If I have to choose just one bit, which is a difficult decision, I'd say go for the Big O notation. Understanding the implications of O(n), O(ln n), O(n²), O(2^n), O(n!) helps you to avoid a lot of expensive mistakes, the kind of which work well in the test environment but disastrously fail in production.
This is a question, everyone will have a different answer on. I would say: complexity theory is the most important piece, that you don't directly learn as a programmer anyway (like algorithms and data-structures), but what may impact your work. It helps if I know, that a problem is has cubic complexity, I know that it will scale badly if the problem size is increased.
Learn about data structures, algorithms and complexity.
Not too much just to get an understanding that a machine is not a magic box with unlimited power. You can't throw anything at it and expect it to crunch it in milliseconds. It has limits you know. You need to learn to not test them out with your code.
Also have a look at common approaches to solve particular design problems in programming. Design patterns namely. Don't worship them just take the ideas they communicate.
Knowledge of database modeling is essential as well.
After that it's just different programming languages, frameworks and libraries that implement or let you implement the core concepts. Pick up whatever you like and practice with those.
This is a bit of a difficult question.
All aspects of Computer science are important in one way or another.
In terms of what you will benefit on a day to day basis, probably a generalised overview of how your code works "under the hood" from code to CPU.
Understanding Big O Notation is important, and also understanding how your code may be executed is also very important in real world situations.
Yeah, This kicked me into thinking for hours.
In the process, I had to remove some of the common answers given here already.
NO LIST
Big O(n) notation. Hard to put it here but No, we can intuitively work out inefficiencies and compare different set of procedures without having even remotely heard of asymptotic algorithmic analysis.
Functional languages No, A single family of language is just one approach to thinking about problems. Why only this bit should matter?
Halting Problem Some are just too specific and people have lived life without knowing they existed.
Listen If you are not listening then you live in world of your own. Not necessarily detrimental!
Software Development Cycle Nah! We can still bumble our way to some incredible software or solo heroic effort.
complexity theory I guess this could be it but without all the formalisms
That one bit of idea from Comp Science
I would say - "Abstractions Abstractions Abstractions ...". Learn about it. See examples around it and learn how to build using it. It is every where. The whole of computer science, engineering and applications looks like layers upon layers of abstraction.
Once you know this, you start learning to look around well.
When you see some one using list insertion in python and not append, you smile because you know that python lists are built using array abstraction where insertions are costly and append cheaper.
This is but one example.
Competitive use cases of data structures.
There are situations where a map with red-black trees is required to guarantee performance and others where you cannot use an array, again to guarantee performance. Knowing when to choose what data structure is an invaluable skill.
there are only three numbers that matter:
The most important thing I learned in CS (and as a developer for many years and as an architect) is the ability to break a problem down based on volatility and not on function. All good designs isolate and encapsulate volatility. All good developers/architects do this intuitively even if they have not formalized it in their thinking. A huge reason for project failure is the failure to break a problem down on the basis of volatility and encapsulate it. A failure to encapsulate volatility inevitably leads to run away complexity and project failure.
The fact that computer related problems exist that simply cannot be solved by a computer.
You should know enough automata theory to be able to know where the problem you're dealing with falls in the hierarchy of formal languages. From that, you can figure out a few important practical uses, like why you shouldn't use a REGEX to parse HTML (HTML needs a context free grammar to describe it), and why it takes so much longer to compile C++ as opposed to Java or C# (C++ requires a Turing machine, while Java and C# can be described with context free grammars).
The most important tiers of formal languages are, from weakest to strongest:
Languages that can be parsed by a finite automata, or a REGEX (REGEX implementations with backreferences are more powerful than this category, but they still can't parse everything in category 2)
Languages that can be parsed by an automata with stack memory, or a context-free grammar.
Languages that can be parsed by a Turing machine, or an automata with random access memory.
Well, I could give you a dull answer: automata theory, and information theory.
Or I could tell you what I learned from a hardware consultant a long time ago:
From the Department of Mathematics and Computer Science Hobart and William Smith Colleges comes Computer Science 124 Introduction to Programming:
Topics include control structures, objects, classes, inheritance, simple data structures, and basic concepts of software development.
If you can't program, you're not going very far in real world computing.
And, yes, I've noted that you are programmer. This is to improve your overall knowledge of programming theory and what other approaches there are available to you.
Is programming Computer Science as we know it?
In response to the comment from @Thomas Owens, who pointed out (quite rightly) that programming is not strictly Computer Science, I'd like to quote from Wikipedia's Computer Science article:
... the focus of computer science is more on understanding the properties of the programs used to implement software such as games and web-browsers, and using that understanding to create new programs or improve existing ones ...
Thus, as I read it, by programming you are demonstrating your understanding of programming theory. This should in turn help you to create simple, elegant code that is a joy for others to work with.
Software Development Life Cycle is something I'd suggest knowing if you don't already. Granted this was introduced in a second year Computer Science course and is something used repeatedly within software projects. This can be useful to get a general idea of how does a project go from start to finish, though if you want to more in-depth there are methodologies like Waterfall or Agile that you could study to get more specific knowledge.
I have to disagree with Konrad Rudolph. There is "One bit" of computer science you should know to make you a better "real world programmer." If you take nothing else away from the answers you're getting here, at least consider this- Satisfying the requirements is NOT the same as satisfying the client! The end users will ALWAYS try to use your program in a way you never thought of or coded for. ALWAYS, ALWAYS, ALWAYS.
Therefore, in order to be a better programmer, you must first LISTEN. Listen to the client. Listen to their needs. Listen to their wants. And especially, listen to their level of "techs-pertise." I can't tell you how many times I've seen a project built that was exactly what was requested, but not at all what the client actually neeeded. All because the programmer gathering the req's wasn't really listening.
Something else you can take away is, unless you've got a background in UI design, get someone eles to design the UI. I can ALWAYS spot an app where the UI was designed by the programmer and not an expert. What is logical and makes sense to you will not make sense to the client. And, if your clients aren't tech saavy, (and who's are?) then your "functionaly correct, but esthetically ugly" solution will be met with the warmth of skunk at a dinner party.
Functional languages!
Learning functional languages makes you think in terms of expressions, rather than steps and named mutable states (variables). This has a significant impact on your ability to effectively deal with every-day programming problems - especially now that almost every popular language has functional features.
Algorithms and complexity theory is also important, but it is somewhat less interesting in that it mostly lets you put names on stuff that you usually already knew and could deduce.
That computers are essentially pattern matchers, nothing more. Everything boils down to the Turing Machine - the classic Computer Scienceconcept of explaining pattern maching.
Problem Solving and the desire to continue learning!
They serve me far better than knowing quick sort and database normalization.
