Vincent Tunru @vinnl@mastodon.social

I wonder what percentage of user stories ever written have had more than a cursory thought spent on the "As a..." and especially the "so that..." parts?

For me, programming is acknowledging I make lots of mistakes, and putting up a lot of guardrails for me to bump into.

I'm currently discovering (and fixing) non-trivial bugs in obscure edge cases using property-based tests — once that's done, I'll be *very* confident it'll be working as intended. Fun!

Extra important because this is access-related code, i.e. at risk of privilege escalation.

Can highly recommend fast-check for writing property-based tests in JavaScript: https://dubzzz.github.io/fast-check.github.com/

It was indeed a recruiter, good job Fediverse! (Though I'm sure the fact that I wouldn't have posted this if it wasn't a recruiter played a role…)

Either way, responding to this message is bound to be a surefire way to land a job with interesting and diverse colleagues, don't you think?

https://mastodon.social/@vinnl/105786602564673149

Got a message from someone saying she "would not forgive [herself] for not making a move on me", and that she'd "love to make time to (virtually) have a cup of coffee together".

Pop quiz! Was this…

This is also a great attitude:

> Be prepared for your feedback not to be acted upon

If you're the one who's going to have to maintain the work, of course your input matters. But sometimes we're wrong, sometimes it's just Not That Important. There's no need to "win" everything.

This is a great point:

> It might feel to them as you're criticizing them personally, and it takes a lot of effort not to take the criticism personally. Honor that effort by making it easier not to take it personally.

Sure, it'd be great if people would try not to take things personally — especially if it wasn't intended as a personal attack! But we're all human and imperfect, and by taking the small effort of being mindful of that, feedback can be so much more effective.

Some good nuggets in this article on giving feedback: https://www.virginiabalseiro.com/blog/how-to-give-feedback

I want to support decentralisation, but I also want to have some confidence that a Mastodon instance will be around in the somewhat longer term.

Thus, I was thinking about moving to #Fosstodon. Anything to be aware of?

For example, there were a number of typo's in the original that I wasn't able to fix, because lockfiles weren't a thing in the JS ecosystem back then, and I could not figure out the right combination of dependencies to properly build it!

I built the original in 2015 with a number of learning goals, among which were actually finishing projects, and React. Over the years several people have taken the effort of actually reaching out to me to share how it's been helpful to them, which has been very gratifying.

Rebuilding it was a good way of reflecting on both how much I've learned since then, and how much our tooling has improved.

I relaunched my #Git tutorial! It gets you from being able to use Git to actually understanding it in less than fifteen minutes.

It is now also usable on smaller screens, looks a bit more modern, and is now up-to-date with modern Git features and conventions.

Git it a try at https://agripongit.vincenttunru.com

Arguing against either ignoring real-world use or ignoring future maintainability often gets you lumped in with "the other side", but... It's a spectrum, people!

Discuss user experiences and implementation trade-offs, then find the middle ground you're comfortable with.

If a piece of software can be expected to evolve in a certain direction, then make your code flexible enough to accommodate those changes.

But if there's straightforward code that supports all real use cases, then please avoid the overhead of more modularity.

Sometimes it feels like there are just two types of developers: the architecture astronaut who over-engineers the simplest problems, and the code cowboy that always takes shortcuts to solve the problem at hand while ignoring maintainability.

But you need a bit of both!