The title says it all. Programming is a team effort. There is no winning, no hierarchy of performance, no #1 programmer: in the end you all commit to the same codebase, you build the same product.

Use terms and language everyone on your team understands. Be mindful about the attitude your language transports, and make it a positive one. Accept the fact that different people will do things differently, recognize different kinds of contributions and value the entire spectrum of possibilities. Unassume knowledge about things you already know and that are important to you. Educate others instead of judging them. Let others educate yourself. Ask, don’t tell.

Assume that every line of code you read, no matter how old or imperfect, has been written with good intentions. There have been constraints and circumstances you don’t know about. Improve upon what’s there and see the opportunity rather than the inadequacy. Make the product better and also make your team a better one. Make doing so and enjoyable ride for yourself and others.

Thank you for this.

Writing tests for your software is an established practice in most development environments nowadays. It also makes a lot of sense. Code that is subject to changes and changes will need some sort of plan for knowing it still does what is it actually expected to do. Tests do that for you.

Writing tests for your software is also a vessel for excessive nit-picking and countless discussions about the “one true way”. Testing snobism is a real thing. The multitude of approaches, even philosophies and the abundance of tooling makes the concept inaccessible for beginners, occasional programmers and self-taught makers.

Fact is, many people - including myself - will still start their programming career driven by the simple requirement that they need something that is not there yet. So they build it, they iterate on it. They shouldn’t have to setup a fully automated test suite for everything when they just started.

I think the fundamentals of testing and writing testable code can be taught without relying on test runners, frameworks, assertions libraries and whatever advanced concepts are out there. Those can be introduced on large codebases that will be worked on by a team. But when just starting, keep it simple.

GitHub Pages is GitHub’s free service for hosting static websites (like this blog) and assets. Its usage is extremly straight forward but requires little repetitive chunks of manual work each time you want to update something (unless you use their built-in jekyll tool). The number of smallish and static side projects I maintain recently reached critical mass, so I looked into using Circle CI for automating the deployment to GitHub pages.

api.ai lets you build conversational chatbots that interface easily with lots of existing messaging services. The promise is: “define your logic once (no coding!!!), reach users across many platforms”. Trouble is these bots are kind of oblivious. If you haven’t talked to them in the last 10 minutes, they will likely have forgotten about you and what the two of you have been talking about the last time.

I recently tried to build a persistence layer for such a bot using the “webhook” feature to trigger an HTTP endpoint that will process the response before it’s being sent to the client, enabling api.ai to access data stored from conversations in the past.

I’ll start by assuming you are just like me. You’re a developer, you went to a few conferences and meetups. You enjoyed going there. You learned quite a lot of new things. You’ve seen lots of people who might be labeled a “rockstar” by others. Stupid term, I know, but well, we’re having quite the time right? Afterwards, let’s go crazy, let’s do aracde games, karaoke all of that. Dive bar? Sure thing, chicken wing. Oh, yes and we’re super inclusive, right, so everyone is welcome. Just come along and be a super awesome person with us. Amazing, isn’t it?