Why Programming is Difficult (2014) • Hacker News Board

Re: Why Programming is Difficult (2014)

#91

Post by greenyoda » Sun, Jan 31, 2016, 6:01 AM UTC

derefr wrote: post #60

mbrock wrote: 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…

"that treats a codebase as a linear narrative of feature additions, rather than a mutable graph representing current behavior. You'd actually be able to read a codebase from "beginning to end" and get a sense of what thoughts went into constructing it, in order."

That might be a good way of understanding the evolution of the system if you're already familiar with what the system does. But if you were a newly hired developer trying to understand the system from the ground up, wouldn't you want the features grouped together by logical function (systems and subsystems) rather than by their order of addition?

Re: Why Programming is Difficult (2014)

#92

Post by jcoffland » Sun, Jan 31, 2016, 6:03 AM UTC

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.

Re: Why Programming is Difficult (2014)

#93

Post by rorykoehler » Sun, Jan 31, 2016, 6:15 AM UTC

jcoffland wrote: post #85

rorykoehler wrote: post #76

Earlier quoted context omitted.

Business people care about instant revenue generation therefore the fastest programmer is the highest value one in their eyes. Maintainability and technical debt is an abstract and far off cost through this lens. Agile methodology was developed in response to this but in my experience the move fast and break things mindset it brings usually translates into move fast, break things and then put the broken things onto a…

If you're afraid you're going to break things then you need to refractor. Fear that changes will break things is a sign of code fragility.

I agree but there is little you can do about the code of your peers especially when they have seniority and you're not doing the code reviews. It's a cultural issue and I'm sure it's not like that everywhere but it is definitely prevalent. Everyone talks a good game about code quality but in practice moving fast is valued more by the money men.

Re: Why Programming is Difficult (2014)

#94

Post by rifung » Sun, Jan 31, 2016, 6:52 AM UTC

marincounty wrote: post #55

ksk wrote: post #19

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 ex…

You should write a blog.(hate that word, but we're stuck with it I guess?). I think it's human nature to overstate the difficulty of one's profession? I know my father felt being a union electrician was on par with--strike that; he felt electricians were the boy profession worth talking about. As a electrician, I can state it's basically knowing 40 important codes, the right training, and a strong back. It's funny ho…

> I think it's human nature to overstate the difficulty of one's profession?

I think there's actually some speculation it's the opposite. I realize there is a lot that's not yet understood, but it seems to point in that direction. See: https://hbr.org/2015/10/its-harder-to-empathize-with-people-...

" First, people generally have difficulty accurately recalling just how difficult a past aversive experience was. Though we may remember that a past experience was painful, stressful, or emotionally trying, we tend to underestimate just how painful that experience felt in the moment. This phenomenon is called an “empathy gap.” "

Re: Why Programming is Difficult (2014)

#95

Post by Terr_ » Sun, Jan 31, 2016, 9:45 AM UTC

nickpeterson wrote: post #48

mbrock wrote: 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…

One thing I really liked about the DDD idea of ubiquitous language was that you reduce the amount of artificial abstractions between domain experts and the code, and it forces developers to be able to converse better with the business. I also think we should be doing a much better job documenting the intent of an entire system. New features get added by working them into the narrative of the 'Document of Intent', rat…

Augh! Stop reading my mind! I've been working to push DDD-ness on my company for a couple years now, and it's been tough.

A contributing factor is organizational: There can be a managerial or "coordinator" layer composed of people who have neither the domain-knowledge of end-users nor the technical-knowledge of programmers.

Unless this layer is composed of very good people, what you get are specs that resemble a game of "telephone": Even if they're detailed with mockups etc, what the specs actually encode is what Alice thinks she needs to ask for in order to satisfy the request of Bob which is based on him thinking about what design might solve his problem, etc.

Re: Why Programming is Difficult (2014)

#96

Post by Terr_ » Sun, Jan 31, 2016, 9:56 AM UTC

noir_lord wrote: post #49

nickpeterson wrote: post #48

Earlier quoted context omitted.

One thing I really liked about the DDD idea of ubiquitous language was that you reduce the amount of artificial abstractions between domain experts and the code, and it forces developers to be able to converse better with the business. I also think we should be doing a much better job documenting the intent of an entire system. New features get added by working them into the narrative of the 'Document of Intent', rat…

Something I've considered on and off is that our current way of writing code is insufficient, I'd really like to have an editor/IDE that had "layers" so that I could attach code related comments in one layer and intent/documentation in another layer - throw in the ability to hide/show layers at will and you'd have a much more flexible way of documenting code than we currently have.

IMO that's sort of what some forms of testing are designed to accomplish, in a way which is a little less-prone to unattended divergence or rot.

Re: Why Programming is Difficult (2014)

#97

Post by huuu » Sun, Jan 31, 2016, 10:31 AM UTC

Terr_ wrote: post #95

nickpeterson wrote: post #48

Earlier quoted context omitted.

One thing I really liked about the DDD idea of ubiquitous language was that you reduce the amount of artificial abstractions between domain experts and the code, and it forces developers to be able to converse better with the business. I also think we should be doing a much better job documenting the intent of an entire system. New features get added by working them into the narrative of the 'Document of Intent', rat…

Augh! Stop reading my mind! I've been working to push DDD-ness on my company for a couple years now, and it's been tough. A contributing factor is organizational: There can be a managerial or "coordinator" layer composed of people who have neither the domain-knowledge of end-users nor the technical-knowledge of programmers. Unless this layer is composed of very good people, what you get are specs that resemble a game…

In my experience some small rules can help to grow towards DDD. For example when the team starts to use immutable model objects everybody is forced to think in a more domain driven way because what happens at the model constuction becomes very important.

Re: Why Programming is Difficult (2014)

#98

Post by mbrock » Sun, Jan 31, 2016, 11:39 AM UTC

nly wrote: post #81

mbrock wrote: post #24

Earlier quoted context omitted.

Yeah, practical and cultural shifts determine how the theoretical foundations come into play. Ten years ago, if you said you were into functional programming, most people wondered if you were crazy and why you didn't just program in a real, normal language. Fifteen years ago, garbage collection was considered slow and mostly only suitable for "scripting." Twenty-five years ago, there was Haskell, Erlang, Common Lisp,…

The matters from each era you mention haven't become any more agreed upon... the hype bubbles just evaporated and reformed elsewhere. Nobody became wiser, the landscape just changed. And, you know, it's probably more interesting to look at the landscape than the architecture anyway. The 70s brought us computing, the 80s brought us networking, the 90s brought us eCommerce, the 00s brought us social and mobile. I don't…

Maybe no grand increase in wisdom, but I would say there is a more diverse interest in languages and paradigms, which probably has downsides too. But, like, on my last three jobs I've worked with Haskell, Ruby, and now Clojure and Elixir. The proliferation of alternative databases seems like a part of this trend too. At least in the startup world, right now we're not so bound to a legacy of serious boss-approved technologies.

So I'm talking about the landscape of development, if you will... Paul Graham's "Beating the Averages" is about how he and Robert Morris knew back in '95 that in a web startup you could use whatever language you wanted, and I think that came into play in a big way in the '00s. I speculate that Ruby + Rails had a pretty big impact, and then also there was just this generational wave of internet nerds, and a big upswing in open source infrastructure, and some other factors...

Hey, while I'm speculating! I think the basic shapes of collaboration-type apps are kind of settling to the point where technologies will come out that eliminate much of the coding drudgery.

This is an old dream, of course, and it comes in cycles—like, maybe a truly excellent framework for modern real-time web apps will stabilize, and the year after everybody will be in virtual reality and the whole paradigm changes again.

But if you look at the structures of "social and mobile" apps, there are some common denominators that we still reimplement tediously all the time. Users who have relations with each other and other entities, via various permissions. Distributed resources modified with different consistency properties. Timelines, searching, embeds, comments, notifications, and some other things.

So what if you took a bunch of clever people with experience from projects like reddit, SoundCloud, Instagram, Airbnb, Slack, or pretty much any social thing, and gave them a couple of years to dream up an architecture that would make all their jobs easier, and that they could maintain as an open source framework? Maybe throw in some theoretical experts to help tease out elegant abstractions and semantics.

I think something like that would make sense for YC Research, even if it's not as radical as, say, extending life spans. Because how much of the YC-backed developer workforce is right now sitting around hacking their own thing for real-time notifications? How much more efficient would these startups be if they could configure a mature system declaratively and get the basics, cross-platform, like you could get the basics for a CRUD app with an hour of Rails configuration?

Anyway, that turned into a long semi off-topic rant. It's just one incremental step I see on the horizon.

Re: Why Programming is Difficult (2014)

#99

Post by mbrock » Sun, Jan 31, 2016, 12:38 PM UTC

huuu wrote: post #97

Terr_ wrote: post #95

Earlier quoted context omitted.

Augh! Stop reading my mind! I've been working to push DDD-ness on my company for a couple years now, and it's been tough. A contributing factor is organizational: There can be a managerial or "coordinator" layer composed of people who have neither the domain-knowledge of end-users nor the technical-knowledge of programmers. Unless this layer is composed of very good people, what you get are specs that resemble a game…

In my experience some small rules can help to grow towards DDD. For example when the team starts to use immutable model objects everybody is forced to think in a more domain driven way because what happens at the model constuction becomes very important.

We have a clear vocabulary problem especially in the UI layer, where we never really know what to call things. I've been working on a test tool that involves assigning a natural language name to each rendered entity, so you can then tell the tool to "Look at the sidebar. Click the compose button. Now look at the profile pane. See a message composition view." The hope is to get both a test suite and an encouragement to think of the UI entities in a more "ubiquitous language" type way. It's still an early experiment but it's turning out quite nicely and I hope to release it as open source within a couple of weeks.

Re: Why Programming is Difficult (2014)

#100

Post by golergka » Sun, Jan 31, 2016, 1:16 PM UTC

rorykoehler wrote: post #76

JustSomeNobody wrote: post #69

Earlier quoted context omitted.

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.

Business people care about instant revenue generation therefore the fastest programmer is the highest value one in their eyes. Maintainability and technical debt is an abstract and far off cost through this lens. Agile methodology was developed in response to this but in my experience the move fast and break things mindset it brings usually translates into move fast, break things and then put the broken things onto a…

You either have a very bad luck with "business people" or talking about a stereotype that is about as close to the truth as similar stereotypes about programmers are.

Business people are very familiar with terms like "infrastructure", "extensibility", "maintenance" and the like. They're not idiots. May be you should try explaining why refactoring and good architecture is good in business terms instead of programming?