+29  A: 

The single hardest problem I have learned, but evidently not perfectly, is trying to maximize performance and prevent thread deadlocks in a massively multi-threaded environment involving asynchronous events from remote calls and from gui events.

Paul Tomblin
your response is merit, but it tends toward the complexity of the application, rather than a particular programming skill, such as multi-threading, which with due respect, is a pretty difficult skill to master.
Haoest
Multi-threaded code is so hard to write and maintain properly that I refuse to do it or allow others to do it unless there is no other way to achieve a desired effect. So, after learning the techniques involved, I've learned to avoid using them. Ironic, no?
PeterAllenWebb
I wholeheartedly agree.
Edouard A.
I have successfully avoided thread programming. I made the argument that it's the job of the kernel to keep all these jobs going at once. No need to re-implement kernel functionality (badly) in userland software. The java people were not amused, and I have successfully avoided java since.
Christopher Mahan
+1 for the topic -1 for the comments. Just cause it's hard, doesn't mean you shouldn't do it. There's infinite value in multithreading. I hope all of your UI's block on long operations :P
SnOrfus
Multi threading isn't hard. .NET has made it all too easy. STABLE multi threading, now that's hard. I don't find it a difficult concept, but I have had several hard bugs caused by multi threaded code. Including one bug that only occured on single core machines.
pipTheGeek
+12  A: 

Until I got my head around it, the declarative nature of PROLOG was a complete left turn from anything I'd touched up to that point. It took me weeks to realise what was going on until - <SNAP> - a light finally turned on.

Unsliced
... and now you KNOW there is little difference between understanding OO and understanding predicate logic! I learned prolog when OO was still someone's vague idea, and when OO arrived I had no problem grasping the concept. (Both boils down to _context_.)
slashmais
+8  A: 

Techniques for effective debugging

EvilTeach
+1, but i haven't mastered this at all, and need to. i live on intuition, and it works for me.
Matt Joiner
A: 

I second Unsliced on Prolog.

unforgiven3
+52  A: 

More code != better

Dan
And people still think that we like to write code, I love to DELETE code.
Fabio Gomes
Yes! I don't know anyone who doesn't love deleting code and having it work just as well, or even better.
Jonathan Tran
Unless you bill by LOCs :)
Camilo Díaz
Same applies to words in a document. :-) +1
Adam Liss
@UnbiasedEntropy: Bill by the hour instead. As Pascal said, "I have made this letter longer than usual, only because I have not had time to make it shorter."
Sherm Pendley
Deleting code is the most fun you can have with your clothes on
Mitch Wheat
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." (Antoine de Saint-Exupéry)
Thorsten79
On the flip side though sometimes less code != readability, everything in moderation I say.
John_
Can't upvote this enough. Over the last 2 months I've deleted literally about 30,000 lines of code from a big e-commerce website (I took over as lead developer). Less code is so much better.
Coronatus
+28  A: 
Jonathan Tran
I will certainly agree with you when I grasp them;)
Steve B.
I hear ya. I was trying to figure out something in everyday life to relate them to, to try to help explain it to others. http://plpatterns.com/post/42929867/programming-concepts-people-just-dont-get I'll post when I figure that out.
Jonathan Tran
Is it worth using a construct that other programmers will almost certainly (from the sounds of it) find hard to grok? What is the overall advantage?
Bill K
Monads can be used to abstract entire computational patterns generically. A monad class can implement flow control, error handling (e.g. exceptions), continuations, sequencing, backtracking and more. Doing this abstractly is necessarily complex.
Chris Smith
I still haven't groked it. It seems you need to nibble away at all the interlocking concepts at the same time in the hope that at some point it will collesce into a single picture. Reminds me of those random looking '3D' pictures that were popular years ago.
AnthonyWJones
Magic Eye images
Jonathan Tran
Also see "Haskell's 90% Problem" -- “The first 90% of learning Haskell is figuring out monads; the second 90% is figuring out arrows; the third 90% is figuring out monad transformers...” :-)
ShreevatsaR
grasping monads is enough to make your eyes water!
Mitch Wheat
I was about to post this too. I've grokked C++ templates and metaprogramming, multiple and virtual inheritance, pointer arithmetic, and whatever else is generally perceived as difficult, but I still bang my head against monads. +1
Thomas
+2  A: 

I would say it's a toss-up between floating point arithmetic (truly comprehending how IEEE-754 works), and theoretical verification (especially of parallel algorithms). But, if I had to pick, I'd probably go with verification.

Joeri Sebrechts
+32  A: 

Pointer. Freaking. Arithmetic. I'm convinced it only exists to keep out the riffraff (and ensure that maintenance C programmers will have jobs until 2137 fixing memory allocation errors).

Patrick McKenzie
Don't you mean 2037?
RodeoClown
I took a class in college that cleared up pointers for me pretty well. Maybe a little too well. I started noticing instances of this->memberfunc() in my C++ code after that class.
Brian
this->memberfunc() is legit. I'd be worried if I saw you trying something like (this+3)->memberfunc(), though. Hehheh.
Greg D
I don't really understand why people find pointer arithmetic hard, but then again, I am the guy whos best four subjects in uni were the four assembly language/computer architecture ones.
Dan
Pointer arithmetic is not hard, working with pointers/passing them around and managing the life of the objects/resources they point at, is horribly error prone.
Pop Catalin
Hey, works for me... :)
LarryF
The difference between Java and Lisp on the one side, and C and C++ on the other side, is pointer arithmetic. All four languages make very heavy use of pointers in typical applications.
David Thornley
+1 Pointer arithmetic is how the processor works. It's almost all there is! Everything else in programming has been put in to keep the riffraff in!
Guge
+22  A: 

Recursive functions.

Although, after figuring the pattern out it has helped me to look at new problems from totally different viewpoints.

chills42
Even with a seasoned programmer, analyzing runtime for some recursive functions is pretty challenging.
Haoest
Really? My view is that recursion is pretty simple. I hate the way introductions to recursion always start with "Right, concentrate kids, this is really tricky." That just scares people and makes them less receptive.
slim
After learning functional programming and recursion I've realized how simple it really is, but initially wrapping my mind around the concepts was tough.
chills42
It took me a while to get my head around recursion, but then one day it just made sense. Now I often think recursively before I think iteratively. I really must get back to learning Common Lisp... or OCaml.
Dan
It's far more simple for me to program recursively than iterative. What I sometimes find hard is to translate a recursive routine into a iterative one.
Pop Catalin
+4  A: 

The hardest thing relating to programming is finding adequate documentation. I usually know what I want to do, and have a general idea on how to implement it, but finding the details through documentation very seldom works.

Lance Roberts
+4  A: 

Monads.

First exposure is ok, then you try to explain it to someone else and can't do anything but go reread the papers.

Then you discover STMs and wonder why people are still playing with locks and threads manually. Computer science is still in the stone age... :)

bltxd
+1000 for mentioning monadic STM.
Dario
+22  A: 

Truly appreciating the value of testing and being able to design for testability and to be able to write testable code (and also writing test cases that actually properly test what's being tested).

Ates Goral
+3  A: 

Writing your entire program as an expression; which is essentially what a functional language like Scheme or Lisp demands. After that would be identifying the resources that need to have thread contention protection. I would say debugging deadlocks in threaded applications, but there seems to be so much variety in what can go wrong that I always learn more while debugging.

dlamblin
Sorry, I think that either all languages can be said to have the entire program as an expression, or none. Also, if by Lisp, you mean Common Lisp (Scheme is another Lisp dialect), it supports a wide variety of programming paradigms.
Svante
@Harleqin: No. Procedural languages such as C and C++ make a distinction between *expressions*, which have values and can be combined using operators (such as "3 + 4" or "x += func()"), and *statements*, which do not (such as "if (x) { y = 3; }").
j_random_hacker
+3  A: 

Emacs

me: what's the key binding to commit a file?
emacs master: C-x v v
emacs master: you can list all the key bindings with C-h b

(10 seconds later after I typed my commit message)

me: what's the key binding to actually commit now?
Jonathan Tran
Did you mean `C-x v v`? Type in Emacs `C-x v C-h`
J.F. Sebastian
Yes! See? I guess I still haven't learned it.
Jonathan Tran
Try C-x M-c M-butterfly. http://xkcd.com/378/
Thomas
+4  A: 

SQL. Hands down.

C#, C++, C, Clipper, x86 Assembly, Javascript were easy compared to SQL. I guess it was hard to change my mind from procedural languages to a set-based language.

Kluge
I think it all depends on what type of programming you learn first. The difficulty lies in making the switch.
Bill the Lizard
Really? I've just learned SQL while doing things ... and I really enjoy the power it gives you to work with data, although it's not my favorite option, I still occasionally write some crazy SQL to pull some mixed/twisted data and work with it the easy way. (By crazy SQL i mean 10 pages or more ...)
Pop Catalin
+1 for SQL. I know just enough to be dangerous.
Tim
A: 

C pointers were always a pain for me. I've been able to figure out how to use them, but I find that whenever I take some time away from C, I need a refresher on pointers when I come back to it.

Dana
+1  A: 

The very hardest part overall was probably when I was 15 or so and was trying to understand the concepts behind BASIC variables on my TRS-80 so that I could interact with hand-coded assembly routines I was fooling with.

Figured out pointers, reference counting and memory allocation all in one week with no help except for a z80 assembly reference book (Nobody I knew had a computer in '78, and there were no "For Dummies", by reference book I'm talking no examples--just bitecodes, register descriptions and electronic signaling.).

When I came to C like 10 years later, pointers were trivial and obvious.

Everything else--inserting bitfields into assembly operations, converting them to integer values so they could be poked into memory, ... was just fun.

Bill K
Luxury, you had Z80 mnemonics. _WE_ had to do 8080 mnemonics, and we were LUCKY!
Thorbjørn Ravn Andersen
Very true. I was spoiled by the Z80 mnemonics and never felt comfortable with Intel's insanity after that.
Bill K
+1  A: 

Recursive algorithms, especially dynamic programming.

Christopher
+3  A: 

Network programming (in both C++ and Java). Maybe just because it's tedious, but it seems like 50% of the code is either detecting or recovering from an error condition.

Bill the Lizard
+4  A: 

Setting up a large, existing project in Eclipse (or any IDE) so that it will (a) build and (b) allow debugging (inside the IDE for both).

I dislike configuration: I don't have the patience for it and it seems the only way to get experience is to repeatedly fall down flights of stairs. There are no university classes; there are few books. Pair-programming helps greatly here.

I have learned to do it but back in the day (2002-03?) it was the bane of my existence. To this day, I will help you with anything I can, but please don't ask me to set you up with Eclipse.

Michael Easter
I remember setting up eclipse to compile Nintendo DS games then run them in an emulator - by following google-translated french instructions and screenshots from an older version of eclipse. I still find myself creating a new eclipse installation for each language...
Dean
maven eclipse:eclipse helps. Unfortunately that means you now have to configure maven with pom.xmls instead. :)
Thorbjørn Ravn Andersen
+8  A: 

XSLT. It requires holding multiple complex "plates in the air" all at the same time: a declarative/recursive program that is manipulating (at least) two document structures, at least one of which is usually hierarchical.

It's hard to write, even harder to read, and not conducive to standard debugging techniques.

Chris Noe
I think XSLT has a crazy learning curve, but in my experience, once you get it, it becomes the most natural thing in the world.
Robert Rossney
The first time I looked at XSLT I was taking over a big system from someone that was leaving andI hadn't used it before. I just shook my head at all the gobbledegook. I then bought a book and after reading a few chapters it clicked. At least I think it did!
Valerion
+2  A: 

Breadth First Search and Depth First Search algorithms.

RyanFetz
are you being serious?
jinsungy
+33  A: 

Regular expressions.

Bruce Alderman
They aren't that intuitive to decipher. Come across a big regex and trying to figure out what it'd doing can be very difficult. I don't tend to use then that much so whenever I do I find myself reaching for a book.
Valerion
huh? Regular expressions are far more simple than programming in general.
Pop Catalin
There, there...
itsadok
@Pop, try Perl regular expressions!
Thorbjørn Ravn Andersen
+33  A: 

What people say they want from a program != what people actually want from a progam

Matt Lacey
IMHO this is a core skill from being just any old programming and being a good programmer. People are biased towards their existing work process, which is NEVER optimal. Especially so with new software, more often than not, needs to redesign the whole process from scratch.
TravisO
The worst solution you can ever make is taking paper forms and merely display them on the screen exactly the same way.
TravisO
If I could upvote this 37 times, I would! People able to listen to what people say they need and figure out what they actually want is indispensible.
rwmnau
Oh, so true... . An extension of this is that : what people actually want from a program != what people really need to solve their problem...
sleske
Non-programmers are lousy communicators!
Guge
@Guge I've known lots of programmers who are lousy communicators also. I think the real issue is poor requiremetns gathering.
Matt Lacey
@Matt Lacey. You can gather requirements 'till the cows come home. What you get is someones understanding of a problem. That problem may very vell be a symptom of a different problem alltogether. Let's say that the users say they want a better userinterface for task X in a program. But you can remove task X from the system by integrating system Y with system Z! So, they said they wanted to make it easier to do task X, but if they knew that it could have been removed, that would have wanted that instead. And even when they know what to want, they usually can't make a very specific request.
Guge
+3  A: 

Functional Programming - Recursion, I'm finding that I have to constantly re-factor code to improve it. It has made force me to think in a new paradigm which is a challenge.

Brandon
A: 

Formal lexing and parsing techniques are the most difficult concept to master that I have actually used in the practice of day-to-day programming in a normal software shop. Being able to create and parse a simple language of your own design can often be a life-saver in terms of long-term productivity, but can also be a royal pain in the ass if you don't know what you're doing.

PeterAllenWebb
A: 

I don't think I've ever done anything harder than debugging someone else's assembly-language code when my starting point was a listing and a cheat-sheet of op codes and the only language I'd ever programmed in was BASIC. I got pretty good at it. I've built my entire career around not ever having to do anything like that again.

Robert Rossney
+2  A: 

Several people have already mentioned multi-threading and thread safety. Although I find these disciplines difficult, the real hard stuff for me is finding ways to TEST multi-threading and thready safe code. In the comfort of a sandbox/sample program forcing these situations to occur is only a little harder than trivial; but in a real, otherwise working application I say "Pshaww!" and "That's hard".

CrashCodes
+36  A: 

Learning to ask for help early on rather than try to be the hero and figure out something on my own which may take too long.

JB King
It's still on the "TODO" list for me...
Asaf R
Of course, there is a balance here. You (or me) might learn more if you figure something out for yourself. It is also very disruptive to interupt another programmer. Although asking on SO is always good. :)
pipTheGeek
Yes, the balance is what makes it so hard. Sometimes I'll spend days on something that someone else will know how to fix within minutes. That's the case I'm trying to avoid at times.
JB King
A: 

Pointers !

Vijay Dev
Down voting without explaining what's wrong !! Pointers is not a concept, is it ?!!
Vijay Dev
How are pointers not a concept? Try explaining them to your grandmother, then.
guns
+15  A: 

Learning to deal with people who lack skill in architecture and meta concepts but who illogically think that some other expertise makes them correct in this area.

Now in general, I have an easy time getting along with people, and this is a rarity, but when it hits, boy can it be a doozy. Often what you are fighting against here is someone's ego, or rather you are trying to debate a point of logic, but finding the ego shield is protecting the logical vulnerability. It can be hard to convince someone that you are in fact correct and that they have a made a mistake when they have already decided their superiority because they know oh so much more than you about: A)Graphical engines B)SCRUM C) The C++ spec D) Making flow charts.

These hardest cases are where the person DOES know a great deal about some area, but has some inability to understand a logical argument... so if you question the logic of "having skill X automatically translates to skill Y" ends up getting interpreted as "ZOMG you have questioned my skills, how dare you."

This is the single hardest skill I think a programmer will ever had to learn. It is especially hard for a programmer because we tend to be poor at diplomacy, especially in the face of illogical arguments. Nothing in school will train you for this, and it really only tends to happen once you hit the mid and senior levels.

David Frenkel
I agree. It's also interesting that most of the time when this kind of question is asked the usaual answers are about a specific technical item being difficult. When in fact (and you do learn it when to get closer to senior level) the people skills are often the most difficult.
Chris Pietschmann
A: 

Eloquence.

you've mastered succinct!
Steven A. Lowe
+14  A: 

Modularity and abstraction.

This is something far too many PHP web developers just do not 'get'. There is something to be said for black-box isolation of APIs. Too much code does everything from assembling HTML to sending SQL to the database on the same page. Bad. Wrong. Doesn't scale.

staticsan
Downmodded for PHP hate; this is something far too many developers don't get period, regardless of language
George Jempty
PHP hate? I'm a PHP programmer! It was an observation based on my experience at picking up PHP projects.
staticsan
I upmodded u a bit ;). While I don't hate php, it does sure suck, but just because of everything nasty written in it, not for the language. Possibly except that it, and all tutorials for it, begs for bad code to be written! http://www.theregister.co.uk/2009/05/25/dziuba_microsoft_php/ ;)
Henrik
+39  A: 

humility

(still working on it)

Steven A. Lowe
(your answer made me think of this) **Hubris** - Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer.
Dian
+1  A: 

I'd say designing programs; that it, which code goes where, what should be static, what should be an abstract class, what should be an interface, how it al fits together etc.

I think it's a difficult thing to learn, and comes with experience.

Cocowalla
+3  A: 

GridBagLayout

GBL code itself is hard enough. But then figuring out how to make it NOT look like ass was damn near impossible.

madlep
Dude, check out the new GroupLayout stuff. It's much, much nicer. http://java.sun.com/javase/6/docs/api/javax/swing/GroupLayout.html
Chad Okere
And we only had to wait until Java 6 to get it!:)
dw.mackie
Agree, GridBagLayout is the prime example of an API _not_ driven by use cases. Sigh sigh sigh.
Thorbjørn Ravn Andersen
A: 

I haven't learned it yet.

Feet
A: 

Developing fast and believable artificial intelligence for games. I've been learning it for 15 years, and still learning.

Gerald
A: 

Continuations. It was a real brain-twister to learn how continuations work in a language like Scheme.

Barry Brown
+3  A: 

The whole C++/OOP thing.

I used to hate it, curse it, lose sleep over it, because EVERY program I had to write for my BSCS HAD to be in C++ unless the course was specifically for another language.

BUT, once I finally got my head around it, I loved it, sang its praises, and wondered how I ever wrote decent code in any other language.

And everything I had to learn since then has been easy by comparison. ;)

CoderChick
+1  A: 

quaternions. super cool stuff once you grok em

Scott Evernden
I was going to say that too- Quaternions are so confusing. I'm not sure I understand them properly even yet, but they are invaluable.
glenatron
It you can't understand it, it _must_ be smart! (Actually, it was a valuable lesson to learn just how wrong that idea is.)
Adam Liss
+40  A: 

"Do the simplest thing that will work".

I used to spend far too much time trying to code every possibility into the routine, planning for any eventuality. Of course, all that extra code meant more chance for defects and more debugging.

I learned that most of that code is never actually exercised. Worse, when the eventualities really do occur, they don't follow the assumptions you made back when coding, so you have to revisit the code and change it anyway. Except it's so complex with possibility thinking that it's harder to change than if you had never bothered.

So now I just write my code for the exact problem at hand. Later, if I need to add something else, I'll re-write (refactor) the code to be the simplest thing to solve the new problem.

-R

Huntrods
I've only recently learned this, now trying to teach the rest of my team.
pipTheGeek
BTW, that's called "You ain't gonna need it" (YAGNI) by the agile folks, and it's actually one of their most important guiding principles.http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it
sleske
It's a bit like Einstein said: "Everything should be made as simple as possible, but no simpler."
sleske
+2  A: 

Writing easily readable, clear code and not trying to be too clever. So much easier on others and yourself when you have to fix a important bug under time pressure.

Testing is another thing. Never push something that can not be tested. I've once held off a 1 line code change for a couple of weeks as the edge case was pretty difficult to reproduce (needed things to have a particular data happening with a set of other conditions). Better to wait than push out untested code.

Arvind
Upvote for readable, clear code! And realizing that programming is form of communication -- not with the compiler, but with the humans who will be reading your code. (And those humans might very well be yourself, three years from now. Or three minutes.)
Thomas Padron-McCarthy
A: 

One thing I still struggle with is the idea that programming is difficult. To me, it comes easy. That leads to some difficulty interacting with other programmers. I've been called arrogant, which I find ironic - in fact, it's a lack of self-esteem that sometimes leads me to believe that others simply aren't trying. After all, so my thinking goes, I'm nobody special, and I can do this - so why can't everyone?

Sherm Pendley
+6  A: 

C++ template metaprogramming.

Martin Cote
they were, and are still complex at times!
Matt Joiner
+1  A: 

ClearCase. Specifically it was difficult to restrain my homicidal urges while using it as a source control system.

madlep
+11  A: 

Stifling my instinct to reformat or rewrite legacy code as I work through it. It's far more productive (and less error-prone) to add a few judicious comments that explain the epiphanies along the way.

Adam Liss
Partially disagree. While you cannot singlehandedly save the world (or even a single legacy app), there is a point where refactoring *is* easier than keeping the code. Especially if you have to change it anyway.
sleske
@sleske: Definitely. Sometimes you're lucky and can make significant improvements with well-contained or low-risk changes. But it's so tempting to "just make it right" -- at the peril of introducing subtle bugs and exposing hidden interdependencies that become horrible time sinks.
Adam Liss
A: 

Maybe not the hardest (it depends on the individual), but certainly the most important for me has been:

Learning to visualise abstract concepts (OOP, set theory, concurrency etc)

jacko
A: 

Self-referencing Common Table Expressions. They seem so simple, but recursion in a set-based language like sql is much, much different from recursion in an iterative or functional language.

Rick
I really need to learn about CTEs properly!
Valerion
+1  A: 

Not trying to build my support libraries too early.

I've only recently figured out that you can't write the database-access abstractions or state-saving classes or whatever else until the second time you need to do that task. Only then will you be able to see enough of the general problem to know how to write a solution for it.

Brent Royal-Gordon
+15  A: 

Threads.

I never knew what was happening.

Later everything came clearer.

Later I understand, I should not do threads but leave all to the application server :)

OscarRyz
A: 

x86 segmented memory architecture. It doesn't help that FAR addresses are represented differently using asm/C.

Draemon
A: 

Python tuples. I kid you not.

There's been a long running holy war, with fanatical jerks on both sides, as to whether tuples are read-only lists.

Well, they are.

But that isn't just all they are. And that's what was tricky to me.

Halfway through the argument, I realized that I had never needed a read-only list, yet I used tuples all the time. Sorting through that revelation helped me understand not only the "intended use" of tuples, but also why certain implementation details were or weren't like those of lists.

It's Python, so I still reserve the right to use tuples as read-only lists, or lists as read/write tuples (as much as the implementation will let me), but now I understand why some uses are more natural than others.

J.T. Hurley
+10  A: 

Object Oriented Design (and programming)

When I was just starting, I had a really hard time with it. Actually, I couldn't grok it until a really good prof explained it to us.

hasen j
+3  A: 

Simplicity, by a large margin.

Thibaut Barrère
+10  A: 

The hardest thing I learned was to resist the temptation to just jump in and start coding. Every hour you spend designing and thinking beforehand probably saves you a day in actual coding time.

Valerion
A: 

"The Realm of the Final Inch" - when you think you are done there is still a whole lot to do !

LenW
+1  A: 

APL. Brrrrr

n8wrl
+3  A: 

I know that nowadays everyone begins their programming education with OO - but when I started out OO was niche stuff. It took me nearly ten years from first exposure to actually applying it in a useful way.

slim
+1 for ten years without giving up:)
pierr
Heh, I gave up lots of times ;)
slim
+2  A: 

Mh, I can't really decide.

The first really akward things are Monads in Haskell. I think I finally began to understand them, because one of our professors told me about the concept in a totally different way ("Monads basically overload the ; and the = in Java").

The second really big step was to move from "Hey, I use class in my code, I am object oriented" to actually designing object oriented with concise objects that are told to do things. Python and its dynamic typing helped me a lot here.

The third big step was to actually understand the concept behind DSLs and thus starting to see where one could use them. This occured to me while pondering about Aspects (another candidate) and other advanced techniques to simplify programs.

One of those was the hardest concept to learn :)

Tetha
+2  A: 

Makefiles

More specifically understanding other peoples obscure Makefiles

+1  A: 

The different structures of $_POST['files'] data and a regular, normal, god-fearing PHP array.

if you're talking about the uploaded files they are in $_FILES not $_POST
Click Upvote
+2  A: 

Probably my biggest challenge was writing my own implementation of a database index using red-black trees in memory mapped files. I had to write my own memory allocator in order to to allow the removal of nodes as well.

I did have trouble grokking the concept of Object orientation when I first started programming when I got my first computer and taught myself C++. That was when I was 15 or so. (I had actually taken C programming classes before owning a computer)

Chad Okere
A: 

Target compiling in Forth.

Bill Drissel
+1  A: 

Linked lists in C++

Binoj Antony
+2  A: 

Many potential candidates here. Writing a virus in assembly language as a teenager. It was hard because I had to deal with self changing code and stupid segments in x86 assembly, and because information was not as easily available as today. I had no internet, BBS or anything like that to access.

PS: I didn't write a virus that was spread, outside my own computer. It was just for the programming challenge ;-)

Adam Smith
+1  A: 

C++ -- and I must admit that I gave up eventually. I can write complex code in roughly 30 programming languages and I learn a new one every year. I wrote OO programs in C long before people know what OO was but C++ ... ugh. As a friend of mine said: "To understand C++, you must be a C++ compiler".

That's way better than my comment: "C++ is the successful attempt to force developers to use every non-alphabetic character on the standard US keyboard in every single line of code."

Aaron Digulla
You've obviously never seen J.Just picking a random example from the J website (JSoftware.com), this is how you solve the N queens problem:queens=: 3 : 0 z=.i.n,*n=.y for. }.z do. b=. -. (i.n) e."1 ,. z +"1 _ ((-i.){:$z) */ _1 0 1 z=. ((+/"1 b)#z),.n|I.,b end.)
MatrixFrog
What I usually say: "There are about five people in the world who can design a good programming language. One of them is Guido van Rossum."
Aaron Digulla
I've been programming C++ for over 10 years, and have become pretty good at it, but it still scares me.
Thomas
Your comment, though, seems to be referring more to Perl (or J, als MatrixFrog noted).
Thomas
+1  A: 

Model-View-Controller took me some time to fully understand, but hind-sight is 20/20. From the side of understanding, it's genius, and amazingly simple.

Jonathan Sampson
+12  A: 

To strike the word 'easy' from my vocabulary.

"Yeah, I can do that, that'll be easy!"

sjbotha
so true. I also learnt to multiply by five the time I think it'll take to complete the task at hand.
Alexandre C.
+3  A: 

Functional Programming.
It's such a different approach to problem solving that I find it very difficult (but very valuable) to wrap my head around it.

dw.mackie
+7  A: 

Continuations (and call/cc).

Total nightmare to wrap your head around. For those who are not aware of call/cc... it's sort of like a mathematically sound GOTO with no side effects.

I.e., it is a riddle, wrapped in a mystery, inside an enigma.

DanM
A: 

Comments

Not the idea that you should comment your code, or that you shouldn't comment every single line. There is always an exactly right kind of comment, one that adds just enough explanation about why a bit of code does this or that so that it makes some sense.

Before I started reading other peoples code, I mostly used comments as inline documentation, explaining what the arguments were, what the return value was, what the function was supposed to do. Only code changes, and comments turn into lies.

When actually reading someone elses code, you will usually start by looking "what does this actually do" because when you tried to use it, it didn't quite work the way you expected, so you read carefully what it does in the particular case you're interested in.

95% of the time, if the code is concise, uses meaningful identifiers, is well factored, you never needed to look at the comments to understand.

The first few times when that other code was just a bit too clever for me to grok by reading the source, and there was a comment there explaining the bit of cleverness, thats how I came to understand comments.

Now I use them for just that purpose. If I had to think hard about how to make something work, like look up a formula, I'll document where that formula came from. If a bit of code seems sloppy as I'm writing it, or condenses much logic into few tokens, I'll leave a note explaining the reasoning behind it and why I excluded other choices.

In particular, I comment about the assumptions I make about the caller and the data they've sent.

TokenMacGuy
+1  A: 

How/When to just fix a bug without throwing out the current version of the code and starting over.

Chris Ballance
A: 

To do it in the simplest way.

Ali
A: 

Regular expressions continue to kick my butt. If I don't keep my head in regex on a regular basis I will forget whatever I learned the last time I was in it. Regex has the additional problem of once it's working right, I don't have to go back to it and use it again for a long time.

It's like taking 3 years of Spanish class, then not going to Spain to use it and make it fluent. Of course that statement, itself, could be applied to a lot of things in programming.

Patrick
+1  A: 

Fast Fourier Transforms. For whatever reason my head didn't want to wrap itself around those for the longest time.

acrosman
+2  A: 

The hardest is Psychic debugging (Raymond Chen style) from clueless-user input :D Especially when internal, non-technical teams are involved as intermediaries.

Finding a probable cause to a problem linked to an interaction between your code and some hardware without any version/model information and two level of interpretations (customer and internal) of a cryptic error message is the hardest of the task... Finding what the original error message could have been being the hardest part.

But the day always shine when after a wild guess answer the customer come back with a simple "Thanks, that solved it."

VirtualBlackFox
Hah, I like that :) Very recognizable.
Thomas
+1  A: 

How video codecs work. Including DCT/iDCT transforms, quantization, zigzag scan, huffman coding, CABAC, motion estimation searches, not to mention rate control - single pass MB-based CBR is probably the hardest thing to get my head around. Once you understand these concepts you can understand most video compression algorithms, like the MPEG family or anything that is block-based and does quantization in the frequency domain.

thomasrutter
+1  A: 

To have patience.

jerebear
A: 

Learning to use other people's code, instead of coding my own version of software that does the same thing from scratch.

My first brush with Prolog also made me go crosseyed. Took me a while to get used to thinking backwards.

A: 

Whilst not a programming language, being able to write mostly cross browser HTML & CSS.

alex
A: 

the hello world application

adi92
while impossible to infer any sarcasm, it's possible the meaning being "my first program", eg the first step being the hardest. That said, I have no idea if that's right.
DevSolo
+1  A: 

Getting a non-trivial multi-threaded program to work properly with both no-deadlocks and good performance.

Mark Goddard
A: 

Although not typically considered a programming skill, I would say Logic, and how it applies to my programming on a daily basis. Not just the standard ways in which it is applied to computer science, but also logic in and of itself.

For example, Kurt Gödel's work on arithmetic logic and his theorems on incompleteness ("no useful system of arithmetic can be both consistent and complete") have huge implications and apply directly to work in programming, in my opinion.

Reed Copsey
A: 

The customer doesn't want clever or elegant code. The customer just wants to see his problem solved.

Konamiman
A: 

Admitting to a development team that you were wrong, and then having the courage to go back to the drawing board with them and start all over again.

Kiffin
+1  A: 

Formal Languages and Compilers. Those were definitely the most challenging concepts I've learnt during my CS uni. Luckily I had a really good professor that would make it sound really interesting. Compile a program by hand on paper and then simulate its execution was quite a challenge.

Emerson