51–60 of 162 posts
Earlier quoted context omitted.
Have you seen the mkdir world view? It's the one where all the code is spread out over as many directories as possible, and leaf directories typically have no siblings just yet and one child.
Is this a particularly egregious worldview that should not be tolerated?
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…
Have you seen the mkdir world view? It's the one where all the code is spread out over as many directories as possible, and leaf directories typically have no siblings just yet and one child.
It is nice when it works but a real pain in the ass any other time.
Software is art, fashion and politics.
Except not the first one.
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.
Earlier quoted context omitted.
Good software solving an interesting problem can be art.
Got any examples? I'd love to see them. Something that's beautiful in its problem set (doesn't, for instance, act as glue between other, poorly designed systems and thereby reflect their flaws), beautiful in its solutions (doesn't solve too much, nor too little, doesn't make too many assumptions), beautiful in its use (user experience, performance, etc.), and beautiful in its implementation (quality under the hood, n…
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?
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…
Two examples:
In designing an email templating system, I've seen junior engineers devise really complex class hierarchies, with super classes that take in type generics for their super() constructor, three levels deep, resulting in hundreds of lines of code. When pressed, the reasoning was "there are parts of the email body we want to be the same and parts that are different, so the class hierarchies map to those parts that are similar vs different." It turns out, this service was only sending 3 different email "types" for the foreseeable future, and the only similarity between them was a copyright notice at the bottom, a banner at the top, and a body.
But, a counterpoint: For a long while, on some node.js backend API we were writing, much of the core business logic was implemented as simple functions across hundreds of files. Worked great when we had four API routes. Now, with hundreds, its impossible to find anything, because there's no structure, patterns, or organization. So, we needed someone to step in and introduce rules and structure in order to make the system more simple, and our job would have been easier if we'd had the foresight to see that necessary complexity coming.
I have seen this with procedural programmers struggling with OO code. OO programmers struggling with functional techniques. Programmers of all kinds seeing a new framework. Programmers used to more structured code trying to fix shell scripts. React developers encountering code using older JS libraries, and developers comfortable with older libraries encountering React. And so on and so forth.
In all cases the common denominator is that the programmer is uncomfortable with the new way of doing things. And the first reaction is, "What's wrong with this code?" And "It's messy and complex" is one of the easiest conclusions to draw.
Earlier quoted context omitted.
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 tend to observe that junior engineers simply misplace the level of complexity that a system needs in order to be as simple as possible. Meaning, I've seen errors to the side of being too simple, and errors to the side of being too complex; the unifying theory here is that its a mis-estimation of "necessary complexity". Two examples: In designing an email templating system, I've seen junior engineers devise really c…
And #1 is funny because we've all done something like that!
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…
"It's more complex to write unit tests/write this so it's easy to unit test, so I won't bother".
"It's more complex to spend a few days thinking through the design of this system, so I won't bother."
"It's more complex to write this in a way that can be subclassed later, so I won't bother."
Perfect may be the enemy of good, but "easy" can also be a foe.
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…
This is why I prefer to use singular they instead. It is less annoying, less likely to make people uncomfortable, and can easily be seen to include people no matter what their gender happens to be. It even includes those whose gender is ambiguous in some way.
It is a small thing, but my world view is that small improvements like this add up to create a more generally welcoming atmosphere.