Essential concepts to remember to be a better programmer

Question

What concepts should you memorize to make yourself a better programming problem solver?

For example, remembering Big-O complexity for the most widely used data structures.

Answer 1

I don't think that memorization precludes the ability to problem solve.

Answer 2

I agree with Sean, I don't think memorization will help with your ability to solve problems.

An alternative to memorization to make yourself a better problem solver would be to actually solve problems. Just working through the logic will tickle the brain and keep you sharp.

Answer 3

Practice and learn. There are so many concepts to deal with in software development.

Answer 4

I think one of Jeff's greatest blog entries was It's always your fault. If you can learn to master that concept you'll go a lot further than the crowd.

Answer 5

Solve the issue completely. Try to see the broader implications a certain fix might have. "Why am I having to fix this at all?" "What could have been done to avoid the problem altogether?"

I think software design's rapid prototyping capability (as compared to, say, designing a nuclear sub) makes it easy to "make it work" quickly without thinking about the framework and the tradeoffs you may be making down the road.

Answer 6

YAGNI and DRY

Answer 7

@Sean: I agree, but memorization only saves you a minute here and there when I can easily find the answer by asking Mr. Google. Concepts are more important in the broad scope of things.

Answer 8

Loose coupling

Answer 9

Test Driven Development

Answer 10

Coding for violent psychopats

Answer 11

To outline Philip Chu's Seven Habits of Highly Effective Programmers:

1. Understand Your Requirements: Build early, deliver often
2. Keep It Real: Use real data, use real builds, merge often
3. Understand Your Code: Code with style, don't simply cut-and-paste, keep it clean, comment your code, compile with full warnings
4. Optimal Programming: Code with purpose, do no harm, find the bottleneck
5. Manage Thyself: Schedule, plan your progress
6. Continuous Education: Coding is science, almost everything you need to know is free
7. R-E-S-P-E-C-T: Don't ask stupid questions, don't give stupid answers

But seriously, read the original article.

Answer 12

Talk to your users . . . a lot.

Answer 13

Code Complete should keep you busy for a while.

Answer 14

Exceptions should be exceptional

Answer 15

If anyone listens to the Stack Overflow podcast, they are well familiar now with Jeff and Joel's debate over needing to learn C. I can see both sides of the argument, and though it's been beaten to death and is a humorous reference now, I think there is some validity to the underlying point. I don't necessarily advocate learning C, but learning some sort of lower-level language and the concepts that accompany it I feel are so very important. Getting closer to the metal and realizing how things work in the machine -- how instructions are executed, etc -- was eye opening for me in college. Further, starting out during the DOS/OS2/Windows NT cusp, I used C, then C++, heavily. Unlike today, there were many times having an underlying understanding of pointers, stacks, heaps and the like were critical.

A former colleague of mine who came up during assembler/COBOL days, but also moved easily into and through the VB, Java and .Net spaces, used to say that he thought every programmer should learn assembler first -- I will admit to seeing some value in that. (God help you, take no concepts from COBOL...)

So, to be way too long winded, I think there are some of these concepts that still apply today in a heavily interpreted and managed language world. Even .Net still has a stack and a heap that operate in a similar manner. I think the overall message when learning C, especially when I did, was that you had to be smart and efficient with your coding. Those concepts are certainly universal.

Answer 16

Divide and Conquer

Answer 17

My take:

1. Reading other people's code

2. Writting "hobby code" to know more and more about any language

3. Solving puzzles(Mathematical, Logical, or Programming kind of puzzles)

Answer 18

Repeat same problem over and over until you got AHA!

Answer 19

Fail fast and fail loud.

The idea behind this is if you come across a data error you cannot fix (or an unknown state, or something that just cannot happen), halt! This prevents bad data from being stored or processed.

This of course is from a business application mindset, if something isn't correct with your GL data, don't save funky GL data.

Answer 20

python -c "import this"

The Zen of Python, by Tim Peters

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren't special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one-- and preferably only one --obvious way to do it.
• Although that way may not be obvious at first unless you're Dutch.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it's a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea -- let's do more of those!

Not only for Python. Print it. Frame it. Memorize it.