121–130 of 162 posts
Earlier quoted context omitted.
As mid level developers, how can we resolve this impasse?
There is no ultimate solution. Just continual efforts to make things better, gain deeper understanding, remove unnecessary complications, and improve overly simplistic solutions. If you were simply making a joke, forgive me =)
Since this seems to be the place for personal views, my views, after 20 years of experience, is that people do not notice the complexity of anything that they have digested as normal. As a result doing anything other than what they are used to seems very complex to them. Whether that other thing is actually complex to a neutral third party is situation and observer dependent. I have seen this with procedural programm…
people do not notice the complexity of anything that they have digested as normal ...which is why examples of "minimal complexity" code often provoke feelings of extreme unease and horror; one nice example is https://news.ycombinator.com/item?id=8558822 where the functionality:code ratio almost seems impossible at first glance. I have seen this with procedural programmers struggling with OO code. To be fair, a lot of…
And a lot of functional code tends towards unnecessary levels of indirection through higher order functions as a way of deferring responsibility for actual logic, or on the flipside insufficient abstraction leading to difficulty extending functionality.
I've gone back and forth multiple times between functional practices and OO practices, and I definitely empathize with the confusion going in both directions. You trade one problem for another, and in the end there really is no free lunch.
React Redux is a great example. People who have gotten over the hump of the boilerplate involved in threading state up and down the tree love how little energy they're spending routing state changes to the correct destinations. However, to someone who is used to event-based UI programming, this looks like a horrific waste of energy reminiscent of how a giraffe's laryngeal nerve goes all the way down the neck then back up. They've both got a point, but you have to follow their paths to see it yourself.
Earlier quoted context omitted.
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…
> 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…
There was not. This is a startup I'm referencing; we don't hold long technical planning sessions for how to design a few hundred lines of code. We'd likely hold a meeting on the product behind it, but that's not what we're talking about here.
Does that mean it was a failure of leadership? I'd argue No. I would argue that it might be a failure in mentorship, which is different, but in all the startups I've been in, there's one constant: Engineers have MASSIVE freedom and responsibility to get the product out the door. We don't micromanage the implementations. That doesn't mean they always turn out great, and that's where mentorship comes in; teaching how to fish instead of the seniors doing it for them.
> This feels like a false dichotomy to me. Your system existed in a state somewhere between between 4 routes and hundreds, didn't it? At the point something starts being painful is when it should be addressed, imo. That was probably somewhere in the teens of routes would be my guess. At that point the system is still small and understandable enough to make a large architectural change, but it's big enough that you can be reasonably certain you're making the correct large architectural change.
I think you're right. No one is perfect.
The reality of many startups is that the senior developers are vastly overworked. I mean, everyone is overworked, but at least in my experience, it comes back to the fact that the seniors can't micromanage everyone. So at some point, we were at a dozen routes, and it probably sucked to work in, but its likely that the seniors reviewed it and "missed the forest for the trees". Yeah, that code looks great, ship it, next feature, keep growing.
It takes a different, holistic perspective to see that the whole architecture is slowly getting bad, and often you don't experience that different perspective working in the weeds on each route. Combine that with the fact that startups tend to move REALLY fast, and an engineering department four the size still wouldn't have the capacity to take on all the feature work we want, let alone the refactoring, and its easy to understand why architecture gets pushed off.
Earlier quoted context omitted.
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 diff…
Earlier 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?
My maxim is "make it as complex as it needs to be, but not one bit more".
There is great satisfaction to be had from productively solving problems rather than endlessly "architecting" in futile search of the "perfect design".
Earlier quoted context omitted.
> 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?
Work on bigger problems that are a lot harder to solve. You cant mitigate for reality, but what you can do is offset its shittyness but taking on a project/task that yields results that are big and great enough to justify dealing with shitty systems/ heuristics to begin with. Just my 2 cents!
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…
> 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…
Edit: grammar.
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…
This strikes me as odd. You really sit there thinking "I need to make this complex"? Why not strive for correctness and completeness?
Earlier 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?
Also, take a break and do something that is not programming as a hobby. Demotivation is more of function of routine and lack of sensory input and less of practical realities.
Lastly, embrace the concept.