Tech Team

The mission of engageSPARK is to help organizations interact with anyone, anywhere. We from the Tech Team are building and running the platform that makes this possible.

A few facts about us:

  • We are multiculinary: Whether you like brewing German beer, barbecuing Hungarian sausage, preparing Indian Dhosa, frying Philippine sisig or cooking Polish Borscht, you’ll find someone to enjoy it with. Isn’t that a good thing? Different, interesting food all over!
  • We are a remote team. Some of us are in Cebu City, Philippines—where it all started—others are in India, Spain or somewhere in Asia. We travel often. In Joel Gascoigne’s classification, we’re a 3 on a way to a 4.
  • Programming languages we’re betting on: Golang, JavaScript, Python
  • Pictures? Did you say pictures?
  • We are looking for you!

What else should you know? Maybe the most important question is:

How do we improve?

And it is a good question. It’s a value of ours after all. And it’s the ability to improve that ultimately makes us an effective team. Some thoughts:

  • Everyone can improve it. This is not (just) the CTO’s job. Something regularly ruins your day? You better start a change.
  • Document and automate. We document our processes and support them with automation. That means for example we decide to remind ourselves to take carer of old issues. And we make our chatbot remind us, every day.
  • Let’s try. It’s an attitude. Maybe something is not broken, but maybe it can be better? Let’s try. Do we know if removing the Daily Standup will work? Maybe not. Let’s try.
  • Everything changes. All those processes and tools—up for change.

How do we work?

  • We are a remote team. We’re putting that first, because it changes how we collaborate. And because it’s not easy to pull off, and it’s never “done”. That’s why we dedicated a page of its own to how we work remotely.
  • We use GitHub to organize ourselves. (This mostly still up to date blog post talks about details.) GitHub also stores our code, we create pull requests there and do code reviews.
  • Jenkins checks our pull requests by running tests and static code analyzers and deploys into production.
  • Our QA is there to help the engineers. Not to do their job. Engineers solve problems in adequate quality.
  • We want to move fast. Perfect is the enemy of the good and good enough. Quality needs to be adequate, but it must be adequate.

 

Tech cloud

Ansible, AWS, Django, Docker, errbot, Git, GitHub, Go, Java, JavaScript, Jenkins, k8s, Linux/Ubuntu, NGINX, Postgres, Python, React, SNS/SQS (AWS), Thrift

If you want to know more, read our blog. Here are some excerpts:

Location Independence Creates Friction and That’s Good for a Remote Team

Remote work usually means you are location independent. Yes: you are free to work from anywhere! Unfortunately it's not all mojitos and sunset at the beach. Did you know palm trees often don't feature Wifi? And as they say: with freedom comes responsibility. In plain...

How I Interview Remote Devs on the First Call (Remote Hiring Series)

I admit I have a love/hate relationship with the first calls in an interview. They're intense.The sheer amount of them makes them extremely exhausting.They're also super fun.And they matter a lot.And because they matter, I think we should try to do them well. I've...

Your Answers aren’t Good Enough, Ask Questions! (Remote Hiring Series)

You're interviewing for a remote dev position? Awesome, here's a tip: spend less time replying to questions and ask them instead.Why's that? Not because I want to hear myself talk. But because your questions—what you ask and that you ask them—are a great signal....

Channel hygiene: simple boundaries for remote teams

For remote teams work and private life often blends into each other—but we need boundaries for a healthy life. Here is how we use channel to make sure we’re off when we’re supposed to be off.

Mosh and firewalls: Proxying all mosh traffic through a proxy

How Mosh, the mobile shell, connects to servers, and how to tunnel its entire traffic through a proxy, using SSH’s ProxyCommand and netcat.