People who disagree aren't trying to make things complex • Hacker News Board

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

#101

Post by klodolph » Wed, Dec 12, 2018, 2:02 AM UTC

flukus wrote: post #71

klodolph wrote: post #64

Earlier quoted context omitted.

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

> At the end of the day, I am writing software, and that software is one part of a real, physical system which obeys physical laws. This makes me an engineer. The person that made my coffee this morning is also an engineer by this definition. Apart from that I agree, we have real constraints to deal with and we can't hand wave away the environment the code runs in.

> The person that made my coffee this morning is also an engineer by this definition.

The verb choice is important here, someone who makes coffee doesn’t “write” coffee.

That said, any definition outside mathematics or logic is imperfect.

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

#102

Post by fatkidspecial » Wed, Dec 12, 2018, 2:02 AM UTC

ilaksh wrote: post #89

shuntress wrote: post #48

Earlier quoted context omitted.

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…

There is a problem with the English language. There is no commonly used neutral pronoun. The closest thing is "they" but I think some people consider that incorrect grammar or something. he/she or switch back and forth is awkward.

the royal we?

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

#103

Post by munchbunny » Wed, Dec 12, 2018, 2:08 AM UTC

austincheney wrote: post #9

I deliberately try to make things complex, but not more complex than they actually are, though apparently this is received as a matter of perception. It commonly boils down to risk or performance versus convenience. As a senior developer I notice that juniors will sometimes do everything in their power to over-simplify a given problem. This is more often due to insecurity than accident or technical ignorance and whil…

I tend to see this in a different way.

In most of the difficult architectural decisions I have encountered, there is a slider that goes from "complex" on one end to "aspirational" on the other. I see this trade-off much more often than I see things getting over/under-engineered, though I've definitely also seen that.

"Complex" tends to be actually easier to design: you adapt the existing somewhat complex system, add a couple things here and there, and you have a workable solution to the problem at hand, even if it feels a bit kludgy.

Simple tends to be harder to achieve because reality is complex, and designing a small number of abstractions to encompass a complex system requires willingness to spend blood and sweat in "meatspace" to reign in the complicating factors. Don't want to support XYZ? Well, you're going to have to get people to stop using XYZ first.

I don't think this extends beyond software architecture, but that has been my experience working on living codebases.

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

#104

Post by [deleted] » Wed, Dec 12, 2018, 2:23 AM UTC

[deleted]

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

#105

Post by marcosdumay » Wed, Dec 12, 2018, 2:25 AM UTC

trainingaccount wrote: post #97

Bjartr wrote: post #70

Earlier quoted context omitted.

> 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

Wot no vectors?

|1> + |1> = 2 * |1> =/= |2>

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

#106

Post by [deleted] » Wed, Dec 12, 2018, 2:31 AM UTC

austincheney wrote: post #9

I deliberately try to make things complex, but not more complex than they actually are, though apparently this is received as a matter of perception. It commonly boils down to risk or performance versus convenience. As a senior developer I notice that juniors will sometimes do everything in their power to over-simplify a given problem. This is more often due to insecurity than accident or technical ignorance and whil…

[deleted]

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

#107

Post by [deleted] » Wed, Dec 12, 2018, 2:33 AM UTC

brabara wrote: post #49

barberousse wrote: post #5

This is a particularly thorny issue as a Junior Developer. There's the issue of the Junior reaching beyond their britches, but there's also the issue of Seniors being set in there ways.

As mid level developers, how can we resolve this impasse?

[deleted]

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

#108

Post by austincheney » Wed, Dec 12, 2018, 2:42 AM UTC

astrobe_ wrote: post #47

austincheney wrote: post #9

I deliberately try to make things complex, but not more complex than they actually are, though apparently this is received as a matter of perception. It commonly boils down to risk or performance versus convenience. As a senior developer I notice that juniors will sometimes do everything in their power to over-simplify a given problem. This is more often due to insecurity than accident or technical ignorance and whil…

> 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 to devise a simplistic resolution that actually lowers risk and with the smallest amount of code? Conversely are they imposing unnecessary layers of abstractions to remove themselves from the directness of the problem?

Another way to think about it in "junior" terms is whether its simple or easy. Those aren't the same.

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

#109

Post by austincheney » Wed, Dec 12, 2018, 2:53 AM UTC

sonnyblarney wrote: post #29

austincheney wrote: post #9

I deliberately try to make things complex, but not more complex than they actually are, though apparently this is received as a matter of perception. It commonly boils down to risk or performance versus convenience. As a senior developer I notice that juniors will sometimes do everything in their power to over-simplify a given problem. This is more often due to insecurity than accident or technical ignorance and whil…

That's funny because I have become, and observe the exact opposite. The notion of trying to make things more complex than they need to be I find deeply problematic. Junior engineers often end up devising solutions which are in fact too complex as they try to over engineer everything. The more experience I have, the more I accept that code is complexity and cost and that it should be avoided. Always take the easy path…

I think that is a misunderstanding between the problem and the solution. The ideal scenario is to take a complex problem and devise a simple solution.

Problems are not made more complex. They are literally the requirements provided. From an economic perspective, the problem is. The complexity is in how a person receives those requirements (perception of approach). This is lost on someone when a problem is more fully exposed according to potential second and third consequences (risks). When everything is ad hoc the risks are never exposed until a mountain of code is written that ends up being not simple and excessively fragile.

To avoid the unforeseen stupidity I prefer to expose the complexity up front and try to prevent people from hiding from it. That doesn't change the problem statement, the environment, the end user, or anything else. It only changes the investment of effort and the person providing that effort. Burying your code in layers of unnecessary abstraction and mountains of dependencies is not exercise in simplicity because somebody has successfully avoided writing original code. This is the difference between simple and easy.

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

#110

Post by nomel » Wed, Dec 12, 2018, 3:07 AM UTC

kokokokoko wrote: post #80

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

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?