The blank canvas analogy is a good one but for the wrong reason. Think of the aspiring novelist with a blank stack of paper in front of them. The problem is not the freedom they have, it's their lack of discipline. It's far easier to write PR for an agency or injury reports for a sports blog than it is to write a novel.
The reason so many programmers struggle with this problem is because nobody is paying them to write CRUD applications in Haskell. If they were, they'd find it more than adequate to the task and the job would be easy and painless.
People only go down rabbit holes when they don't have a manager breathing down their neck all day. It takes real discipline to create really good hobby projects on your own, regardless of language.
> People only go down rabbit holes when they don't have a manager breathing down their neck all day. It takes real discipline to create really good hobby projects on your own, regardless of language.
I agree, but perhaps discipline is not necessarily complete restraint... I think some rabbit holes are worth exploring, they can separate outstanding projects from mediocrity. Perhaps it's about choosing the right rabbit holes in the right projects, another way of achieving that is minimalism where you limit the scope and not the depth.
Or you just fail due to your own miss-management more than just once, and learn that structure is not for the boss but for you, yourself. Happens more often when the style of abstraction is restricted for performance reasons (i.e., no java-like OO and so) and you fall on something like buffer mismatch like I once did (to e fair, it was a bug that repeatably depended on the presence of explicit synchronization calls and there was no documentation about that possibly changing anything).
It takes experience to get a sense of where to spend that time. There are parts in any project that are write only fluff that will not be changed or extended much once written. Then there are the others where you know that things will need to grow and change a lot. There, it is incredibly important to find a good starting point fron which the code can grow with as little pain as possible. A day or two to find the right approaches there can pay off nicely.
how to build the foundations of an everchanging building in an everchanging environment.
not specifically directed to the parent comment, but it lead me to write this:
I think the discussion here is too focused on business/productivity. I feel like different people have different approaches to coding. Some of us really need to write beautiful code, and we are ok with "wasting" a lot of time thinking about fluff until we recognise that it really is fluff, or come up with interesting ideas simply because we spent time thinking about something. Maybe you care about the end result, maybe you care about the code, maybe you care about both. And even when you care about one or another, you do it in different ways. We start optimizing algorithms, then we build frameworks and "optimize" workflows, and then we want to optimize the approach to coding. But I don't think that's universally doable as with algorithms. We end with great insights and confused discussions.
That clicked a lot, the first sentennce, if code architecture is like a building with many extra dimensions then programming has this quantic challenge of getting beyond the fourth dimension of time to an intuition of how to build the foundations and subsequent DSL design levels of the code building's own future state, as if the future state exists in the present along with all other possible building states (that fit project[ed] constraints), since time is not a restraining cognitive concept in those higher dimensions of architectural mathematic representation.
I like playing with ideas and code as much as the next guy. But I have this distinction between things I do to learn and things I do to create results useful for others. For the later I need to find efficient ways to create what I need to create or I will take too long and the need is gone and my time is wasted.
Ultimately I want to be able to tell the world that my work had a positive impact in some form. I do not want to be the guy who did useless things. This is my main motivation these days.
> The reason so many programmers struggle with this problem is because nobody is paying them to write CRUD applications in Haskell. If they were, they'd find it more than adequate to the task and the job would be easy and painless.
I get paid to write applications in Scala that are often mostly CRUD. The temptation to overengineer is still there and still constantly needs to be fought.
I've seen the same thing happen in plenty of Java codebases too, mind. There it tends to be less "make this work for any possible Monoid" and more "make it work for any imaginable form that the user might want to build", but I think it's another facet of the same issue.
> People only go down rabbit holes when they don't have a manager breathing down their neck all day.
I've experienced this first hand. If I can't find a basket of Easter eggs within the 30 minutes of my journey into a rabbit hole, I have to backtrack and move on to something else. I do not feel this limitation when I'm at home, doing things on my own volition.
Better than a manager, is a customer. Though, any stakeholder is probably better than none, which I believe is your main point. (And one I agree with.)
I've always found interacting with clients to more satisfying than interacting with a manager. Managers have a probability of feeling like unnecessary middlemen, which presents a conundrum because they are your manager.
The reason so many programmers struggle with this problem is because nobody is paying them to write CRUD applications in Haskell. If they were, they'd find it more than adequate to the task and the job would be easy and painless.
People only go down rabbit holes when they don't have a manager breathing down their neck all day. It takes real discipline to create really good hobby projects on your own, regardless of language.