Live data from Hacker News

People who disagree aren't trying to make things complex

m50d.github.io

111–120 of 162 posts

Re: People who disagree aren't trying to make things complex

#111
post #14

Earlier quoted context omitted.

This is a great comment, and very succinctly put. Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics. The 'possible model space' is relatively constrained, and everyone is working under, roughly, the same set of assumptions, rules, and standar…

> Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics. As a software engineer who calls what I do "engineering", I have to answer to physics every day. The difference is that the relative cost of everything is skewed so far out of proportion to…

We're absolutely working with physical stuff still. However, if there's a continuum between mathematics and engineering, I think software is much closer to the former than the latter.

I think 'working with real physical systems which obey physical laws' is necessary, but not sufficient to qualify a discipline as engineering. Architects are not typically engineers by the title, and yet they design real things, and have to worry about some aspects of pragmatic engineering when they work. Neither are applied physicists, even though their work to defines many of tools that engineers use. I'm not sure that the task of creation scales isometrically. I think there's a certain allometric aspect that means that the kind of thinking required at 8 orders of magnitude has a radically different shape to that at 20 orders of magnitude; there are still some hard yeses and hard nos (you can't build a Dyson shell out of adamantium), but the amount of grey area is vastly, non-linearly larger, and requires a lot more ad-hoc construction to work within, and thus strips away the shared language of rigor that engineering has the benefit of operating under.

I hope I haven't made it sound like I think it's completely black and white, and also that I somehow don't think software is hard. I just think it's a different kind of animal, because of the scale that it operates at, and the number of abstractions it depends on, even if it can't embrace them fully and transcend into pure mathematics.

Re: People who disagree aren't trying to make things complex

#112
post #14
post #3

A big part of this is that programmers have different programming worldviews. Many people seem to be unaware that worldviews are not perfect rational easily modifiable constructions but are instead foundational structures that thinking builds upon automatically. Programmers are about as unlikely to easily change their programming worldviews as they are to change their political beliefs. Which is not to say that progr…

This is a great comment, and very succinctly put. Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics. The 'possible model space' is relatively constrained, and everyone is working under, roughly, the same set of assumptions, rules, and standar…

> Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics

So do computer scientists! Random access memory isn't constant time, but logarithmic for physical reasons. Cache effects can dominate big-O for a surprisingly large range of input sizes.

Re: People who disagree aren't trying to make things complex

#113
post #57

Since this seems to be the place for personal views, my views, after 20 years of experience, is that people do not notice the complexity of anything that they have digested as normal. As a result doing anything other than what they are used to seems very complex to them. Whether that other thing is actually complex to a neutral third party is situation and observer dependent. I have seen this with procedural programm…

My now favorite example for what you describe is this blog post "I no longer understand my PhD dissertation". However, it's worse, even the same person experiences this - because over time we are different people.

To quote from the blog post:

> I was curious to see how much of the dissertation I can still grasp, five years after the fact. I figured it couldn’t hurt my ego if I refreshed my mind with past mathematical glories.

> How wrong I was.

> This was not the casual read I had in mind. The notation was alien. I even had to scour the examiner’s report to direct me to the key results. And while I could have sworn this was a well-written thesis, I repeatedly found myself bamboozled by my own prompts. “The result now follows easily…” may have made sense back when, but now the author-turned-confused reader can profess that it most certainly does not follow easily, at least in his own mind.

https://medium.com/@fjmubeen/ai-no-longer-understand-my-phd-...

Re: People who disagree aren't trying to make things complex

#114

Earlier quoted context omitted.

> I deliberately try to make things complex, but not more complex than they actually are I don't understand. Is it an elaborate way to say that you expose your juniors to the full complexity of the problem, rather than feeding them a "simplistic" view of the problem? > This is more often due to insecurity than accident or technical ignorance and while their motives are often unintentional (non-cognitive) the actions…

Economically speaking, the problem is. It isn't necessarily complex or simple. Whether, or not, you are willing to accept that there is are risks and possibly second or third order consequences to your approach is the true complexity. Exposing the fullness of the problem isn't a creation of complexity. The same amount of complexity is already there unchanged. Are your juniors willing and capable to account for this t…

I really like this view.

I see problems as a messy graph. There is a node on the far left that represents the problem and a node on the far right that represents the solution. There are nearly infinite ways to traverse this graph to complete the problem, but there is a minimum number of nodes that must be passed, along some optimal path, in order to actually solve the problem, as defined. No less is possible, unless you change the problem. I think being able to see something close to this minimum complexity, and that it is the problem, is what you’re referring to.

After identifying this, the problem/solution nodes can be reassigned intentionally.

Re: People who disagree aren't trying to make things complex

#115
post #31
post #28

So, we should just "agree to disagree" and stop trying to demonstrate how one approach might be much better over another? How can anything ever get better? The Complexity Trap didn't accuse anyone of actively trying to make things complex, nor did it imply any "moral failings" on anyone's part, it just gave examples of how common practices can cause accidental complexity. It also dedicates an entire section to defini…

> So, we should just "agree to disagree" and stop trying to demonstrate how one approach might be much better over another? How can anything ever get better? No, we should try to make things better. But framing these choices as "complexity" doesn't seem to be helpful. The choices are tradeoffs but they're not a deliberate choice of complexity for the sake of some other value; at most they're choices between different…

> deliberate choice of complexity

I also don't see anything in The Complexity Trap that accuses anyone of that. I think that's a misreading.

Rather, I think The Complexity Trap argues that many developers have a poor understanding of what "complexity" means, so they end up increasing it even when they think they are decreasing it. Specifically, I think the point it tries to make is that complexity doesn't equate to verbosity, and simplicity doesn't equate to terseness. That's why it starts by defining complexity in terms of coupling.

Your article seems to agree that DTOs are more decoupled because you refer to it as "cargo cult decoupling", yet you still argue it's more complex. So you aren't using the same definition.

Having said that, I do agree with you that blind "decoupling" is definitely not always the answer, and some things should be coupled. When a change in one thing should always cause a change in the other, purposely coupling those things in code can decrease complexity.

But I wouldn't say coupling your public API to your internal model by generating the former from the latter is one of those cases. It's something that's done for convenience and terseness, at the expense of complexity. (It's more complex because changes that would otherwise be simple refactorings could cause breaking changes for consumers of your public API in ways you would not expect. For example, you won't be able to use automated refactoring tools safely without carefully thinking through the consequences in your head.)

Depending on the project, trading complexity for terseness/less boilerplate might be the right decision. But it should be done consciously.

Re: People who disagree aren't trying to make things complex

#116
post #70

Earlier quoted context omitted.

I feel like most of the strife caused at work is different value judgements on things. So I've been trying to tease out truths vs value judgements. 1 + 1 will always equal 2, no one debates that. AWS offers both Postgres and MySQL, no one debates that. But which one is better, that will be informed by possibly irrational value judgements ("Postgres bit me once, never again!") I think people are irrational in terms of…

> 1 + 1 will always equal 2, no one debates that. Challenge accepted. * In boolean algebra, 1 + 1 = 1 * Over the field Z2 (the integers modulo 2), 1 + 1 = 0 * In binary, 1 + 1 = 10 * In a language that allows overloading +, 1 + 1 = usually 2, but potentially almost anything else In conclusion, context matters

To be fair, in Z2 the equivalence class of 1 + 1 is still equivalent to the equivalence class of 2.

Re: People who disagree aren't trying to make things complex

#118
post #57

Since this seems to be the place for personal views, my views, after 20 years of experience, is that people do not notice the complexity of anything that they have digested as normal. As a result doing anything other than what they are used to seems very complex to them. Whether that other thing is actually complex to a neutral third party is situation and observer dependent. I have seen this with procedural programm…

My now favorite example for what you describe is this blog post "I no longer understand my PhD dissertation". However, it's worse, even the same person experiences this - because over time we are different people. To quote from the blog post: > I was curious to see how much of the dissertation I can still grasp, five years after the fact. I figured it couldn’t hurt my ego if I refreshed my mind with past mathematical…

Thanks for sharing the interesting article! This effect also applies on presentation slides.

Just checkout my archive for some slides I presented a few years ago. I would have thought that they are random compilations if there are no file names.

Re: People who disagree aren't trying to make things complex

#119
post #110

Earlier quoted context omitted.

These are great points and I wanted to add a couple more I've found over the years. Software development often has an almost infinite number of ways to accomplish the same task. Maintainability is as much, if not more, about correctly predicting the future uses and requirements of the software as it is about the initial coding practices and design patterns. Working on older systems that are being used in ways that th…

> The grand irony is that, very often, once a developer becomes fully aware of this concept, they lose that internal fire and vigilance required to constantly seek out better ways to solve problems and their skills wane. Any hints to guide one back to the path of passionate problem solving?

Work on bigger problems that are a lot harder to solve. You cant mitigate for reality, but what you can do is offset its shittyness but taking on a project/task that yields results that are big and great enough to justify dealing with shitty systems/ heuristics to begin with.

Just my 2 cents!

Re: People who disagree aren't trying to make things complex

#120
post #3

A big part of this is that programmers have different programming worldviews. Many people seem to be unaware that worldviews are not perfect rational easily modifiable constructions but are instead foundational structures that thinking builds upon automatically. Programmers are about as unlikely to easily change their programming worldviews as they are to change their political beliefs. Which is not to say that progr…

I completely agree with your comment but since we are on the topic of worldviews and assumptions I just want to point out that women program too. My assumption currently is that you do not switch pronouns arbitrarily and as a result were not just as likely to send "social circumstances may necessitate that she adopt a new viewpoint" when writing about an abstract individual programmer. I know it is annoying to have t…

Use the generic singular "they" for persons of unknown gender?

> there is a good chance of of the other person's programming beliefs may play a big role in their thinking

Check.

Use the male pronoun for hypothetical person in detailed example who needs to be more flexible in his/her thinking?

> this social circumstance may necessitate that he adopt a new viewpoint

Where the female pronoun would sound awkwardly coercive and uninviting?

> this social circumstance may necessitate that she adopt a new viewpoint

Check.

I believe ilaksh has their bases covered.

Post reply on HN