The great team would not have written the Amazon clone in Fortran. There is no engineering justification for such a choice, and "we are swaggeringly awesome engineers who can conquer anything" is not even remotely an engineering justification.

▲

jll29 3 days ago | parent | next [-]

The parent article's point, though, is that choice of programming language is often NOT driven by justified choices, but is a foregone conclusion because it is part of the identity ("I am/want to be a XY developer.") of someone influential (e.g. tech lead, CTO, VP Eng).

One argument I would like to add to this original debate is that I have observed two types of developers: one type tries to stick to one programming language for everything (e.g. Java) and tries to write everythin in that language. They are specialist and they may accrue deep knowledge of the language versions, APIs and IDE(s). Another type of developer, in contrast, maintains active knowledge of a dozen programming languages (C/C++, Java/Kotlin, Python, bash, Rust, Go, PHP, JavaScript, ...), and is capable of delivering projects in each. They'd pick a language suitable for the task and stick with it for a project. They won't know any single language as intimately as the first type, but they benefit by virtue of their choice of language being more appropriate to the given project.

	▲	bdangubic 2 days ago \| parent [-]
		keep in mind though that size of the organization/team/... matters greatly. I have been involved with tens of projects over the course of my career (3 decades) and have encountered numerous scenarios where the choice of languages/technologies/... is already made, company-wide. I have seen this especially in companies that do a lot of contracting work. If apps are built say on top of springboot services and angular front-ends and we have 200 developers that specifically learned and know those technologies (along with myriad of internal libraries etc built on top of those technologies) swapping people between the projects becomes a non-event (or even adding few bodies to meet deliverables).

▲

bluGill 3 days ago | parent | prev [-]

If you are starting from scratch fortran is a bad choice. However if you have a fortran project that keeps getting more features you may become an amazon clone along the way

	▲	bdangubic 2 days ago \| parent [-]
		I was of course being facetious mentioning fortran but given a choice between working with an amazing group of people on a project which has a completely wrong tech/frameworks/... stack for the job at hand (e.g. fortran to built an e-commerce website) vs. working with average/subpar team utilizing some amazing stack, I'd choose the former any day of the week and twice on Sunday