The Hardest Thing in Programming
It’s not learning your first language. It’s not learning your second and third languages either. It’s not learning Lisp, Scheme, Ruby, Python, Erlang, Haskell, Perl. It’s not knowing C back-to-front, upside down. It has nothing to do with Java, script or regular, nor is it anything to do with Objective C, C++, C#, or D. It’s not even assembly language.
It’s not grokking recursion. It’s not using functional languages. It’s not understanding things like function currying, and other fancy tricks.
It’s not knowing the hardware down to the bits. It’s not programming for embedded systems, or for giant mainframe clouds. It’s not getting a Computer Science degree. It’s not working for Google, or Microsoft, or Sun, or IBM, or anyone. It’s not working for yourself, either. It’s not managing your time, nor is it managing others’ time. It’s neither agile nor extreme.
The hardest thing in programming is that no matter who you are, and what you’re doing, most of the time someone else has done it, done it better, and then released it for the world to see and use. Instead of re-inventing the wheel, your best course is to close emacs, and spend some of that time you were going to spend creating the world’s seven millionth web framework scheme reading documentation, and learn to live with it.
Although I never really got the hang of that currying business.
Fuel another post
September 17th, 2008 at 9:34 am
Yep, I think you’re right…learning something else often feels harder than writing something from scratch.
September 17th, 2008 at 9:44 am
It takes the fun out of creativity doesn’t?
September 17th, 2008 at 10:13 am
The hardest thing is finding a project that is actually useful and interesting and at my skill level that some else hasn’t already done to death.
Reading documentation is certainly hard, especially those web-frameworks because I spend the whole time wondering why they built such a huge and complex system to solve such a small problem.
September 17th, 2008 at 10:16 am
I’ve always “tweaked” code where possible - saves a lot of time in the end.
September 17th, 2008 at 11:01 am
When I program in ruby, and I look around, then the chances are high that NOONE else did what I wanted to do as of yet.
And I cant just go and use C because I would have to write a wrapper, which forces me to understand what that other guy did (and it takes a lot longer the larger the C app/lib in question)
So how can your point be correct in this regard, even “creativity” taken aside? There simply are a few bottle necks one can never overcome, i.e. on Linux. Right now everyone has to use the modular xorg solution which is the common base. And you write as if that other solution is indeed always better.
I doubt this strongly. :)
September 17th, 2008 at 11:37 am
“Most of the time, someone has done it better”… and 10,000 people have done it the wrong way. Finding the right library, adapted to your problem, programmed correctly, and with the right license, is unfortunately time-consuming.
Is it worth it? Depends of your situation. Programming for fun, or trying to find the cheapest way to make and release a commercial product, probably bring very different answers to that question.
September 17th, 2008 at 12:14 pm
I disagree, the fact that someone out there has written the library, framework, tool that already does what I want just makes programming easier. Yes, I have to make an effort to read documentation, sometimes source code, and actually figure out how to use these things, but generally that effort is not that big for the pay off if the documentation is decent, the library/framework has a decent API, and isn’t riddled with bugs. Eventually you get good at avoiding the bad ones or the ones that don’t fit your needs.
Though I suppose this varies depending on what language/platform you are using. Some languages/platforms are almost completely devoid of any good 3rd party solutions.
Sometimes it *is* just better to roll your own.
September 17th, 2008 at 12:30 pm
The hardest thing in programming?
Figuring out what someone else wants.
Let me say this again:
“Figuring out what someone else wants.”
September 17th, 2008 at 12:41 pm
Have you read the documentation that is out there? Apparently writing documentation is similarly difficult to reading it.
September 17th, 2008 at 1:00 pm
[...] Lo más difícil de la programación no es programar. Informatica, Programacion, minipost Deja un Comentario [...]
September 17th, 2008 at 1:20 pm
Excellent post. Though I do enjoy making my own wheels. There used to be a trade called wheelwrights. Their job was to make wheels. Someone has to make the wheels. You are not reinventing the wheel if you are making your own wheel.
September 17th, 2008 at 2:24 pm
Off-topic, but… what’s so difficult about currying?
September 17th, 2008 at 2:53 pm
Most of the time if I hear someone say “Everything has been done before” I’d cry foul and tell them we are in our infancy of thought and innovation.
But, in this case you are right on the money. I think the web will eventually move over to something like Objective-J where all of the widgets are encapsulated in code to let us reuse all of the same crap everyone has done before (validation, passing variables, etc etc etc). Sometimes finding what has done before will lead you into very simple code and an include, and sometimes what is out there is crap, but it leads you to a better way of thinking about it. Caveats are sometimes obvious when it is not your code. Communicate with yourself. You are not the only one doing what you are doing.
September 17th, 2008 at 3:01 pm
markus, if theres no code available to reuse then maybe you’re using the wrong language?
September 17th, 2008 at 3:28 pm
The same hardest problem appears when you write scientific papers, or when you invent something - actually, it happens every day. Just think of how many times the wheel has been invented… And that is only because someone did not know about it.
On the other hand, it is much easier and fancy to think the solution yourself than to get into someone else’s mind and finally find out that his solution does not exactly solve your problem…
If you start looking into others’ solutions you may get swamped in their thinking and lose your perspective, your vision on your particular problem.
On the third hand though, you may learn new tricks that will widen your point of view to a horizon and show you that your problem was incorrectly (poorly, narrowly) defined…
September 17th, 2008 at 4:23 pm
[...] By Adan Bard [...]
September 17th, 2008 at 4:42 pm
How about WRITING documentation….? I’ve been doing this for nearly 20 years and can count on one hand the number of people who actual DOCUMENT what they do…
September 17th, 2008 at 5:36 pm
“Figuring out what someone else wants”
NO!!!
The hardest thing is “Figuring out what someone else NEEDS”
September 17th, 2008 at 6:11 pm
Good truth. Most of what I have learned comes from dissecting existing programming (viva la open source). I often work with Drupal as my CMS with a frankenstein of what I want to see but Drupal ain’t got. I aim to NOT poke at the core so I can update and even migrate to another CMS and/or platform.
All my fanciness is placed on top of other programs. Most of the time is seems that the web needs a good CMS that also has Unique Application X. Well, X may or may not be written. That is where the money is…
–Nahtass
September 17th, 2008 at 6:14 pm
BAH how exceedingly boring. Can you imagine how stale the world would be if all the Walter Bright’s of the world had said “fuck it, no one needs a cleaned up 21st century C++, let em use .NET and Java, D can die”? What if Jeff Bonwick had said “screw it, RAID is good enough, who needs consistency checking or checkpointing, ZFS can go die”? These paths are all ruin; cs would rot and decay and wither away without people constantly drawing from the most select and best pieces of the past to build new things.
The hardest and best part about CS is studying what people have done, finding the limitations and potentials- minima and maximas- and distilling out the best and most practical essences of each idea, then smashing them together in high energy late night experiments. Yes it involves your chief suggestion of long long hours reading citeseer and source code; the difference is that you take fistfuls of the old and attempt to build something radically new and better.
Of course in 97% of cases you are right, but I’ll take that 3% of hard sweat and highly kinetic work any day.
September 17th, 2008 at 8:07 pm
Seems obvious that the hardest thing in programming is documentation. Think about it. Would it be so hard to use someone else’s code if they provided easily understood, even interesting, documentation? A lot of people use Word and Excel. How many people use it at an advanced level? The documentation for these products makes that difficult. Thank goodness for a decent user interface.
All the programmers, I’ve known have lobbied either me or other supervisors for a technical writer. Why? Documentation is hard. It’s tedious and if you leave it for last, it’s anti-climatic.
Creating clear, concise, usable documentation is a part of programming. That is truly the hardest thing in programming.
September 17th, 2008 at 10:56 pm
You’re all right!
For me though the hardest thing is trying to partisipate in community opensource. The flood of emails alone takes at least an hour a week.
September 18th, 2008 at 9:32 am
Quote all
September 22nd, 2008 at 7:00 pm
I agree with you 99%!
as to that 1%, one must be careful when saying such words not to be too convincing! :)))
Thank God there are dreamers (far less than 1% of us, and that is quite bad!) who do not listen to such words and write their OS, language or design a new paradigm… thanks to them, we have blogs to write to, languages to play with and this curry stuff that some people love and others do not really get ;)