What I Learned Developing Amelior

The proof-of-concept of Amelior, a health app I’ve been developing for the past semester with a team of colleagues, is complete. This was the first time I’ve touched Android app development in a long time and it’s been quite a journey learning Kotlin. Along the way, I’ve learned a lot of new things about working in a team that perhaps I might not have fully realized before.

You can check out Amelior here: GitHub. As of right now, the latest commit is 54f2a77. We have plans to push Amelior to the market later this summer following a complete Android rewrite and an iOS port, so the repository may be more updated by the time you check it out. We developed the app to reach the proof-of-concept deadline for our CSE-155 (Introduction to Human-Computer Interactions) class and it’s not really meant for real-life usage at this point in time, but that’s not to say it’ll stay that way into the far future.

Lesson #1: Kotlin Sucks

Kotlin definitely has to be one of the worst languages I’ve ever had the displeasure of using. It is somehow less-liked to me than Java, and those are big shoes to fill. Kotlin is a language that is insecure of itself and its own existence. It can’t make up its mind. The most annoying thing about Kotlin to me is that it is selectively whitespace* significant. For example, the following two are valid code:

* Note that whitespace significance in this context refers to line breaks as well, not just spaces/tabs.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.main_activity)
}

override fun onCreate(savedInstanceState: Bundle?)
{
    super.onCreate(savedInstanceState)
    setContentView(R.layout.main_activity)
}

However, only one of these is valid code:

button.setOnClickListener {
    val intent = Intent(this, QuestionActivity::class.java)
    startActivity(intent)
}

button.setOnClickListener
{
    val intent = Intent(this, QuestionActivity::class.java)
    startActivity(intent)
}

That’s dumb. As a proponent of Allman (BSD) braces – my justification for which is a topic for another time – I’m irked by Kotlin’s selective whitespace significance. If a language wants to be whitespace significant, don’t use braces; Python does non-brace whitespace significance well. If a language wants to use braces, don’t be whitespace significant; C, JavaScript, and just about every single brace-using language does this well.

Make up your mind, Kotlin! This is just one thing Kotlin does wrong, and if I wanted to enumerate all my Kotlin complaints, well, that’d be a topic for another time.

Lesson #2: Surround Yourself With People Who Will Tell You You’re Wrong

Disagreement is not negative. Disagreement is positive when it’s done with the right people. It’s important to surround yourself with people who are not afraid of telling you that you’re wrong, that your proposal to do X is misguided and that you should actually do Y instead. Don’t surround yourself with yes-people who will tell you what you want to hear and nothing more, because they may make you feel good about yourself but then you get tunnel vision and dig yourself into the wrong approach.

Surround yourself with people who will tell you you’re wrong, because the back-and-forth discussion and debate is a constructive process that eventually converges on the best solution for your user. Never get attached to your ideas. Never get attached to your code. Be ready to drop your ideas and your code at a minute’s notice when you realize that another approach is better. You fight for the user, for the product, not for your own self. Get rid of the ego, because it has no place.

I’m grateful that my teammates ΙΜ, ΚΓΒ, and ΚΛ were each able to tell me that I was wrong when there was a better way to do something.

Lesson #3: Your Dream Team Isn’t Your A Team

My team was not full of randoms. Everyone knew at least one other person in the team ahead of time at team creation. We thought we had the dream team and, well, we did, but what we didn’t know was that our dream team was not our A team.

We had some team conflicts with a particular member not really pulling their weight and not really having neither the technical nor social nor creative skill to contribute meaningfully to the project, which would have been fine frankly since the workload of a single person divided amongst the other four is not particularly cumbersome, except that they ended up feeling guilty for not contributing and blamed it on us and went to the professor of the class about it. That was not okay. Our reactions to this were varied, typically going between confused to angry that they didn’t just talk to us directly about it, to feeling accused of something we didn’t do, to feeling weirded out by having this particular member – who I shan’t even acknowledge with an anonymized Greek pseudonym as I usually do – hyperfixate on me.

Basically, one of our teammates ended up doing nothing, felt bad about it, and then blamed that on us and told the professor who warned us that all must feel included, even though it was their own fault for not really doing anything. When confronted, this particular teammate revealed that they’d been hyperfixating on me, wrongly believing that I was the authority who told them what to do and that I was carrying the project which, to be totally clear, I was not – it was a team effort and everyone else deserves credit.

We’re pushing the app to market this summer and we’re not working with that particular teammate. We clearly have different ideas about how to resolve conflicts, with the rest of us believing it better to just talk it out amongst ourselves before escalating, while this particular teammate decided to just jump the gun and go nuclear. They clearly have no place in our team. It’s one thing to not know how to program and not contribute to our project, but it’s another thing to go out of your way to harm the progress of the team and add an additional stressor (as if our tight deadline were not already a major stressor).

What we’d thought was our dream team didn’t end up being our A team. That’s fine now because we pushed through that anyways with that unnecessary additional stress over our heads, but we won’t be working with them anymore when we push this app to market.

I learned a lot working on Amelior, and I’m excited to continue working on it again after all my semester stresses are over!

Happy hacking!