In my experience, the overwhelmingly most difficult thing about programming is writing code that makes sense, even after it has gone through a couple rounds of requirements changes and bug fixes.<p>Any concrete coding task can be dealt with straightforwardly enough, but projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema.<p>The idea of composability is a good approximation to what it means for a program to make sense. If any part of the program can be understood as a sensible composition of parts, then the program probably makes sense.<p>But so many parts of real world code bases seem to end up incoherent. You look at a function and instead of seeing code that obviously, say, maps the render function over the list of widgets, you see three obscure conditionals, an apologetic comment, a bug tracker issue number, two boolean parameters named "force" and "dontRenderLast" (for some reason), and so on.<p>This is why I think the ideas from "domain-driven design" are so important, including the notion of a ubiquitous domain vocabulary. Also the FP idea of denotational semantics. And that well-known benefit of unit test driven design.<p>There's not enough recognition and clear understanding of this problem, in my opinion. We all know the problem, but somehow we don't talk about it enough, and don't acknowledge it as an enormous problem for development speed, programmer happiness, agility, and so on.
I don't think programming - in the sense of what 99% of programmers do - is as difficult as programmers love to blog about. Most professional programmers write stuff that is not all that hard, and most of it has been done by others countless number of times. All the "hard" cutting edge stuff is done by a tiny tiny fraction of programmers. Heck even the things people think are cutting edge now, just taking a random example - VR, have been explored decades ago. Seriously, go read some SigGraph papers.<p>However, programmers more than other professionals love blogging about their work, which is great - because it helps spread ideas (more so than any other field I've seen), but also creates this illusion that programming is this super hard thing. I mean people complain about going to interviews and being asked about algorithms and stuff that you could "just google" when, if you were to ask an average scientist, the amount of active working knowledge they have at any given time is simply astounding.
It is much easier to prove a particular program function correct when complexity is properly handled, this is the true art of programming, handling complexity in a way that makes sense.<p>Many complex phenomena in nature is explained by very simple mathematical equations, likewise great engineering design is achieved when there is nothing else to remove, and in order to achieve those results, a great deal of effort and thinking has to happen first.<p>The thing is, as the author put out, the environment is just too hostile in order to design beautiful programs, from the insane expectations of what can be done, to incompetent peers, politics, distractions and what not.<p>If you are skilled, you can define a problem in a precise way, be able to dissect it in smaller problems, solve them and prove the solution correct.<p>What is ultimately hard is how to handle the hostile environment you're usually stuck with.
<i>Programming is difficult because it is easy</i>.<p>Here is what I mean. Implementing new functionality where nothing existed before <i>is</i> easy: just figure out what you want the machine to do, and tell it to do that. It isn't trivial, but on a relative scale, it's easy.<p>Precisely <i>because</i> it's easy to create functionality, we do a lot of it. Our programs grow. As they grow, they get complicated. As they get complicated, it gets to be more and more difficult to understand what they're already doing so that we can make them do something different. So, the less tongue-in-cheek version of my thesis here is that <i>programming gets to be difficult because it starts out being easy</i>.<p>This is why I always say that the essence of software engineering is <i>the management of complexity</i>. And this is the part that people who have not actually worked on large programs will probably never understand. (As someone once said to me, "what you need to get is that management views programming as primarily a <i>clerical</i> function".) Viewed one-by-one, the tasks seem simple. And yet, somehow, when you put them all together, they're not simple anymore.
> Sleep. A lot of programming problems get solved while you sleep.<p>I love it when I go to bed mulling over a problem, and when I get up I have the solution. The brain is truly a wondrous machine!
I think the author nailed it on the head with the Workplace parts about why programming is difficult. The physical/socio-political environment that someone is in compounds the normal issues in the programming process and I've seen it drive quite a few programmers to straight up quit when the mountain of issues became insurmountable. Without the freedom to tinker and explore a bit, as the author bemoans, I think that it's when programming becomes a chore and<p>At my last job, I think the only time that I had ever seen our programming team actually happy to work on a project was when by chance and via a minor mutiny, we were able to break them away from the minutia of constant maintenance and repair and let them actually just work on a project with no expected outcome. It was an alternative path for our identity management solution and the entire project was a challenge to the managers for the Enterprise team. Our programmers were down-right chipper at the prospect of just being able to flex their creativity and try something just to see if they could do it.
The most important line from the author is "it takes time to be a good programmer". Those nights of debugging and reimplementing will decrease as you better understand how to develop code.<p>Also I find open concept offices terrible to work in. I'm not the type of person who can put on a pair of headphones, blast music and pump out code. I like solitude as I think though the problem and code. Unfortunately for me, the open concept is here to stay it seems.
I see these posts every so often: "X is hard". Aside from just illuminating the X, I don't really see the point of the posts. Most higher-order jobs are difficult, that's why people train and educate themselves to work in the field. Coding has it's own set of challenges, but I don't think anyone is saying coding something slightly complex is easy. Just like how designing a building is hard, or swimming an olympic time is hard, or solving a complex science equation is hard. If I'm being honest, these posts come off a little whiny.
The bigger question is, why are we still programming the way we did 20yrs ago? Higher level languages were a great improvement over machine language. But what comes next? Why don't we have it yet? A decade ago I was setting up database, writing queries, designing forms, writing the code to wire it all up. I still have to do all these steps with more amount of effort today.
>code that produced it should be cleaned up and documented before the next project was started.<p>A major why waiting to the end to test document and clean up code is a failure.<p>Write beautiful, tested code from the start. Even throwaway code, because half time prototypes, etc end up production.
I think for those programming complex systems in business and industry, the biggest problem remains how to represent concepts in code.<p>Even the simplest problem, like a Purchaser placing a Purchase Order for a Product from a Supplier can't be easily modeled and programmed by the majority of software developers - with any sort of predictability based on prior art or their own experience.<p>At best, we approach a problem with a combination of modular procedural code (modularity via subroutines)(from the 1950's) and structured programming with functional decomposition (from the 1960's).<p>There is no shortage of technical prowess, but a warehouse system is not based on design patterns, libraries, frameworks, or technologies. Instead, it is based on people, places, things and transactions interacting together to solve a problem.<p>How to represent real-world concepts and systems (real or abstract) into code, remains the challenge it always has been. We just don't seem to learn any lessons from the past.
All good points, but this is not just specific to programming IMO. I work as a sales engineer for a networking company and I face the same issues as you when I work with customers who use our products. Documentation is never good, you're always solving customer problems so you never really have time to dig deep (read 391 page manuals are out of the question), new features are not described correctly and when I try to lab things up (demo or otherwise) there are about 100 things that can go wrong (I made up that number but you get the idea).<p>Great article though- I think it applies to most technical roles.
<i>Now I find no particular joy in implementing archaic and perverse protocols but often the quickest way to progress is to re-implement them from scratch.</i><p>whaaaa
The author and a number of commentors seem to be saying that incremental changes eventually lead to tangled and unmaintainable code. My litmus test for the quality of a code change is the amount of code it allows me to remove. If a change results in many other parts of the code collapsing or getting simpler then I know I've made a good decision.
I believe author means things like code, build system, etc when they say "inputs are beautiful". Cause In my experience one of the major inhibitors of beautiful code, what takes many tests, and what makes dev hard is how fucked up input is. Esp user, as in interactive human, input.
It is not difficult, trust me. I know C, C++ , Java and Phyton. It is all about logics and the only thing that differs is the syntax.
Get in touch I might help you