This is my creed:
If my solution is going to require a course to be understood then I have failed writing clean code.
Obviously, junior engineers might actually need a course, but from mid-level up, great code seems trivial without falling into the many pitfalls of software engineering: spaghetti code, overreliance on 1 vendor, fractional responsibility (where bits of a feature is implemented in unknown number of places), high cognitive complexity, rigid structures...
My wife is not a software engineer so it was quite telling she immediately understand my above statement: "But if it needs a course then it is bad UX, right? What are they building? Excel?"
But what is "mathlightning"?
Mathlighting is when your complaint about a hard-to-read, counter-intuitive or overcomplicated programming language/framework/library gets a lecture about "theoretical superiority".
They sound a bit like this to me: "I am willing to sacrifice project velocity and performance on the altars of theoretical benefits."
It is you who don't get it, but you should learn it. They are theoretically correct after all!
Time and time again, I see this in workplaces. Someone sees the usability problem, the other repeats the marketing claims that sound a bit like it is from a university lecture or a book, then the person who raised the concerns no longer wants to look stupid, so the entire team commits to "not getting it", but together. Productivity lowers, bugs are hard to fix (remember you never fully got it), people lose their minds over fixing a "theoretically" damn simple form.
There's an interesting cross-cut with Impostor Syndrome here: people are stressed not to look stupid by not understanding something. There are also people (quite rare in my experience) who loudly and proudly don't even try. This is a tough cookie, so I'll roll out a couple of examples in the hope it helps.
React and Redux
My quite high sample anecdotical evidence (please note the conscious play on opposites here) is react. Getting the parts that really make or break performance and clarity is very hard. People usually get to useMemo, useCallback and useEffect and then tune out and ship features. People usually don't get to learn in how many important cases are these unnecessary.
Early version of redux is generally hated in places where I worked at: the fact that all state and action logic is so scattered makes it really hard to understand the flows. Again and again, people get to about 70% of it and then they just hope for the best.
One can make a point here: the majority of software engineers are not up to the task. Or one can make another point here: your abstractions badly need some iterations until they make sense - after all, we must design for the average or even for those who struggle (see also: https://universaldesign.ie/about-universal-design).
For example I always struggled with redux but getting overmindjs right was super simple. The latter was an iteration over redux where the UX was done well.
Other Examples
"Of course it is hard to get it at first, but writing your code in 6 separate layers like this will eliminate side effects, which are mathematically proven to be bad for your code!"
_ “Elm’s statically-verified type system ensures that your entire application logic is captured as a series of pure, deterministic transformations, eliminating whole categories of runtime failure. No NullException means no crashes, right?”
Well, my friends, the real deal in my opinion is not a null exception, which are usually quite easy to debug; it's hiding error messages. Once an error message was swallowed you're set up for a terrible fight as it resurfaces elsewhere masquerading as "something else's problem".
I say it again: unless you must have mathematical correctness, code clarity >> theoretical superiority.
If people spend on average 3x more time on your code you are going to be 1/3 productive; or less, since frustrating humans usually results in giving up, or in rageful corner-cutting actions.
Any language or framework must work a lot on making sure it is ergonomic to the human brain.
Top comments (0)