• Frist! (unregistered)

    Frist is hard!!

  • Kiwi (unregistered)

    First up, I'm not a programmer so take what I say with a pinch of salt. I reckon programming is hard because thinking is hard, well, thinking clearly and logically is hard. Humans haven't evolved to use that mode of thinking most of the time, it's there as a stand by for the usual 'quick thinking' that works more or less most of the time. Check out Thinking, Fast and Slow by Daniel Kahneman if you get time.

    Cheers

  • Mike McCarthy (unregistered)

    Nice post. I'll be sharing it with the other developers I work with as well as my wife who is trying to become a writer.

  • Dave (unregistered)

    "Little did I know that training wheels are considered harmful."

    That article was just nonsense, though, from someone who doesn't understand how to fit stabilisers correctly. They're supposed to both be off the ground when the bike is upright, and the bike should be able to lean 30-40 degrees to either side before the extra wheel on that side contacts the ground: they're just there to stop the bike and rider toppling over altogether.

    All too often you see stabilisers set up so that the rear wheel and both stabilisers are in contact with the ground at the same time, and that does indeed create some weird, oddly-handling quadricycle which won't teach balance.

  • Tom (unregistered)

    This is strong opinionated from a coder's perspective. As one myself I fully agree with the statement that learning to learn is key in becoming a programmer, however it isn't if that's not your career. The modern day artisans use whatever "simple" script works because we're at a point where the code itself is vastly less important than the increasing far-reaching function these scrips can perform.

  • (nodebb) in reply to Dave

    All too often you see stabilisers set up so that the rear wheel and both stabilisers are in contact with the ground at the same time, and that does indeed create some weird, oddly-handling quadricycle which won't teach balance.

    And go over a small indentation in the ground or a crack in the concrete where the bike gets stuck. I made that mistake with my eldest child's bike but quickly fixed it, but now he rides around without them at all.

  • Paul M (unregistered)

    I agree with the points that tools can constrain the developer and make some code constructs very hard or impossible.

    I recall a colleague building an windows program using a toolkit which had drag and drop and made producing a forms interface very easy. He managed to build 80% of the program very quickly, in an impressively short period of time. However, once he started to add more advanced features he ended up spending more time working round the limits of the tool than actually writing the features. The number of problems and bugs escalated quickly, partly because he was using little-used features which were poorly documents and buggy, or having to make calls to native windows libraries. Progress slowed to a crawl. I don't think he ever finished more than 90% of the features before it was shipped as being good enough.

  • (nodebb)

    Remy's basic premise is correct. Programming is hard.(1)

    However, none of the things he talked about, except sort of sideways in passing, are why it is hard, or, more accurately, what it is about programming that makes it hard.

    It isn't hard because C++ has complex and occasionally ambiguous or unobvious syntax, or because C has only raw pointers, or because Java and C# do different things in a few corner cases despite their apparent similarity, or ..., but none of those things help to mitigate the difficulty.

    No, it is hard because despite(2) the flexibility and adaptability of the medium (code), it is hard to convert the wishes of the would-be user into a design (not the code). That is a thinking task, not a construction task. It is easy to convert a well-done design into code, but it is hard to convert even a well-expressed wish (something someone wants) into a well-done design.

    (1) Many moons ago, 1988 if memory serves, I wrote a similar sentence on a term paper for a 400-level college course coyly titled "Software Engineering". In that case, the statement was, "Software Engineering is hard," and after introducing the paper with those words, I proceeded to refuse to answer the question the paper was supposed to answer. Instead, I explained why I wasn't going to answer it, and proposed and answered what I asserted was a better question.

    I got an A.

    (No, don't ask me to recall the two questions. It was nearly 30 years ago, FFS!)

    (2) That should say, "because of," not, "despite," of course. We build our software castles on nothing so substantial as air, from the most flexible and adaptable medium known to Man.

  • Mike Shawaluk (google)

    As I was reading the article, I expected the author to call out ReSharper as one of the "bad tools" that attempts to make programming "easier". I appreciate that tool, as well as the features of Visual Studio that automatically indent my code as I type it, because I think that properly formatted code is easier for others to understand (including me 6 months later).

  • Bert (unregistered)

    Typing code is not hard. Solving problems is hard. The latter is what software developers are paid for. The former is just the means to an end.

  • Brian Boorman (google)

    If software was hard, it would be called hardware. But it's not called that. Therefore, it must be easy. That also means that us hardware engineers are smarter than you software people.

  • Howard Richards (google)

    Programming isn't hard. Programming well is hard.

  • Church (unregistered) in reply to Brian Boorman

    I lol'd. That is a good one that I haven't heard before.

  • Pjrz (unregistered) in reply to Brian Boorman

    Hence the old joke about the number of software engineers it takes to change a light-bulb

  • (nodebb)

    I like this article. I like it a lot.

    The reason for really wanting the tools that look much like training wheels is that they can sometimes bring higher-level problems within grasp. Writing a GUI program in assembler certainly is possible, but you'd go probably crazy trying to do it. You could use C to write the whole of an enterprise web software stack, but it's just a monumentally poor choice nonetheless. Having more restrictive tools makes it possible to take on the larger tasks, and this is because there's simply a limit to how much anyone can really think of at once.

    I prefer my tools to be simple things that I can mix together in creative ways.

  • (nodebb) in reply to Brian Boorman

    Okay, I'll feed the troll, but only because there's a valid point to be made. As an electrical engineer with over 30 years experience designing and developing embedded real-time firmware, I have lost count of the times I've been called upon to perform the miracle of twisting the firmware in order to make up for lazy or thoughtless or stupid hardware design. So go on, Brian, go create yet another opportunity for a software developer to be a hero.

  • Angela Anuszewski (google)

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

  • Angela Anuszewski (google) in reply to RogerC

    Where I work, "embedded real-time firmware" devs are in our Processing Technologies organization... with all the other software engineers.

    P.S. Brian and I used to work at the same place until about 12 years ago, but I can't remember if he made any of those opportunities for me or not. :)

  • Sham (unregistered)

    TRWTF is Reddit.

  • jj (unregistered)

    As an absolute nooby learning to code, with some (what should be simple) but slightly grand plans for my level, I have to say it feels more like trying to ride a bike that has been welded at every joint. It just doesn't move. I cannot find the one problem as there are so many at once. Its highly frustrating.

  • Vilx- (unregistered)

    Yes, programming is hard, but I'm not sure it's the right answer...

    A little over a year ago my father asked me how long it would take to learn programming. I was ecstatic to hear that question. He was well qualified to start learning, being a technically minded person already. He has a higher education in radio electronics, and had worked first as a hardware technician at a TV station, then spent 10 years installing security systems, and then another 10 years repairing electronic construction equipment (think laser levels and the like). On top of that, his then workplace was... one that I wish he had the courage to leave (side note: he did eventually, and is now much better off because of it).

    So, you can imagine my excitement when I saw that he was actually seriously considering trying his hand out at computer programming. I knew it was going to be a long road, but wanted to encourage him and help him whichever way I could. He was still young enough to make something of a career out of it. Perhaps we could even end up being colleagues one day!

    So I tried to be smart and honest and straightforward about it. "10 years" I answered with my most encouraging smile. And said something about it being like chess (you can learn the moves in an afternoon, and then spend years honing your skills), and any skill taking 10 years to become an expert, etc.

    The light of excitement went out of his eyes. "Oh." he said. And at that point I realized my mistake, but it was already too late. My father never again considered trying to program computers.

    In retrospect, I think the correct answer would have been something like "I can show you the ropes in a few afternoons, and then you can start writing useful stuff in a few months. From there it's just honing your skills and gathering experience. :)" Perhaps this isn't entirely truthful, but not far from it either. And it's a heck of a lot less discouraging.

    So, yes - programming is hard - but take care not to discourage people with this truth.

  • FennNaten (unregistered)

    Programming in the sense "translating thoughts directly to syntax with rough understanding of variables, loops and conditions" is not hard. However that's not what programming is. Factor in understanding types. Specialized data structure. Understanding memory. Understanding network. Understanding your platform. Your tools. What about security graphics? Is your code secure? And now all that, but with a client whose needs you have to satisfy with your programming. Which must be maintainable by others. And automated, configurable, scalable, available...

    This shit is hard. Anyone can play with some code in the integrated interpreter of a tutorial, and quickly make fun things. Doing this stuff professionally? That's when you get in trouble. Saying it's easy gives a wrong idea to beginners and is harmful for the whole field.

  • w (unregistered) in reply to Dave

    30 to 40 degrees is a bit much though. If you let the bike lean 30 degrees before the training wheel touches the ground it will topple anyway, and in a much more uncontrollable way than without the training wheel.

    For them to work they need to be just above the level of touching the ground in normal cycling. Which means you(r child) will have a nasty fall on the first sharp turn.

    Alltogether training wheels don't actually work that well. They mainly have a psychological function of letting the learner think they won't fall, which is half of what is needed to actually not fall.

  • erk (unregistered)

    Many years ago I was struggling with some intractable bug. My boss said, "The job's not meant to be easy. If it was easy we'd get girls in to do it."

  • D-Coder (unregistered) in reply to erk

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

    Eep.

    I usually say, "If this were easy, the customers would do it."

  • Carl Witthoft (google)

    Maybe a more accurate, and simpler analogy is: Writing sentences is easy (ish). Writing a great novel is very hard.

  • flower (unregistered)

    The real reason you need training wheels is that small children starting to ride don't move fast. The faster the bike moves, the more stability you get from the wheels acting like gyroscopes - it's significantly harder to balance on a slow moving bike. The training wheels keep you upright through the really unstable part while you're learning how to make it go fast (and how to get your feet on and off the pedals quickly when you slow down and start up). Big kids get the pedaling thing quickly and start moving fast right away - therefore they don't need the training wheels.

  • Bubba (unregistered)

    Nice article! I broadly agree with the general thrust of this article, but I do think it deserves deeper analysis.

    What does "hard" mean in this context? This is a critical factor to focus on that I was glad to see being tackled here.

    Learning the keywords and syntax and general hieroglyphic nature of a programming language is a challenge on par with learning a foreign language - easy to learn the first bunch of common words/phrases and thereby express simple things, but requires continued study to progress deeper, to finesse the accent and nuance of vernacular, to be able to express complex ideas and engage in fluent communication.

    Once fluent, however, if you are an idiot, you will only ever say idiot things.

    This is where I consider the "hard" part of programming lies - it isn't really the programming per se, it's the intellectual gold behind it that is the true challenge to mine. If you don't have the right intellectual toolkit, you'll have a hard time mining anything more than dust...the real motherlode is discovered by truly smart people - powerful thinkers.

    That's what is hard. Guidance and practice can reveal more of your intellectual toolkit than you realized you possessed, but ultimately you're going to run into the brick wall of your IQ.

  • Nate Scherer (google) in reply to Dave

    If the bike is leaning at 30 degrees and not turning, it will be almost impossible to stay on it, with or without training wheels - even if the bike itself doesn't tip over. So if you're doing to do it that way don't even bother with them.

  • HearHear (unregistered)

    Sometimes we forget how much we know. A couple years ago I was working from home and my teen son, who we've taught some Python and some Java, looked over my shoulder at my embedded C code (bare metal) and was curious. I thought it wouldn't be to hard to explain it to him, but the very concept of a non-OO language blew his mind, and there were many other aspects I didn't think twice about until trying to explain them.

    Now I'm a team lead for a product that employs real time embedded C on a microcontroller, higher level OO code and web technologies on Linux, and a web portal on "the cloud". Management doesn't have a software background. It's a bit freeing because it's up to us to decide what and how to do stuff. However, I have to keep them from expecting us to be able to do anything in less than a week. I find myself simultaneously wanting them to understand how hard it is, and not to make them so scared of software that we're not allowed to do the things we know we need to do.

    I also have to contend with management's urge to hire inexperienced (cheaper) people, into a tiny team that can't afford that. Invariably we put together the job requirements, open to hiring any younger person who could meet them, and find ourselves hiring experience.

  • Carl Witthoft (google) in reply to flower

    That's a long-standing Bad Science mistake. If the wheels' gyroscopic effect were significant, you'd be unable to turn. The reason moving faster keeps you upright is that you learn to steer minutely towards the side you're falling, and centripetal/centrifugal force straightens you up.
    You can look it up :-)

  • isthisunique (unregistered)

    In my book a few things in particular come to the fore. To be a good programmer requires:

    • Caring about the quality of your work in general to the right extent for each concern.
    • Good organisation skill and good language skill in general for whichever written language you code in. There's a big advantage for English speakers.
    • Good cleanfreak skills. Remove things when no longer necessary, etc. Natural garbage collectors don't let cruft build up until it is unmanageable. They remove all distractions, etc.
    • Reasonable level of general intelligence. Strong mathematical, systematic and logical intelligence.
    • Both ability to pay attention to detail and to filter out irrelevant details. Reasonable ability to abstract.
    • Strong level of introspection and self awareness.

    you're going to run into the brick wall of your IQ.

    I just call this the ceiling. It really exists and I have experienced it first hand. You can only afford so many average IQ software developers working on a team. Some projects are more tolerant than others but generally if you don't stack the deck with high IQ sufficiently there's going to be a lot of work that average IQ just can't do. You'll have one or two high IQ software developers basically doing 90% of the work. A lot of people would think you need one smart leader then the rest can follow but it's not really so for software development. The average task is of moderately high complexity especially if it is to be done right. There's often no way for the high IQ developers to break it down without it just being quicker for them to do themselves. This happens to me when delegating. I still give people work even if it would be much more efficient for me to just do it. Otherwise I bottleneck and they aren't going to get faster. Some people pick up a lot of speed over time but others are stuck in first or second gear. There's no higher gear. I've trained a lot of people and seen people develop over the course of years. You don't get the same result giving everyone equal training.

  • AProgrammer (unregistered)

    I've never met a hard programming problem, neither have my siblings. Programming is as hard as using a hammer, but not everyone naturally understand how a hammer works and holds them wrong, to others it is obvious which end to hold. Before you criticize me or my siblings, we've all have gotten special accommodations at school because normal programming classes were a joke to us. None of use spent almost any time practicing programming, we just naturally found it easy. What we have been practicing is logic. Our family is very witty and we've held reason and practicality above all else.

    My one brother is heading up 6 different research projects and complains everyone else slows him down, helping our university redesign their datacenter, has special accommodations to have his own servers in the datacenter to play with, is second in command for network security administration for the campus, and in the first time in 50+ years that the school has specialized in super-computers, he was given exclusive access to do AI research on their newest super computers, and he's only a freshman, priority even above tenure professors. He's more ambitious than us, but we're mentally his peers.

    I like talking to my siblings, we bounce all kinds of ideas off of each other. We're all in danger of being overly negative people because we can't trust the logic of most others. Our mother only has a high school education and is a secretary. She taught us how to think. This one time my siblings and I were discussing a massive geo-distributed problem that other people at work were having problems grasping. These were "specialists" that did not understand their own domain problem domain. Our mother thought the conversation sounded interesting and joined in. She had more constructive ideas than those so-called "specialists".

    There are not many fundamentally hard problems, mostly just problems made unnecessarily hard by convoluted thinking. Time is a fundamentally hard problem, which ironically most programmers don't think so. What I think is easy, other things is hard, what I think is hard, others think is easy. Funny how that works.

  • Developer Dude (unregistered)

    Saying that you can learning how to program is as easy as learning a foreign language is like saying learning how make music is as easy as learning how to read sheet music.

    I.E., it is one thing understanding the syntax/semantics, it is a whole different thing knowing how to properly use a programming language to solve problems in an efficient, understandable and maintainable manner. And learning new tech just muddies the water (not that it isn't good, but master what you use first before moving on to something new)

    I've been developing software for almost 3 decades and while I consider myself proficient, I don't consider myself a "master/expert/etc.". I do know bad programming when I see it, and I see a whole lot of it written by people who think they know how to program.

  • Bubba (unregistered)

    Well...if BLAKEYRAT says so, then it must be true.

    Delete the site immediately, and find more reputable avenues for employment.

    BEGONE VILE SITE!!!

  • Bubba (unregistered) in reply to Developer Dude

    @Developer Dude - No...I said that learning the programming language is much like learning a foreign language. The rest of my comment basically agrees with the rest of yours :)

  • isthisunique (unregistered) in reply to AProgrammer

    Time is a fundamentally hard problem, which ironically most programmers don't think so.

    That's a crucial element for anyone in the above average intelligent and capability category. This is a problem I have. I can do everything and fairly well. Even a lot of genuinely hard problems but time is a major issue as is finding others with the same scope of capabilities. Any developer who doesn't recognise the time issue either has too much of it, too little to do or lacks introspection. It's not that hard to see a backlog forming or a list of extras you would like to implement but can't. When everything reaches the level that you can only spend time on bare essentials then that really sucks.

    You can have huge swathes of programming that really isn't complex. Setting up networks and things like that really takes more time researching than thinking because a lot of it has been done before. Saying that, there's a lie in that. You can't do too much by rote. Most things require you actually understand.

    I have to disagree that programming is like using a hammer. In a sense it is, but it's more like using an entire tool shed. A hammer is far more limited in scope. It's not a one simple trick to get programming right. It's several hundred simple tricks. A lot of people can't actually handle that.

  • Herby (unregistered)

    It really isn't that programming is "hard" (it is in many respects), it is that thinking in a coherent way is "VERY HARD". Thinking is a life skill, and to think in a coherent way takes a lot of work. I suspect that many of us are able to think in a somewhat coherent way, and the many WTFs we see here are due to just not thinking things through. How many times have you said to yourself "What was he thinking" when you see a WTF here.

    Yes, many occupations have the need for coherent thinking, not just ours. It is that our thinking is a bit different than others (yes, a lawyer thinks differently than a programmer).

    Training wheels. Yes, I remember them over a half century ago. In our neighborhood we had "soft" street gutters that had curves leading up to the sidewalks. With training wheels, you could position the back tire to be free wheeling and in the water at the same time. Then pedaling like mad would kick up a big rooster tail of water. It was a lot of fun. It was a single speed bike with something like 20 inch wheels. Just about right for a 5 year old. Boy was that a long time ago!!

  • (nodebb)

    Either Jeff is back for revenge, or someone who's mess got featured here is really salty

  • Brian Boorman (google) in reply to RogerC

    Well Roger, since lately I've been both the HW and FW person on projects, if I make stupid electrical mistakes, it is only myself I am kicking on the firmware side. But not everything EE has a micro on it either. No amount of software would fix my latest buck-boost switcher with Li-Ion charger hardware.

    And I don't recall any times Angela had to rescue me, but I still have emails from circa 2000 where I made FPGA changes so her software could continue to send deprecated control messages to my hardware.

  • DavidO (unregistered) in reply to Steve_The_Cynic

    Remy's basic premise 'Programming is hard' is correct, but almost everything is hard if you do not have the correct tools, knowledge, or temperament.

    As an engineering student in the 80s, we had to take an assembly language programming course. Base on Remy's article, this programming language is very powerful and flexible. I do not see the masses of professional programmers flocking to this language. It too hard!

    To me, being a teacher, police officer, or nurse, would be hard. I'm not sure a 55 year old nurse would see her job as harder then an IT professionals. Hard, like beauty, is in the eye of the beholder.

  • Developer Dude (unregistered) in reply to Bubba

    I was referring to the comment in the article: "If you learned a written language, you can learn a computer language. "

  • Lazerbaems (unregistered)

    Nice article but I don't think "gud" is a valid git command

  • Developer Dude (unregistered)

    You know what is boring?

    Trolls.

    Trolls are boring.

    Trolls put me to sleep.

    Trolls put me into a coma.

    Especially trolls that say something is boring as if we should care that the troll is bored

  • Ulysses (unregistered)

    Remy says garbage collection is a good thing, yet it commits sins criticized in this article, and worse. It provides the illusion of no cleanup; meanwhile, you have to manually release other types of resources.

  • Ron Fox (google)

    Programming seems easy because once people start learning one way to do it .. a language... a technique... a buzzword... the Dunning-Krueger effect has the ability to take a foothold. Programming is hard because it's not linguistic mastery. It's the ability to build logical, extensible, understandable problem solving structures. The linguistic part is 'just' how those structures are represented in a manner a computer can mechanically execute.

  • Angela Anuszewski (google) in reply to Brian Boorman

    Maybe I would have changed my messages if you kept your IDD up to date. ;-)

  • Developer Dude (google) in reply to Steve_The_Cynic

    Very good points

    To divert just a little (I hope) whenever someone (usually uninformed about software much less about AI) as to how "robots" (i.e., AI) will "replace us" (take our jobs, etc.) and do this, that and the other thing, I pull out my favorite response; the one thing that you would think AI should find easy to do, write software, is actually the one thing it has failed at doing for decades. You would think it would be easy because software eventually is transformed in to explicit instructions that a computer can understand unambiguously. So it should be able to create that right?

    Wrong.

    Some human still has to explain the problem and requirements to the computer in some form, and right now, that is us - software engineers, and the form is a programming language. While the languages make improvements over time, it is a very slow and tortuous process, and for the foreseeable future will involve humans. I will probably be dead and my ashes scattered before AI can replace me or my successors.

    In short, if we can't "do" software right most of the time, how are we going to create AI that can "do" it right?

  • Developer Dude (google) in reply to Vilx-

    I have hired people right out of college that "got it" and all they really needed was time and more experience to become senior developers, but they were of value as they were.

    I have hired people who had years of experience where I had to review each line of their code after their checkins. It turns out, most of those kinds of developers had the same "year of experience" over and over again, and never really improved themselves nor learned much of anything new or of value.

  • x (unregistered)

    y

Leave a comment on “Programming is Hard”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article