4 ms·
For personal projects, absolutely great advice. For any codebase destined for a team to develop, primary consideration goes to the technologies the team prefer
by cobbzilla 1y ago
For personal projects, absolutely great advice.
For any codebase destined for a team to develop, primary consideration goes to the technologies the team prefers, not my own preferences. Which makes for a fun guessing game when you’re green-fielding and before you’ve built the team.
- princevegeta89 1y agoThe vast majority of the teams I worked in, I got forced to use shithole technologies, with shithole tools, and as a matter of fact, forced to work on legacy codebase. The part with legacy codebases is a fact of life when working in teams at companies though. This is just my personal preference - but I tend to be affected by development workflows and developer experience profoundly and my output is directly proportional to that. I hate projects where testing workflows haven't been setup correctly or not set up at all. The last job I had was one where my team fucked itself up, along with our entire engineering org by setting up layers and layers of microservices and introducing unnecessary complexity hence making trivial changes hard to ship into production. What would take 30 minutes to debug ended taking days because abstractions between teams were not properly set up. Visibility into pipelines was severely lacking and it was all nothing but a circus shitshow. I tend to have the greatest happiness working on personal projects where I get to choose everything, so I relate myself to the post very much