Software Engineers don't have a tech stack - their projects do
I would rather discuss solving problems than just talk about "Stacks" in isolation
It's great to have favourites, and to be enthusiastic about specific tools - I do too, this is an important part of being a tech-nerd/hacker/programmer. But "Tech Stack" isn't an attribute of the person, it's an attribute of the project.
Yes, it takes some time to get familiar with a lot of tools/languages. But it takes longer to get up to speed with a specific business domain. Furthermore, most of the common programming languages are not really that different from one another*.
Let's talk about problems
If we have a discussion about tech, I want to hear about the problems you are solving and have solved, with technology as a tool to solve real-world problems. I also want to talk about the pros and cons of specific technologies, but not some pre-defined "stack" (and what you have achieved using technology is much more interesting than the simple fact that you have used it).
The choice of stack should be heavily driven by the business requirements, and should usually evolve over time, as requirements become clearer/change. Two examples of this from Mycs** are firstly, the shift from using NodeJS for backend services to building new ones in Go; and secondly, the addition of Redis in a complementary role, alongside Postgres. Both of these changes were driven by a need to scale, driven by changes in the business. The shift towards Go was also driven by a desire to make the codebase cleaner, more maintainable, and less buggy, but ultimately these are all in support of ensuring the system can continue to support an expanding business. Tech-Debt is a business issue too.
Solve Practical Problems
The most valuable asset of an Engineer is an ability to solve problems for people. We sometimes lose sight of this (at least I do), and focus too much on the tools and too little on the task.
A quote to end on:
Hey look, buddy, I'm an Engineer. that means I solve problems. Not problems like "What is beauty?", because that would fall within the purview of your conundrums of philosophy. I solve practical problems. - TF2's Engineer
Appendix - My Projects' Tech Stacks [Show]
Stacks I have used relatively recently:
- Haskell, Scotty, Postgres, JS, React, Linux
- Chicken Scheme, Sqlite, Linux (pure hobby project & therefore no real-world business constraints)
- Go, JS, React, MiniZinc, Postgres, Linux
- Go, JS, React, Postgres, Linux, NetSuite SuiteScript
There are patterns and preferences. But most of the language choices above were made within a business context and team environment, and in some cases (React), I initially had to learn them very quickly for a specific project.
All of that said, I am particulary keen on Haskell, Scheme, Go, Postgres, and Linux. So if you are also interested in these, feel free to reach out and say hi.
* Of the top 10 Stack Overflow 2022 Most Popular Languages, seven were hybrid languages with C-ish syntax, strong OOP support, plus between "some amount" and "a fair bit" of FP support.
read more...
The remaining three were bash/shell, HTML/CSS, and SQL (all of which are often used in conjunction with one of the other languages). The first language on the list (at 14th place) that probably requires a shift-in-thinking away from the C-Syntax+OOP+SomeFP hybrid paradigm to use, is Rust, which draws inspiration from languages like Haskell and OCaml, but is still a language with not-that-different-to-c-syntax + OOP support + FP features (PowerShell is at 12th place, but like bash, HTML, and SQL, this is usually an auxiliary language). There are important differences in type systems, but you need to understand what a type is, what different kinds of type systems are, and what implications this has, regardless of whether you are using JS or C++. If someone had only worked in dynamically typed languages, perhaps that would be a concern. But in the same way that you can't really understand what shade is without some concept of what light is, I'm not convinced you can truly understand either dynamic or static typing without understanding the other.** Mycs is a Berlin-headquartered custom furniture Start-Up (maybe now more of a Scale-Up!), with a Europe-wide presence. I worked for Mycs before I moved to Canada, and I recommend them as a place to work - I had a great time working for them in Germany, Poland, France, & the UK.