This makes me miss my early days of programming, where no code was too verbose or horrible to stop me from progressing towards my goal, no matter how misguided I was. Nowadays I'm distracted by the first hint that there might be some better way, and all progress stops. I think I'm just beginning to recognize this, and maybe one of these years I'll learn to recognize when the right abstraction is really important and…
Premature abstraction is generally worse than immature abstraction. Write the most straightforward thing you can, and wait for that feeling that it won't work out. Then, ignore that feeling until you get proof. If you've kept your code simple and clean reacting to a lack of abstraction is relatively easy, at least compared to what digging yourself out of the wrong abstraction is like.
TerrariaClone – An incomprehensible hellscape of spaghetti code
211–220 of 289 posts
Re: TerrariaClone – An incomprehensible hellscape of spaghetti code
#212Earlier quoted context omitted.
As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my project's function than the structure of the team. There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. I now favor code that has…
> allows programmers, these very territorial beasts, to have their own little realms they control My 25 years of programming experience says otherwise. The only place where this works is with good(ish) programmers who are assholes and must have their huge, fragile egos stroked or they'll throw a diva fit. I don't hire or work with those people anymore. Neither should you. Joint code ownership produces better code bec…
>>> they'll throw a diva fit
? I'm not a native english speaker and although I get the general feeling, I don't get the exact picture this should paint in my mind... (and I bet it should be a funny one)
Re: TerrariaClone – An incomprehensible hellscape of spaghetti code
#213Earlier quoted context omitted.
I agree that my wording maybe gave a wrong idea about the strength of the "ownership". Code has to be readable and commented and peeking into each other code is welcomed, calling for help or reinforcement on a module is recommended. "Realms" is something that is unenforced and that emerges implicitly. On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables nam…
> On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. It leads to never-enforced style rules that no one likes nor follows. Seems less a problem with joint ownership and more a problem with poor leadership.
Re: TerrariaClone – An incomprehensible hellscape of spaghetti code
#214Earlier quoted context omitted.
> allows programmers, these very territorial beasts, to have their own little realms they control My 25 years of programming experience says otherwise. The only place where this works is with good(ish) programmers who are assholes and must have their huge, fragile egos stroked or they'll throw a diva fit. I don't hire or work with those people anymore. Neither should you. Joint code ownership produces better code bec…
People need that feel of "ownership", not based on who made something, that's really bad and lead to "not touching Joe's code, no f way", and probably what you said... But there needs to be a "Joes is responsible for the well functioning of microservices X1, Y2, Z3" - even if there may be 5 other people working on these same and others. Also, people's "fragile" egos can be turned to your adavantage, as a manager or o…
That implies that Joe has some kind of authority over the 5 other people, I hope. Otherwise that sounds like a "responsibility for blaming only" situation.
Re: TerrariaClone – An incomprehensible hellscape of spaghetti code
#215Earlier quoted context omitted.
> allows programmers, these very territorial beasts, to have their own little realms they control My 25 years of programming experience says otherwise. The only place where this works is with good(ish) programmers who are assholes and must have their huge, fragile egos stroked or they'll throw a diva fit. I don't hire or work with those people anymore. Neither should you. Joint code ownership produces better code bec…
I agree that my wording maybe gave a wrong idea about the strength of the "ownership". Code has to be readable and commented and peeking into each other code is welcomed, calling for help or reinforcement on a module is recommended. "Realms" is something that is unenforced and that emerges implicitly. On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables nam…
That is not my experience. Sure, there will be some bikeshedding in the code reviews, but you get rid of most attack surfaces by agreeing on lint/formatting options and just delegating the task to a tool. For me, proper whitespace formatting was whatever gofmt spat out. Later clang-format with the agreed team-wide options and currently pretty-js. The team can instead focus on more important code issues like the overall structure or bugs in the reviews.
> It leads to never-enforced style rules that no one likes nor follows.
If no one likes, enforces or follows them, you can't really call them rules. If it is the mutual understanding that some style aspects are not relevant, what's the problem keeping it that way? There is no need to let that get in the way of enforcing some aspects of style in order to produce code that anyone in the team can easily work on.
> In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API.
IMO one of the best ways to train a new programmer is to have them work closely with more experienced people and with the same level of review scrutiny. I don't know about the project you are working on and its timeline, but in the long term I believe this pays off by turning newbies into good, independent programmers that produce readable and idiomatic code. And no one needs to argue about minor formatting details with the tooling available today. It's a self-imposed waste of time if anything.
Re: TerrariaClone – An incomprehensible hellscape of spaghetti code
#216Earlier quoted context omitted.
Holy shit. Be sure to read the issue. It turns out it's not really a joke - someone in the know points out that Terraria's code is basically the same quality, if not worse...
You used to be able to decompile Terraria into perfectly readable code, since its c# and they didnt use an obfuscator. The code base was atrocious, but it is impressive that they got something working, and pretty fun, together as quickly as they did. These days there are a fair amount of production Unity games out that you can extract full sources for.. Can make for a fun read sometimes.
Re: TerrariaClone – An incomprehensible hellscape of spaghetti code
#217This makes me miss my early days of programming, where no code was too verbose or horrible to stop me from progressing towards my goal, no matter how misguided I was. Nowadays I'm distracted by the first hint that there might be some better way, and all progress stops. I think I'm just beginning to recognize this, and maybe one of these years I'll learn to recognize when the right abstraction is really important and…
As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my project's function than the structure of the team. There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. I now favor code that has…
Is this necessarily a bad thing? I know this quote and it always made a lot of sense for me. But I never understood where exactly is the problem, and why one should go to great lengths to avoid this.
Moreover, in this concrete example, isn't assigning modules to individual developers (as opposed to collective code ownership) essentially the same? i.e. structuring the code along the organization communication structure?
Re: TerrariaClone – An incomprehensible hellscape of spaghetti code
#218Earlier quoted context omitted.
Until someone goes on vacation, their area blows up and everyone else has to panic fix some code that they've never seen before. As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 and scheduling vacation time so that we always have full coverage should stuff go down. There's a huge difference between a silo and giving someone responsibility for driving the design of a component…
There are infinite ways to organize teams so your concerns are addressed. For example, you can have primary, secondary, and backup developers for each component of the system. That keeps you bus factor down and makes it more clear what the progression of responsibility looks like. But, absolutely, a lack of peer review, authentic feedback, and general teamwork causes all sorts of issues in so many ways.
Small nitpick: I assume to wanted to say this keeps your bus factor up.
Re: TerrariaClone – An incomprehensible hellscape of spaghetti code
#219Earlier quoted context omitted.
As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my project's function than the structure of the team. There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. I now favor code that has…
> There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. Is this necessarily a bad thing? I know this quote and it always made a lot of sense for me. But I never understood where exactly is the problem, and why one should go to great lengths to avoid this. Moreover, in this concrete ex…