Live data from Hacker News

Why Programming is Difficult (2014)

joearms.github.io

61–70 of 117 posts

Re: Why Programming is Difficult (2014)

#61
post #16

Earlier quoted context omitted.

See the middle part "there is not enough time to do it right first time"

And even if there happens to be, check back in six months and see what's happened. Did your beautiful design smoothly accommodate the fix for the tricky issue #5388? Was there enough time then to update your clear documentation, or does the documentation now clearly explain something false? Did the new coworker who implemented that new feature understand the point of your design such that she was able to extend it pr…

Yup. Unit tests, clean code built via tdd, auto generated docs from interfaces, high level architecture diagrams and explanations on a wiki, instructions on getting your machine / environment set up on a wiki, and api contracts on a wiki are the best documentation from my experience.

Re: Why Programming is Difficult (2014)

#62
post #5

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.

Why does something come next? Maybe we're already doing it right.

Re: Why Programming is Difficult (2014)

#63

>code that produced it should be cleaned up and documented before the next project was started. A major why waiting to the end to test document and clean up code is a failure. Write beautiful, tested code from the start. Even throwaway code, because half time prototypes, etc end up production.

At most places I've worked there's not much point in documenting everything meticulously at the start. The users don't know what they want yet, and they won't think through the details until they get the first prototype.

What makes sense in testing and documentation is really project dependent. What's right for flight control software is very different from what's right for Yet Another Twitter Clone.

Re: Why Programming is Difficult (2014)

#64
post #17
post #2

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. 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. The idea of composability i…

Do you think that sort of a problem (incremental changes eroding an initially sound structure) could be fixed with better refactoring tools? It seems like the issue you're describing is that logic is leaking from some parts of the codebase to others, which might be fixable with sufficiently powerful refactorings.

In my experience the only thing that prevents that phenomenon is unrelenting stubbornness from the development staff. It takes a tremendous amount of thought and care with each change to make sure it doesn't happen. Also in my experience, there is no "fixing" it once things have gone down hill. It's theoretically possible, but I've never personally seen it happen. Whereas I have seen fairly large code bases remain coherent after years of significant changes. That dev team was like a bunch of nazis as far as code quality was concerned. It was the best team I've ever worked with.

Re: Why Programming is Difficult (2014)

#65
post #60
post #2

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. 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. The idea of composability i…

> Projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. Personally, I think this isn't inherent, but is just an effect of how all the current programming paradigms (procedural, functional, even logic) tend to compose features together by simply sticking more code into each node of the function graph. So code that was originally a single stream of s…

Developing a linear narrative is a good part of why revision control systems and issue trackers exist. You use them to explain the evolution of the code base.

Re: Why Programming is Difficult (2014)

#66
post #60
post #2

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. 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. The idea of composability i…

> Projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. Personally, I think this isn't inherent, but is just an effect of how all the current programming paradigms (procedural, functional, even logic) tend to compose features together by simply sticking more code into each node of the function graph. So code that was originally a single stream of s…

I'd love to see some non-game software written in Inform 7. Like, a web framework. Seriously!

Re: Why Programming is Difficult (2014)

#67
post #31
post #17

Earlier quoted context omitted.

Do you think that sort of a problem (incremental changes eroding an initially sound structure) could be fixed with better refactoring tools? It seems like the issue you're describing is that logic is leaking from some parts of the codebase to others, which might be fixable with sufficiently powerful refactorings.

Yeah, I think the sheer manual friction of moving things around is a big impediment to change. But also, I think there has to be some conceptual basis for us to be able to think about factoring in a clear way, and that kind of intellectual labor is hard on another level. Eric Evans' book on domain-driven design has some examples of programming tasks that generate confusing and unclear code, until the coder together w…

Very smart comment. I've had a long brake from programming and all this functional and lisp stuff is new, and it is not always clear what is the benefit. But is great to see a diversity and experimentation.

Re: Why Programming is Difficult (2014)

#68
post #31
post #17

Earlier quoted context omitted.

Do you think that sort of a problem (incremental changes eroding an initially sound structure) could be fixed with better refactoring tools? It seems like the issue you're describing is that logic is leaking from some parts of the codebase to others, which might be fixable with sufficiently powerful refactorings.

Yeah, I think the sheer manual friction of moving things around is a big impediment to change. But also, I think there has to be some conceptual basis for us to be able to think about factoring in a clear way, and that kind of intellectual labor is hard on another level. Eric Evans' book on domain-driven design has some examples of programming tasks that generate confusing and unclear code, until the coder together w…

[deleted]

Re: Why Programming is Difficult (2014)

#69
post #2

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. 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. The idea of composability i…

What I've seen kill code quality is a) management putting out fires and b) cocky programmers who boast they can do X in a few hours. Ok, sure, any of us can but why don't you take longer and properly refactor the code. Problem is, they've already opened their mouth so now management expects it in a few hours.

Re: Why Programming is Difficult (2014)

#70
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).

Great article though- I think it applies to most technical roles.

Post reply on HN