Technical Leads are not rational beings and lots of software is developed from an emotional stand point.
Engineering is trade offs, every technical decision you make has a pro/con.
What you should do is write out the core requirements/constraints.Then you weigh the choices to select the option that best meets it.
What actually happens is someone really likes X framework, Y programming language or Z methodology and so decides the solution and then looks for reasons to justify it.
Currently the obvious tell is if they pitch Rust. I am not saying Rust is bad, but you’ll notice they will extoll the memory safety or performance and forget about the actual requirements of the project.
I would amend that to “if they pitch any language”.
The best language is almost universally “whatever we already use” or for new projects “whatever the team is most familiar with”. It should occasionally be reconsidered, and definitely try out new languages, but actually switching to the new language after trying it out? That should be very very rare.
The team/organisations knowledge is a huge factor but its easy to fall into a trap where no matter what the problem is the solution is X language.
If I have an organisation that knows C# and we need to build a Web Application. I would suggest we need to learn Node.js and Typescript and not invest in a solution that turns C# into web pages.
Wait, are you seriously overlooking ASP.NET and suggesting c# tes learn typescript and node to build web apps?
I get that it’s a hypothetical, but typescript and node shouldn’t be the first stop on the we need to build a web page train for folks already in the c# wagon.
I know they make a joke about Tom in office space being the one who brings the specs from the customers to the engineers - as much as it looks like he’s dead weight, there really is a skill in being able to explore the customer’s needs (and frequently manage their expectations of what the proposed software should be and do) and parse them into something more technical for the engineers, because you might not know how to program, but you’ve got a good idea of what the capabilities are because you communicate with the engineering team on a daily basis.
Technical Leads are not rational beings and lots of software is developed from an emotional stand point.
Engineering is trade offs, every technical decision you make has a pro/con.
What you should do is write out the core requirements/constraints.Then you weigh the choices to select the option that best meets it.
What actually happens is someone really likes X framework, Y programming language or Z methodology and so decides the solution and then looks for reasons to justify it.
Currently the obvious tell is if they pitch Rust. I am not saying Rust is bad, but you’ll notice they will extoll the memory safety or performance and forget about the actual requirements of the project.
I would amend that to “if they pitch any language”.
The best language is almost universally “whatever we already use” or for new projects “whatever the team is most familiar with”. It should occasionally be reconsidered, and definitely try out new languages, but actually switching to the new language after trying it out? That should be very very rare.
The team/organisations knowledge is a huge factor but its easy to fall into a trap where no matter what the problem is the solution is X language.
If I have an organisation that knows C# and we need to build a Web Application. I would suggest we need to learn Node.js and Typescript and not invest in a solution that turns C# into web pages.
Wait, are you seriously overlooking ASP.NET and suggesting c# tes learn typescript and node to build web apps?
I get that it’s a hypothetical, but typescript and node shouldn’t be the first stop on the we need to build a web page train for folks already in the c# wagon.
I know they make a joke about Tom in office space being the one who brings the specs from the customers to the engineers - as much as it looks like he’s dead weight, there really is a skill in being able to explore the customer’s needs (and frequently manage their expectations of what the proposed software should be and do) and parse them into something more technical for the engineers, because you might not know how to program, but you’ve got a good idea of what the capabilities are because you communicate with the engineering team on a daily basis.