This article reads into the replies article and hand picked a few points.
While actually the article agree on the article it referred to. But the wording has been in a way that is argumentative, which is rather immature imho.
People who disagree aren't trying to make things complex
11–20 of 162 posts
Re: People who disagree aren't trying to make things complex
#12As someone who has read Moby Dick front to back I can agree with this argument. I had a colleague once, really bright engineer but not as steadfast as I was at the time. I suggested he read this amazing novel and he instead opted for the book on tape. During a long drive he almost died from boredom. Literally! He almost fell asleep at the wheel. While he disagreed with me that manually reading the book was the optima…
This comment feels like a markov chain wrote it. Do you really find parallels between this anecdote and reality? What if we presented an anecdote of the opposite to you, would you change your worldview entirely? If not, why should anyone who reads this?
Re: People who disagree aren't trying to make things complex
#13I 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 I see this often with someone who has made it into a senior role and then is attempting to ensure job security through complexity. Reflecting this on to junior developers further reinforces that said developer has adopted (usually subconsciously) a fear-driven approach.
Job security does not seem like a reasonable explanation for programmer behavior in this day and age.
Re: People who disagree aren't trying to make things complex
#14A 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 standards. This kind of constraint allows for higher degrees of rigor, because there often is a 'right way' to do things, or an empirical set of tests to verify the quality of an idea.
Software is, on the other hand, only slightly more constrained than mathematics in its most basic form. We can introduce artificial constraint by monopolizing a domain with certain ideas that have proven robust and reliable (in the same way that we've decided that, in general, you turn a screw clockwise to tighten it), which in turn allows for the introduction of some engineering-style rigor and standards, but there's nothing really stopping you from stepping back and saying, "well I want to do it this way instead", in the way that an Engineer is prevented, by physics, from saying, "well, I think we should just alter the density of air so that we don't need to worry about lift for these airplanes we're building; they'll just be buoyant!". By and large, you can do that kind of thing in code; you're building the world within which you're going to solve the problem, and you can arrange that world as you see fit (by and large) to make certain aspects of the problem easier (often at the cost of making others harder), in the same way a mathematician does.
And if you've got one kind of world you really like, because it works well with how problems decompose in your head, it can, to the parent's point, be really difficult to understand why another representation might be just as useful to someone else's particular brain arrangement.
Not trying to make value judgement here, though I do envy and admire engineering rigor. Just a (likely naive) take on a fundamental difference.
Re: People who disagree aren't trying to make things complex
#15Earlier quoted context omitted.
>I deliberately try to make things complex I see this often with someone who has made it into a senior role and then is attempting to ensure job security through complexity. Reflecting this on to junior developers further reinforces that said developer has adopted (usually subconsciously) a fear-driven approach.
Job security does not seem like a reasonable explanation for programmer behavior in this day and age.
Yes and no. Some developers really want to stay in the same place working on the same sorts of things and to have control over the domains they are working on. There are usually many reasons for this, some ones are easy to understand such as people who value autonomy in their work over the pure dollar value of salary that could be gained by job-hopping. For some folks, the idea of having to go somewhere new with different practices and where they may not be in charge of making decisions on the codebase (or at least not having any control over what goes into it) is terrifying.
Re: People who disagree aren't trying to make things complex
#16A 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…
When you're fighting for speed on your code, it ends up feeling like what you're describing of that engineering world. Your techniques have to adapt to what is actually happening in the lower layers.
When you're fighting for ease of use, you can't make your users forget their preconceptions, you have to adapt to these externalities.
I think sometimes engineering and software development have different degrees of freedom, but the difference isn't as clear cut as you make it.
Re: People who disagree aren't trying to make things complex
#17Earlier quoted context omitted.
>I deliberately try to make things complex I see this often with someone who has made it into a senior role and then is attempting to ensure job security through complexity. Reflecting this on to junior developers further reinforces that said developer has adopted (usually subconsciously) a fear-driven approach.
Job security does not seem like a reasonable explanation for programmer behavior in this day and age.
[deleted]
Re: People who disagree aren't trying to make things complex
#18I 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 have the opposite experience. I think a senior should focus not on identifying the complexity of a problem, but identifying the complexity of the proposed solution. What are the bottlenecks? What possible situations wouldn't fit into the proposed schema? Would a table of 1k records that have a seemingly large number of columns suddenly become 10m records because you decide to use an EAV?
To mitigate issues, is a solution full of contracts and complicated dependencies the right answer? Or is the right answer to not use the ORM for that one particular call and just write a parameterized SQL query or proc that gets the job done?
That kind of insight upfront only comes from experience, which is what a senior has to offer most of all.
Re: People who disagree aren't trying to make things complex
#19As someone who has read Moby Dick front to back I can agree with this argument. I had a colleague once, really bright engineer but not as steadfast as I was at the time. I suggested he read this amazing novel and he instead opted for the book on tape. During a long drive he almost died from boredom. Literally! He almost fell asleep at the wheel. While he disagreed with me that manually reading the book was the optima…
This comment feels like a markov chain wrote it. Do you really find parallels between this anecdote and reality? What if we presented an anecdote of the opposite to you, would you change your worldview entirely? If not, why should anyone who reads this?
I don't think the point of most comments are to change someone's worldview entirely (unless of course they are disputing religion or something on that level). Perhaps they might help to mold it over time but if a single comment can change the way you view the world I think your view was too simplistic to start.
Re: People who disagree aren't trying to make things complex
#20Earlier 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…
When you're fighting for speed on your code, it ends up feeling like what you're describing of that engineering world. Your techniques have to adapt to what is actually happening in the lower layers. When you're fighting for ease of use, you can't make your users forget their preconceptions, you have to adapt to these externalities. I think sometimes engineering and software development have different degrees of free…
Agreed, there's definitely a continuum as you go lower down the stack; in the same way that the first programmers were often electrical engineers (with due deference to Ada Lovelace).