Letting tools make choices
jackfranklin.co.uk
Letting tools make choices
1–10 of 18 posts
Re: Letting tools make choices
#2Akin to his adventure, black [0] for Python does one thing and does it very well: It formats my code. It's pretty, it's legible, it's consistent, it works; and you cannot customise it. Has been a great experience since the day I switched from autopep8.
Re: Letting tools make choices
#3This to me is what I really miss about Ruby on Rails being a more popular platform, way more than any of the metaprogramming magic or super-readable syntax. It made a ton of choices for you, which helped with productivity on teams more than anything else.
If you had a new developer coming onto a Rails project, there's no need to ask how logging is done, where models and controllers were stored, what the naming convention of database tables were, how assets are compiled, where to find tests or how to run them, how to start your application, or probably a hundred other little tiny decisions.
Sure, you have less control over things, but 90% of the time, that control doesn't matter, and you're making life more difficult for every other person who will ever read your code in the pursuit of what's often purely aesthetic.
Re: Letting tools make choices
#4A coworker from a previous job said something along the lines of “How much work is getting done by teams debating tabs vs spaces?”
And it was in context of the decision being important but once it’s made just go write code and ship a product.
One of the many reasons I immediately fell in love with Go.
Re: Letting tools make choices
#5This to me is what I really miss about Ruby on Rails being a more popular platform, way more than any of the metaprogramming magic or super-readable syntax. It made a ton of choices for you, which helped with productivity on teams more than anything else. If you had a new developer coming onto a Rails project, there's no need to ask how logging is done, where models and controllers were stored, what the naming conven…
It’s the same reason I love Django (no tooling decisions to make) and hate “modern” JavaScript development (far to many options for small tools to construct a framework).
What is the opinionated framework of choice for front end work now? (Something that is all in like Django or Rails)
Re: Letting tools make choices
#6I’ve always struggled with this, on the one hand I recognize my productivity/efficiency increase.
On the other...
I feel like tooling that automatically makes decisions for you can be a crutch if you don’t take the time to understand it.
It might be me getting older/grouchier but watching a dev use black or prettier because they don’t know how/are too lazy to indent their code properly is frustrating for me.
Or when I see new devs pick up User.find(id) in rails and sticking to the ORM without learning a lick of SQL - I think to myself how they’re selling themselves short.
But then I think, what don’t I know that I’m selling my self short on? Do I really know precisely how database storage works? or FS operations? Do I know the HTTP spec to the letter?
And I settle on the following: Any level of abstraction is fine - just try to identify what level you’re on so you can go down if needed or up when a new level of convenience becomes available!
Re: Letting tools make choices
#7This to me is what I really miss about Ruby on Rails being a more popular platform, way more than any of the metaprogramming magic or super-readable syntax. It made a ton of choices for you, which helped with productivity on teams more than anything else. If you had a new developer coming onto a Rails project, there's no need to ask how logging is done, where models and controllers were stored, what the naming conven…
It’s the same reason I love Django (no tooling decisions to make) and hate “modern” JavaScript development (far to many options for small tools to construct a framework). What is the opinionated framework of choice for front end work now? (Something that is all in like Django or Rails)
Maybe Ember.js - https://emberjs.com
Yehuda Katz is Core Team Member of Ruby on Rails and Co-Creator of Ember.js https://yehudakatz.com/projects/
Re: Letting tools make choices
#8Great article.
In a similar vein, I first started with react years ago and spent MANY hours even trying to get the libraries working together. Complete nightmare. I put it down for a year or 2 until it matured to a level of stability that allowed me to ship without hassle.
In contrast during that time I picked up some Angular work which, because it was opinionated, was very very quick to get something up and running.
Re: Letting tools make choices
#9This to me is what I really miss about Ruby on Rails being a more popular platform, way more than any of the metaprogramming magic or super-readable syntax. It made a ton of choices for you, which helped with productivity on teams more than anything else. If you had a new developer coming onto a Rails project, there's no need to ask how logging is done, where models and controllers were stored, what the naming conven…
And the real magic is that if you really wanted that control back you can have it! Nothing stopping you from opening up a class and redefining a method for what you need.
Re: Letting tools make choices
#10I recently moved to a new team, and the project I've been assigned to was handcrafted and built by ‘gut feeling’. I'm not familiar with the tech and tools and I'm having a hard time getting onboarded.
I'm exploring the possibility to migrate the code to an opinionated framework that gives guidelines on how to structure your code. Some people feel very strongly about these, but I’ve been warming to the idea of just following directions, particularly for new techs that I am not familiar with. I rather focus on the logic of the problem at hand rather than deciding where to put what and how to structure things.