Hacker News new | ask | show | jobs
Letting tools make choices (jackfranklin.co.uk)
47 points by jackfranklin 2344 days ago
7 comments

Akin 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.

[0] https://github.com/psf/black

I’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!

> 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.

I think those are very different cases. Knowing SQL is a valuable skill which I'm pretty sure almost all developers end up using at some point in their careers, whereas there's no value in being able to format code. Maybe that will change once we start seeing people who learnt to code with automatic formatters and didn't develop any sense for what good syntax looks like, but I don't think we're there yet.

If I can add on to this, I'd say it's okay for new devs to use a tool such as prettier without knowing how it works as long as they know what it's purposes is and why they're using it.

I remember when I first started programming I often used tools without understanding what they did simply because a guide or Stackoverflow answer recommended them. It led to a lot of problems down the road, e.g. Googling for "how to add two numbers using jQuery".

When I try to teach junior devs, I'll let them use User.find... as long as they understand someone else is writing the SQL for them and that it isn't some magic database tool ;)

Similarly, I am embarrassed for devs who type their code in a coddling text editor because they are too ignorant to use ed, the standard text editor, properly.

Computers are for solving problems, not helping programmers, after all, right?

My sarcasm detector just exploded.

It’s all a continuum. A great test for mid career programmers is solving a problem from a blank text file. Especially true for more languages with great IDEs like Java or C#

Interestingly, that’s how I started coding and I’m still young(ish).

Borrowed a book from the library as a pre teen and followed along using notepad on my dad’s computer.

I didn’t see syntax highlighting or autocomplete until I was much older. So I can see why some people nowadays aren’t concerned as much with things like indentation. Syntax highlighting adds another dimension of legibility. I couldn’t imagine coding a website even just in plain old html without good indentation if there was no syntax highlighting.

This 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.

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/

My org still uses RoR for nearly all our sites. I used to add a fair amount of custom config and gems, but more and more I find myself gravitating to the default stack. It’s just simpler, and easier on the next guy if I ever pass on a project.
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.
A 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.

A coworker from a previous job said something along the lines of “How much work is getting done by teams debating tabs vs spaces?”

That's a good question, but having agreed that such debates don't contribute much, you've got two ways to go: either enforce a standard, or "live and let live" (perhaps supported by strong-ish module ownership). I think it's unfortunate that the "live and let live" option seems to have largely fallen by the wayside over the past few years.

Great 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.

I 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.

It looks like a case of analysis paralysis. Customize on use, not upfront. When I write personal tools (throw-away scripts, more long-lived utilities etc.), it is not rare that I change my mind about how they should work after using them - even though I made each and every choice while coding them! You don't know what you need until you need it.