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…
Coincidently, people (and other beings) also have different worldviews in every context and not acknowledging this leads to endless pointless arguments. It would be cool if the participants of every discussion (programming or otherwise) labeled their worldviews explicitly, so we could at least know what we're dealing with. For example on here with a tag by our usernames. Old religions used to serve that purpose at le…
People who disagree aren't trying to make things complex
141–150 of 162 posts
Re: People who disagree aren't trying to make things complex
#142No programming approach is perfect but some programming approaches are better than others. I started programming with a statically typed language for many years and then I went back and forth between dynamically and statically typed several times in my professional career. Once you've developed good programming habbits (which statically typed languages can help you to learn), ultimately, dynamically typed is better.…
Re: People who disagree aren't trying to make things complex
#143Earlier 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
Re: People who disagree aren't trying to make things complex
#144Judging by the initial half-second of chaos on page load there's certainly something complex about the javascript this person is using to communicate these words.
Re: People who disagree aren't trying to make things complex
#145Earlier 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?
What fuels my passion: I try to stick to languages and concepts that are puristic. I loved SmallTalk, which is pure OO (so much more than Java). I love Haskell, which encapsulates a particular style of functional programming quite well. I love LISP, since it represents and embraces metaprogramming quite well. The more a language deviates from these extremes, the less 'thrill' I feel using them. I always try to solve problem with the purest form a paradigm has to offer.
In the real world, I am able and perfectly happy to choose whatever tool fits the need best and adapt to the team. But I will certainly voice my opinions ("This is a planning task - let's not reinvent the wheel - and waste time and fix unnecessary bugs - and just send the data to Prolog and translate the solution back into our program") tho and what I do in my free time is not bounded my industrial needs.
Every paradigm offers a different perspective on programming and is worth exploring. Thankfully I am not genious enough to run out of this particular motivation in my lifetime.
Re: People who disagree aren't trying to make things complex
#146Earlier quoted context omitted.
Except not the first one.
Well you can implement the same program in endless different ways. Particular styles develop. Each piece of software is unique. You're engineering with an artform that's why you see so much variation among the patterns. Every portrait might be recognizable as a portrait, but every portrait is unique in its details.
"the expression or application of human creative skill and imagination, typically in a visual form such as painting or sculpture, producing works to be appreciated primarily for their beauty or emotional power."
Software developers have a tendency to try to claim artist status because what they do is almost entirely meaningless and a waste of time. The exchange of time for money is too transparent so they are unfulfilled and try to imbue their work with meaning. If you want to make art, do it, it can be a hobby. Yet another useless website created to shove more ads in people's faces is not art.
Re: People who disagree aren't trying to make things complex
#147Or better yet, your complexity is incidental, mine is essential. I was forced to make it complex, you did it because you’re not trying hard enough!
As Rich Hickey’s dictionary reminds us, to complect is to entwine together things better left separate. If you aren’t using the word in this sense, if you aren’t identifying the specific concepts which are complected but should be separated, you’re using fancy words to say you don’t like something. I’ve noticed we tend to do that, a lot.
I’m very wary of doing this in my own thinking, personally. It’s okay to just not like something, and it’s more honest just to say so than to use objective-sounding words in an attempt make it about something other than one’s own taste.
Re: People who disagree aren't trying to make things complex
#148> What if there is no "complexity trap", just disagreements about how best to design programs? While I think this post asks reasonable questions, and has some healthy skepticism, the complexity trap is very real, in my experience. After 20 years of professional software development, I can safely say I've watched literally tens of millions of dollars wasted over-engineering solutions to problems that were anywhere fro…
Would you say that these over-engineered solutions actually grasped the problems, and over-engineered the solutions? Or did they not grasp the original problems to begin with, and solved tangential problems instead? In my experience it's often the latter that leads to accrued accidental complexity and technical debt. Edit: grammar.
I think I’ve more often seen tangential and imagined problems than people doing the right thing the wrong way. To be fair, it can actually be very hard to know whether a problem is really truly a problem that needs to be solved. Some tangential and imagined problems seem important and real, and you don’t discover until later you needed to solve something else and not the thing you did.
Some examples:
At a games company, the two mathiest programmers decided we needed to be using geometric algebra instead of matrices. They spent years working on it, and the code infected the rigging and animation and rendering systems, all kinds of things. Most of the programmers had to interface with it, but didn’t know geometric algebra, so it slowed development. It only solved minor issues. One of the claims was we’d have no gimbal lock, but people already solve that with matrices in one or two functions, it’s a non issue. To top it off, the math all got a bit slower, and we had to maintain the matrix math anyway to interface with the hardware and external libraries.
At a film company all the programmers decided they were tired of the renderer and they needed to start from scratch because making updates was getting slow and difficult. They scrapped the renderer, started over, and it took many multiples longer than they estimated. When they were done, they had roughly the same complexity and ugliness as before, and making updates didn’t get significantly easier. Some mistakes were made in the rush to rewrite everything.
Personally, I built a multi-user whiteboard website, and I over-engineered the rendering and the multi-user undo system, convinced they both needed to be perfect. In the mean time, discovered that very few people care about those things or ever hit corner cases, and I missed the opportunity to write proper integrations with other tools and import/export tools — the things the customers needed in order to adopt my software for their workflows.
Re: People who disagree aren't trying to make things complex
#149I 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 This strikes me as odd. You really sit there thinking "I need to make this complex"? Why not strive for correctness and completeness?
Re: People who disagree aren't trying to make things complex
#150I have to pretty much reject this post wholesale. True the post it's disagreeing with picked weak examples. But other than that pretty much all of its overall points were actually very accurate. The original article was not about json/scala/etc. It was about this: To summarize, we have to deal with a lot of accidental complexity these days, for multiple reasons. First of all, we adopt techniques and abstractions with…
> True the post it's disagreeing with picked weak examples. But other than that pretty much all of its overall points were actually very accurate. That's what I initially thought. But how can the overall points possibly be right if they lead to exactly the wrong conclusions in most or all of the specific examples? At best the part you quote is vacuous and unhelpful for actually making technical decisions.
As best I can tell when you call his point "vacuous" you mean you think it's too abstract to be practical. I disagree.
What I take a away from his article is:
- Before you build something, ask yourself "Is this REALLY a technical problem? Or is it better solved non-technically?"
- What are the costs, especially complexity, of this change? Weigh those against the benefit.
Seems concrete and useful to me.