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.
Comment on What are some common misconceptions about programming that you'd like to debunk?
stevecrox@kbin.run 4 months ago
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 medts 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.
LoamImprovement@beehaw.org 4 months ago
abhibeckert@lemmy.world 4 months ago
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 adopting them? Very very rare.
stevecrox@kbin.run 4 months ago
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.