Hacker News Reader

Comment by W0lf | Hacker News Reader

I never understood the argument of _helping fellow developers out_ by setting up their development environment or _lowering the entrance bar_ as everything got so complicated really.

For one, I personally cannot trust the technical competence of a fellow developer if he/she cannot handle their setup him/herself. We're talking installing tools by clicking around, aren't we? The same argument holds true for a fellow plumber that has never worked with this pipe system in particular.

Second, there's much to discover by installing and setting up everything by oneself. It can give insights on how things are connected to each other tool wise which is the first step of getting familiar with a new environment in the first place anyways.

View on HN

We're talking installing tools by clicking around, aren't we?

Not sure if you mean this literally, but I'd rather have a fellow developer who shows me an automated way to do (most of) this, meaning the devloper realized that switching to another machine would require figuring out and executing those same clicks again. It's like the discovery process you mention, but imo with deeper insight. Also because I've seen the other end of the 'oh I still need that thing let's point and click to install': co-workers needing multiple days to get their development environment setup. Or rather: thinking it's setup only to find out some days later the envoronment is so polluted only the correcct sequence of starting a shell and executing scripts leads to a build without errors.

I worked at a small Rails shop a long time ago. Everyone had their Mac setup differently (they each did the setup themselves), and nobody really knew how theirs was setup. Until something broke.

Development domain names - some people used /etc/hosts, some people used pow, others used PassengerPane. For packages, a few people used Brew, some used MacPorts...

In the end we went with a standard setup where I implemented things like rvm (we had both Rails 2 and Rails 3 apps). And even created a CentOS setup script which was as similar as possible.

A new developer of decent competence in your tech stack should be able to go from zero to first commit in a few hours. If that's not possible then you have a technical debt problem that's probably a smell for other issues in your code base.

Sometimes the complexity is unavoidable - e.g. loading some large training data set or a complicated tool chain of some essential libraries - in which case you should automate away as much as possible in build scripts. Sometimes the setup complexity is due to poor maintenance - "we used Gulp 3 years ago, but switched to Webpack last year, and the frontend guys are trying out esbuild, but there's still stuff that's running under Webpack and we need Gulp for these couple old pages over there". Either way, there's no better way to crush the enthusiasm of a new hire than have them bogged down in your shitty install setup on their first day.

"I cannot trust your competence as a developer if you can't build your compiler in assembly."

These setups are useful because:

- not everyone needs to start from scratch every time

- they share one’s known-how through their configuration

Even if I rarely use boilerplates and such, often they're good resources to see how a specific problem has been fixed.

Also if they're done well they lower the barrier of entry considerably. See create-react-app where you can start developing something serious in React without starting from an empty index.html and glue everything together.

Reply on news.ycombinator.com