231–240 of 289 posts
This makes me sad. Not because of the code quality, but because it makes me think of all the games I used to write back in middle school that are now lost to the swirling sands of time. The youngins don't know how good they have it with github!
Earlier quoted context omitted.
There's a tension between "everyone writes some of it" and individuals having autonomy to focus and make decisions. If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors. In this process, peopl…
If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. Being free to do things your own way often means choosing not to do something if it's going to negatively impact other people. Once you realise that you need to think about the way your decisions impact other people you quickly realise that compromising on your cho…
This becomes more and more important as the team grows, as there are more feet that you can step on. Working on a large team is really different than a solo or small team. Large teams are as much about communication, mutual respect, and shared goals than writing good code. Unfortunately, communication takes time and energy, and necessarily slows down the entire process, but it's critical.
The Mythical Man Month lays this out nicely. The possible lines of communication in a N person team grows quadratically at N*(N-1), which explains why large teams are often far less efficient on a per-person basis than smaller ones.
Earlier 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…
There's a tension between "everyone writes some of it" and individuals having autonomy to focus and make decisions. If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors. In this process, peopl…
A flat fully connected hierarchy is better for small groups, but it doesn't scale well as the number of lines of communications is proportional to the square of the number of people.
12 months forward I had made my first "commercial" product - Power Crypt. A Windows application allowing to encrypt / decrypt files. It as written in Delphi, had a single class of ±5000 LOC and used open source cryptography library.
Main selling point was that it encrypted a file not by using a single algorithm, but with all (about 10 or even more) the algorithms the OS library had implemented. Thus making it more secure :-)
Earlier 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…
There's a tension between "everyone writes some of it" and individuals having autonomy to focus and make decisions. If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors. In this process, peopl…
Earlier 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…
Earlier quoted context omitted.
There's a tension between "everyone writes some of it" and individuals having autonomy to focus and make decisions. If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. To solve this, you normally end up with a hierarchy of authority, where most people have to have their work vetted by seniors. In this process, peopl…
If everybody has autonomy in a shared codebase, you end up with a heterogeneous spaghetti of unrelated design decisions and styles overlapping everywhere. Being free to do things your own way often means choosing not to do something if it's going to negatively impact other people. Once you realise that you need to think about the way your decisions impact other people you quickly realise that compromising on your cho…
Reminds me of a rather insightful comment from a Hackernews a few years ago [1]: > People write MLOC monstrosities in Java because they can. You get some boring financial topic and some sub-par programmers and they'll write as much garbage as the language can possibly sustain. > These things are a testament to how safe and simple Java is as a language. > Not having massive crappy code bases is a negative sign in term…
I think that has a lot to do with the IDE as well. When I'm using Visual Studio, I autocomplete and peek until I find something that even remotely does what I need in the library and move on. I come back and optimize when I see smoke coming out of the CPU or my project manager :) (Of course I'm responsible with my code and this is an exaggeration but could this be called "too mature optimization"? :) )
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…
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…
Earlier quoted context omitted.
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.
> That keeps you bus factor down Small nitpick: I assume to wanted to say this keeps your bus factor up .