Contributor Interviews – Angus

Site feedback
1

Every week, we’ll be posting an interview with one of our many beloved contributors here on Meta. Find them all in user-interviews. This week:

Angus McLeod @angus

Tell us a bit about yourself

Name: Angus McLeod.

Location: Currently, Perth, Western Australia.

Until a few months ago I was the Head of Technology at Knotel, a co-working space business in New York. I quit that to focus on building / starting a platform to provide civic and legal services online in any jurisdiction. Part of that involves building plugins for Discourse. It also involves a fair amount of research and thinking. I’m interested in any interesting ideas at the intersection of technology, public services and law. Previously, I studied law in Australia, the US and Singapore and worked for 2 years as a lawyer, before moving to New York and stumbling into a job at a little tech startup (there’s an interesting story there actually involving Craigslist, the Nuyorican Poet’s Cafe and transcranial stimulation) .

When I’m not working, I hike (I recently hiked around Yellowstone), I go to the theatre (I used to do some amateur acting), I go dancing and I’ve always read a lot. I’m currently reading Clarice Lispector and some short stories by Balzac.

How did you first find out about Discourse?

A co-worker told me about it in the context of discussing interesting open source projects.

What are you using Discourse for?

Partly as the core of the civc/legal services platform I mentioned, partly as a study of how and why people contribute to open source projects (more on that below) and partly as an example of best practices for my own development as a developer.

How did you get so involved in the Meta community?

By building a number of plugins, then ‘releasing’ them on meta.

What compels you to contribute to Discourse?

There are a few things at work here:

  1. I need Discourse for my own project, so contributing to Discourse (core or plugins) is contributing to my own work.

  2. Sharing your work with people and getting recognition for it is emotionally satisfying.

  3. Being part of project that involves respected developers, and is itself respected, is attractive.

  4. It has helped me teach myself how to code.

  5. Discourse produces social benefit by making it easy to start your own online community and by improving the quality of discourse on the internet. Contributing to Discourse helps to produce those benefits.

  6. It provides the context for showcasing some of my abilities to employers and / or clients. For example, I have used my meta profile and my work on my Discourse plugins as a reference for people I have been providing consulting services to.

Apart from 1, all of these benefits apply whether or not my own project succeeds. So even if that fails (which, if I am being coldly rational about it, it probably will), I would still have gained a huge amount by contributing to Discourse.

Tell us about a non-Discourse community that you’re involved in!

Here in Perth I’ve been going dancing socially - Salsa in particular - which has a community aspect to it. In New York, the co-working space I worked for had a significant community aspect.

While it’s a generalization, I would say that in-person communities are easier to get involved in in the US than they are in Australia. Americans love the idea of ‘community’ and ‘groups’. They like to participate (and to be seen participating). Australians can be a bit more reserved about ‘participating’, particularly Australian men. Part of that is the difference between a big city like New York and a smaller city like Perth, but it’s also partly a reflection of culture.

The culture around ‘community’ is different again in Asia proper. I lived in Singapore for a year while studying at the National University of Singapore. Singaporeans are also ‘joiners’; they love to participate.

What kind of significance does the open source movement have to you?

The relationship between the open source movement and the business side of the tech industry is unique. No other industry has such an integral relationship between communitarian and capitalist values. The open source movement would not exist in the form it does without being subsidized by relatively high wages and significant capital generated by tech businesses, but nor would tech businesses be nearly as successful or socially influential with the foundation of open source that underlies and infuses a lot of commercial technology. This kind of symbiosis doesn’t exist in any other industry. One of the things I hope to do (in life) is to translate the ethos and practice of the open source movement into other industries, in particular law and public services. Communitarianism and capitalism need not be mutually exclusive social forces.

What has been the greatest challenge in learning about Discourse and its community?

For me Discourse is intertwined with learning how to code, so when I think of its challenges I normally think of times when I was stuck trying to figure something out for days hitting my head against the wall (metaphorically speaking).

I’ve never had a serious issue with the community or anyone in the Discourse team. I’ve had moments of minor exasperation, for example when the codebase changes and breaks all my plugins, but this is always minor. I think I have a decent sense for what drives Discourse as a company, and the folks who run it, and it makes sense to me.

Any ideas on how to improve the Meta community?

We encourage respondents to speak candidly on this topic. Even if no sensitive information was discussed, answers will always be presented in a short list.

  • Better representation of female and minority voices.

  • User-to-user (i.e. non-team) interaction could be a much bigger part of meta.

Any advice to future contributors?

If you’re working on a plugin, release v0.1 when it is 90% ready. It needs to actually work, but you shouldn’t aim for the same level of perfection that core Discourse itself attains, at least in v0.1. Otherwise you will spend disproportionally more time on that 10%, and you may never release it. Moreover, you will find flaws quicker and sometimes you will realize you need to re-think the product logic once other people have played around with it.

Another thing to keep in mind when developing a plugin is how generalizable your code and the plugin functionality is. Generalizability / flexibility can often come as an afterthought, but it should really be at the front of your thinking from the very beginning because it changes the way you code. In particular:

  • The more you can abstract logic into isolated functions, the better.

  • The more you can use existing functionality from core Discourse, the better.

40 Likes
2

I came here to say I greatly enjoy your contributions, thanks! :heart:

While I’m here, I also do have a question, I often read the code of your repositories and noticed you almost always write ruby specs and no js tests, any reason to this? Personal taste? time? difficulty to write them? Something we could do to facilitate this?

12 Likes
3

Basically I found the process of writing js tests for the elections plugin to be quite frustrating, so (rightly or wrongly) I de-prioritised js tests generally. I plan to write more js tests (and rspecs) soon, as I’ve now (just this past week actually) finished a number of other dev priorities.

Writing tests is a bit like eating your greens or exercising. I would ask that people working for me write tests, and be healthy. But I find it harder to follow my own advice when it applies to me personally. I have a longer reason as to why that makes sense which I won’t bore you with, as it’s probably just ‘post-hoc’ rationalisation on my part :wink:

15 Likes
4

You are not the only one to feel that way. I also think it has a lot to do with a person’s experience. Those who may have had a bad time with tests in the past, or might not be familiar/experienced with the language and testing framework, tend to be the first to really push away from it or put it as a “nice have” versus a “must have” (admittedly, I’m the same way when it comes to Ruby and JS tests, but if you see me writing C#, you will see me write my tests first).

Admittedly, for me it is both laziness and time constraints. I’m not in Ruby or JS on a daily basis. Most of the software I write is headless backend processing tools. I’m 100% comfortable writing tests for services, clients, libraries that have zero UI. I’m even 100% comfortable writing tests against MVC 6, but ask me to write tests for Discourse and I struggle (although a lot of my PRs in Discourse have tests – when related to core – don’t look at my plugins though… :shame-face:)

One day, I’d love to be able to ingrain myself deeper into Ruby on a daily basis, but right now, finding that time between work and home life is just too difficult (and that is the excuse I’m sticking to, at this moment…).

11 Likes
5

I wanted to make this separate from the other post of mine, as I want this to be more of an acknowledgement than a response.

You’ve done much more than that and are selling yourself short! I can’t tell you the number of times I saw a plugin you wrote and went “DAMN! That is brilliant.” Your talents are well received and it is always an enjoyment to see the things you come up with, whether out of need or curiosity.

There is a lot of talent shown in what you do, and you should feel really proud of that.

Based on the things you have developed, I would have guessed you were a programmer by trade. I would not have guessed it to be a secondary talent of yours.

This is a great advice! One that I use at my workplace all of the time. There is zero point to withholding an application until it is perfect, it will never launch. Instead aim for a minimum viable product and ship it soon, gather feedback while working on the next set of features and ship them soon too, rinse and repeat. You learn far more with that approach and can shift directions (if necessary) and usually do not have to restart the entire application because you got the feedback early on.

I’ve also been adapting Complaint Driven Development at my work place over the past year, primarily because, it is driven by feedback and works great with Agile practices. Let the end-users/customers provide feedback at the earliest opportunity possible.

I’m very glad a co-worker got you interested in Discourse. It has been an enjoyment to look at the contributions you have made to Discourse. I hope you never tire of it, because I know I won’t tire of seeing your contributions!

17 Likes
6

Thanks for those kind words :slight_smile:

Yup. I would add though that you can release too early too. If the thing you’ve released is too buggy, you can lose more in terms of goodwill / first impressions than you gain in terms of feedback. Getting that balance right is not always easy.

It’s also a market-specific calculation. For example if you’ve built a piece of security infrastructure for enterprise you better make damn sure it works 100% the first time it’s used by your big lucrative client.

5 Likes
7

I read from somewhere before that tests are not for yourself. Tests are for the poor souls that have to pick up the code later on and change it. Notice that poor soul may be yourself included.

2 Likes
8

Indeed, another industry where it is nearly impossible to release early is the medical field. You have to be 100% certain your code works in that industry too.

That is true, but it is also to validate the code you’ve written to prove it meets the requirements and does what it is supposed to do. So when newbie goes in to make a small change and they break core functionality, the tests fail and alert him of his mistake.

1 Like
9

Perth is an amazing city. My place of birth and residence

4 Likes
10

Great read! Really appreciate your contributions to the community, Angus.

You inspired me to learn more about the Discourse stack and start working on plugins myself.

Keep up the great work!

11 Likes