It's been a while since I dived into reading a Ph.D thesis... I bumped into that one through an article which was trying to summarize it but I wasn't super happy with it. That's why I decided to go to the source.

It's an interesting read, it has the benefit of making a clear difference between complicated and complex from the get go, which is welcome (generally a good sign for me).
If you want the tl;dr it's at the end of page 16:
"we found that differences in architectural complexity accounted for differences in developer productivity of 50%, three-fold differences in defect density, and order-of-magnitude differences in staff turnover".

Note the last point about the staff turnover should be taken with a grain of salt though. It is well explained in the limitations of the study, being a lot in the high complexity areas of the code can also be a sign of higher skills and thus more job opportunities.

Anyway, I think we all suspected some link between complexity and productivity but I always wondered how much. Seeing how the study was done it's definitely not an absolute answer (very thorough and precise, even historical data taken into account over several releases... but in a single company). Still the value is in at last giving us some rough numbers on how far the impacts can go. Thus, the scale of those impacts are potentially huge.

Maybe it's time to stop trying to find rockstar developers or mythical 10x developers (common "leprechauns" of our industry)... Let's focus on tackling undue or uncontrolled architectural and code complexity instead, shall we? Even better if that's done through the use of documented patterns when applicable.

Interestingly, the literature review part gives a few clues about why there is under-investment in architecture in general, or reworking the architecture on long term project. It's unclear to organizations the costs of the undue complexity will carry. It's exactly what this thesis tries to shed light on (see tl;dr above).

Also, it's interesting to see confirmed that the perception of the architectural complexity we have is often wrong when looking at parts in isolation. The relationships need to be transitively mapped to start to grasp the presence of architectural complexity. That's why only coordinated efforts can tackle it, it's almost impossible to tackle for a single developer.

Of course I'd advise reading it in full, that requires investing some time into it though.

Very stimulating, I'd like to apply some of those tools on projects in the wild but I'm not sure there are ready made tools available. Also I'm wondering what we would find if I'd reuse some of those in ComDaAn to work on temporality of changes rather than dependencies. I think this could give interesting insights.

Interesting way to frame the potential problems around organizational culture. This indeed influence behaviors quite a bit so should be in check. It also shows it's a complicated problem you don't want to overdo it, freeze the culture in place, and see it used mainly for blaming... it'd effectively turn into a cult.

Une histoire édifiante sur le sexisme ordinaire... et tout le monde regarde ailleurs.

Interesting, this seems to empirically confirm the Peter Principle, at least in sales. Also shows that companies are trying to workaround it. Dual career ladders seem to be an interesting path for this.

The report is very US centric. Still it looks like the future standard for developer jobs will be more and more remote.

Hiring and interview isn't simple. There are good advises in this piece. In particular I strongly agree with the fact that leet coding is probably not it and that having something guided and scripted it necessary.

This is a sound advice, it's better if it's a conversation. Some companies push for that some don't. If they don't the proposed plan is a good one.

It's coming from the job interview domain... but I wonder if it could be more largely useful due to how simple it is (but not easy mind you). I guess I'll experiment with it for my next project postmortem.

As I could experience both, I concur. Anniversary reviews are just much better for everyone involved.

Interesting career ladder example. I especially like the various dimensions they focus on.

Interesting set of tips for interviews. Definitely inspiring to dig deeper on a candidate motives and behaviors.

A very important and unfortunately underestimated factor for a sane and welcoming culture.

A very good list of criteria... Definitely questions we should ask ourselves regularly to know where we stand.

OK, that's an interesting approach to the note taking during interviews. I'm a bit far from that which is fine... and still that gives me ideas for improvements.

I so much agree with this. Interviews are just better one on one. Mind the stress of the candidate.

Since I keep telling candidates interviews are also for them to know the company before hand, I welcome this kind of list. I'd like to have more candidates ask some of that. :-)

OK, if true this is indeed an interesting test... kind of a social experiment really. Probably quite a bit ambiguous though.

About growth again, definitely from the point of view of the mentee though. This looks like a nice and lean framework to figure out where you are and where you want to go.

Lots of nice advices, both for mentors and mentees. This is definitely hard work but it's worth it for people to grow.

Good set of advices on how to deal with someone quitting the company.