• Harry Johnston (google)

    I'm just baffled by the suggestion that learning a written language is easy. It takes years to learn your native language, and that's when you're a child and don't have all that much else to do. And most adults struggle to learn a second language, and in many cases never speak it well, even if they can make themselves understood. That's not enough to count as hard?

  • Lerch98 (unregistered) in reply to Brian Boorman

    That could start a bar fight.

  • Nate West (google)

    It's worse than you say. Fundamentally, coding is 'easy', it's System Design and Integration is hard. Banging out a little javascript to make the cat picture and the hat picture sit on top of each other is easy. Any 'coder' can crank out Joe Bob Fortune 500 website/integration/database/etc code in the language of the week. What pretty much all coders fail at is seeing the bigger picture - making sure their work plays well with others.

    An interesting example of coders failing to see the bigger picture is the explosion of the Ariane 5 rocket in 1996. Someone tried to convert a 64 bit floating point to a 16 bit integer. The number was to big to fit in a 16 bit integer, so 37 seconds into flight, all guidance and altitude information was lost. In a system where pretty much every developer has exception handling and testing banged into their heads, failure still happens on a regular basis. NASA, of course, had the biggie with the Mars Climate Orbiter in 1999 as well. Lockheed used English units but the JPL systems were expecting metric, so we have a hunk of metal orbiting the Sun now instead of Mars. Also the patriot missile battery that had some rounding errors that resulted in a 0.5 second delay, thus failing to intercept an Iraqi Scud in Desert Storm. And countless other lives lost due to system failure.

    One other comment. You mentioned that coders are expected to worth with structured data. We now have a whole industry trying to convince people that there is such a thing as 'unstructured data'.

  • Norman Diamond (unregistered)

    For all that discussion of easy vs. hard, this article didn't have an "Easy Reader Version". I'm disappointed!

    Writing WTF articles is hard.

    Writing Easy Reader Versions is harder.

    [* OK, writing WTF articles isn't necessarily hard, but writing good WTF articles is hard.]

  • Norman Diamond (unregistered)

    My boss said, "The job's not meant to be easy. If it was easy we'd get girls in to do it."

    Did you show him these? https://en.wikipedia.org/wiki/Grace_Hopper https://www.wired.com/2015/10/margaret-hamilton-nasa-apollo/

  • Norman Diamond (unregistered)

    I remember in my first C++ class, I spent days—literal days— hunting for a semicolon.

    This is too little, too late; but here, have one on me.

    By the way sometimes I need an IDE that doesn't just force all my assignments and computations of values to put in SCSI control blocks to be valid commands, but to also be correct commands for what actually needs to be done at that point. By the way Microsoft sometimes needs the same.

    (It doesn't have to be SCSI. An IDE to do IDE right would be awesome.)

  • Big Jesus Trash Can (unregistered)

    One of my comp-sci lecturers gave us a bunch of sayings, the most pertinent of which is:

    Good judgement comes from Experience. Experience comes from bad judgement.

  • Greggy (unregistered) in reply to Bert

    Unfamiliar with this platform, not sure if the message I'm replying to will be quoted. So, "Typing code is not hard. Solving problems is hard."

    Year ago our CEO visited engineering during a particularly stressful march to ship. He complimented our manager for all of our work "programming". He then immediately frowned and said, "I don't see a lot of people at their keyboards this afternoon." Having no filter I piped up with, "That's what typing looks like. This is what programming looks like," sweeping my arm around the common area full of engineers.

  • Teemu (unregistered)

    The Reddit quote is full of nonsense. Learning the language is easy, doing something with it is hard. Just like how if you know a written language doesn't automatically make you a writer.

  • GrahamK (unregistered) in reply to D-Coder

    "If it were that easy, fewer people whose full-time job is programming would make such a hash of it!" ;-)

  • poniponiponi (unregistered)

    TRWTF is people buying an entire separate "balance bike" instead of just taking the cranks and chain off a regular one.

  • Dave (unregistered) in reply to Mike McCarthy

    is this because you hate them?

  • (nodebb) in reply to DavidO

    Assembly language is more intricate and fine-grained than higher-level languages, for sure, but remember my basic premise: the hard part of programming is NOT writing the code. The hard part is deciding what to write, that is, thinking about what you are trying to produce and putting together a schema for it.

    Aside on programming languages: I once saw an assertion (backed by some research) that code production, measured in SLoC (Source Lines of Code) per day, is approximately independent of the language in use. That, ultimately, is why we prefer higher-level languages, because each SLoC written in them does more than a SLoC written in a lower-but-still-high-level language like C, which in turn does more than a SLoC written in assembler. (Example: a = b + c; is one line in C, C++, etc., but would normally be expected to take at least three lines in most assembly languages.)

    I'm not afraid of writing GUI programs in assembly, but I avoid it on the grounds that I'll get the code written sooner if I write it in C or C++ or C# or whatever. x86 assembly is relatively pleasant to work with (especially compared to Z-80 or 6809 or, worse, 68HC11 or 6502, all of which I've used in the past), even if it doesn't have an equivalent to the EDIT instruction of IBM System/360 mainframes.

  • Discouraged (unregistered)

    Programming (well) is hard. It's reducing a complex system to tiny simple pieces, then reassembling them, but in such a way that there is enough flexibility to handle the inevitable change requests.

    At the same time, there are easier parts - I believe UI is easier (yeah, I'm mostly not a UI coder), but tedious.

    I have coded extensively in assembly language, including writing GUIs - it's no harder than doing it in a high level language, but there is more tedium :-)

    The comment the article mentioned is symptomatic of someone who has never really coded - maybe took an intro class, concluded "oh, this is easy", and is now spreading that attitude. Not someone to get worked up over (unless they are in management!).

  • Developer Dude (google) in reply to Nate West

    Nate West: I would say that your example is more about the details and fundamentals than the "big picture", but is a good example of how small details can affect the big picture.

    I have worked with developers who can do one or the other, but not both - devs who can get the details right, but not grok the big picture issues of architecture/design/integration, and devs who understand those big picture issues, but do not bother with the small details such as checking for a null reference, converting from one data type to another, checking for valid states/args, and so on.

    And then there are those who can do either one.

    I.E., thinking about and properly implementing both small details and big picture issues is part of the difficulty of creating any system, not just software.

  • Mike a Person (unregistered)

    Programming is hard. And so is designing hardware in programming languages like Verilog or VHDL.

    It can be made a lot harder if you come from a team and environment where a loud three day argument about the architecture of a completely new sub-system in a Linux kernel would result in a successful development of the product, and the documentation was mostly 'we will make an XYZ'. The team motto was JFDI .. Just F... Do It. And we turned out several successes.

    Now when I have to write a specification to guide other people I find it hard to understand that they dont understand the problem as well as I do. So they fail because I dont tell them how to do it, just what I want. So I fail too.

    Recently after three people failed to even understand what it was they were supposed to be creating because it did not exist off the shelf, I had to create the software myself. And because I am me , it was full of bugs and took ages to fix because it was hard to get right.

  • Old Fart (unregistered) in reply to dkf

    I'd consider the restrictivity you mention a blessing, they are there to protect the innocent from walking astray.

    Tools? FFS, just throw more code at the problem.

    David J. Wheeler: "We can solve any problem by introducing an extra level of indirection"

  • Hugo (unregistered)

    Interesting read, thanks!

    Your list of things to keep in mind, and especially the first, makes me wonder how much designers of programming tools could learn from game designers? Almost every game I ever played that has a complexity level beyond "point and click/shoot at everything that moves" comes with a tutorial mode. They often start by forcing the player to do exactly as told, but at some point start giving more freedom without immediately making all options available. Should we start to gamify the world of programming?

  • ATF (unregistered) in reply to Brian Boorman

    Yea.. totally agree! The chalk board Einstein used to write equations on was the REAL winner, not the mathematical equations he used. Or perhaps it was the pencil? Either way, that hardware sits there doing nothing without a software engineer. Even the firmware is coded. Hell, this is why the finger print company tanked and had to be bought out by Apple. They were Hardware engineers that couldn't write software to save their lives (er, their companies life that is.)

  • ATF (unregistered) in reply to Teemu

    More to the point he mentions Javascript along with VB and PHP. Has he checked the recent usage of Javacsript/ECMScript? The speed in which it executes, business value can be created in, and the speed in which the standard is evolving? As someone else mentioned, it's becoming less about the language and more about what we can offer in terms of functionality. What can that piece of code DO. Esoteric code for the sake of being complicated is no longer cool.

    The whole being able to read and write a language used to communicate ideas amongst humans is NOT at all the same as a language used to communicate to a machine. A writer misplacing a comma in their Best Seller is not going to cause a banking application to crash and for a large Fortune 100 company to lose millions. The same can't be said for a computer program.

    Comparing human to human languages with human to machine languages is not logical. Humans are able to infer, guess, adapt, and internally translate what another human is trying to say. And we get it WRONG most of the time anyways. A computer only does exactly what it's told to do. This is what makes it hard. It takes a certain mindset to code properly.

    I'll take the giant leap in saying that Software Development is less about being HARD, then it is about having the capacity to do it in the first place. This is not a skill that anyone can pick up. Not everyone can sing, or play a musical instrument. The correlation is that we are pumping out tons of 'software developers' that have no business being a developer. Yet, we live in a world where everyone can be anything. But that's just not true. Could you all imagine what would happen if Software 'Engineers' had the same liability as Civil Engineers? You write crappy code; you get sued or go to jail. It would change the landscape.

    The Reddit poster is correct. Programming is not hard. It's actually quite easy. Programming something that is easily maintained, efficient, easy to understand by others, secure, performant, scalable AND concise is HARD. This is the root of the issue. There is a difference between doing something and doing something well. Programming well is hard.

  • FRED (unregistered)

    Learning English takes about 15 years. You do, of course, continue to learn English all your life, but after 15-18 years it ceases to be obvious that you are still missing words and constructs.

    Apart from that, the idea that learning C syntax makes you a better programmer, or makes you a better programer faster, or makes you a programmer faster, is the same kind of self-interested, self-indulgent, vain, conceited, cocky, narcissistic attitude that, in my personall knowledge, programmers have been known for over the last 45 years.

  • Phallus (unregistered)

    Programming is hard .... and so is my Phallus

  • T (unregistered)

    The hard part of programming shouldn't be syntax; that's the "pedaling problem" the bike article called out. What's hard about programming is making explicit all the implicit things your brain does when thinking through a problem: Which pieces of information do I need, and when? What do I do if I can't find the answer to question ___? What if my attempt to mail this letter fails?

    Visual languages and forgiving languages help people iteratively develop that sense. Programmers in their early days are rightfully fine with programs that crash at the first sign of trouble; even experienced programmers are fine with that for programs that won't see long-term use.

  • MIckey (unregistered)

    Software is hard, hardware is harder. You can't redesign hardware in the field, but software is forgiving if you take the time. Worst case - hand it over to someone that knows 'what' you're doing, and has the skills to develop what you 'want'. Both are challenging and require skills!

  • Tim (unregistered)

    "Here’s the problem, though: once you understand how to think syntactically, syntax itself isn’t really a bother..."

    I've been programming for over 30 years, and have used over a dozen languages professionally. When does syntax stop being a bother?

    Some languages are just more complex than others, often for dumb historical reasons. It doesn't just go away. C++ in particular is notorious for being difficult to parse.

  • (nodebb)

    cool

    Addendum 2024-04-28 18:57: Through a specialized online platform, I found a team of expert software developers who turned my concept into a reality. Their professionalism and dedication were evident from the start, and they consistently Glow Team delivered high-quality updates and improvements. The end result was a sophisticated piece of software tailored exactly to my needs. I am thrilled with their work and would encourage anyone needing custom software to consider this talented team.

Leave a comment on “Programming is Hard”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article