News for hackers. Stuff that matters.
Re:Designing very large JavaScript applications by simonw on Friday April 20, 2018 @04:49PM (#16888337)
I love Malte's take on what makes a senior engineer with regards to API design:

> The way I would talk about myself as a senior engineer is that I’d say “I know how I would solve the problem” and because I know how I would solve it I could also teach someone else to do it. And my theory is that the next level is that I can say about myself “I know how others would solve the problem”. Let’s make that a bit more concrete. You make that sentence: “I can anticipate how the API choices that I’m making, or the abstractions that I’m introducing into a project, how they impact how other people would solve a problem.”

Re:Designing very large JavaScript applications by aje403 on Friday April 20, 2018 @05:56PM (#16888742)
I think "How confusing is this going to be to the one consuming this" (assuming you're not writing the front end as well) is the more important question to ask
Re:Designing very large JavaScript applications by joeyespo on Saturday April 21, 2018 @11:22AM (#16891737)
This way of thinking was my main motivation behind Grip [0]. Use Readme-driven development and "play" with the API--whether it's in the form of a CLI, a library, or web API-- through usage examples.

I've found this to be a wonderful way to get into the heads of dev users before you approach them directly.

[0]: https://github.com/joeyespo/grip

Re:Designing very large JavaScript applications by abritinthebay on Friday April 20, 2018 @06:15PM (#16888827)
And the one most rarely asking in my experience too
Re:Designing very large JavaScript applications by silversmith on Saturday April 21, 2018 @07:44AM (#16891052)
In my opinion, asking this question is the key benefit of test-driven development. You get to be the consumer, write down your expectations, and then work backwards from yours-as-consumer expectations.
Re:Designing very large JavaScript applications by sbov on Saturday April 21, 2018 @08:02AM (#16891107)
I find the opposite tends to happen in Java. In the pursuit of testability, people make libraries much harder to use and understand.
Re:Designing very large JavaScript applications by purerandomness on Saturday April 21, 2018 @11:06AM (#16891681)
Writing good tests is a skill that has to be developed, just like anything else.
Re:Designing very large JavaScript applications by abritinthebay on Sunday April 22, 2018 @01:59AM (#16894913)
It should be, but too often people write bad tests that test whst they wrote and not what it’s supposed to do.

Writing good tests is a skill and most developers don’t seem to be as skilled in it as they think.

The same concepts power much of Agile too though: XP & Scrum both complement this.

Re:Designing very large JavaScript applications by dahauns on Saturday April 21, 2018 @10:42AM (#16891584)
Isn't that basically what he said? :)
Re:Designing very large JavaScript applications by sdrothrock on Friday April 20, 2018 @11:57PM (#16889908)
> I can anticipate how the API choices that I’m making, or the abstractions that I’m introducing into a project, how they impact how other people would solve a problem.

I feel like if you take "API" out of this sentence, this is really the benchmark for any senior developer.

Re:Designing very large JavaScript applications by jordache on Friday April 20, 2018 @07:03PM (#16889015)
yep.. a very refreshing descriptor of a senior level dev. It is also a very intuitive notion of the behavior of a senior level dev, even if not frequently articulated as such. I'm working with a fellow dev right now, where this notion of empathy is lacking.
Re:Designing very large JavaScript applications by jypepin on Saturday April 21, 2018 @02:10AM (#16890207)
Yes I loved it too, and it is super relevant. I've had my fair share of team swaps, both from backend to frontend, and it is always very interesting to see how engineers who have been on a specific team/role for a while tend to lack empathy and forget that other engineers who end up using their APIs don't share the same context and knowledge (or worst, sometimes it just comes from laziness).