Great things are usually built by teams, not by lone wolves. The myth about the 10x developer sitting alone in the basement is often exaggerated. In practice we’re usually working in a team, building (hopefully) great things together. Aside from the code we write, how we collaborate with others, our work ethic and ways of working have big impact on the success of a project.
The code review practice is widely adopted for increasing overall code quality and decreasing number of bugs that reach the QA team / end user. On top of these, I believe reviewing and discussing code written by your peers is the best way to share knowledge within the team, to onboard new members faster and to quickly adopt new patterns as a group.
Below are my top tips for being a great team-player, making your pull requests easier to read and understand so they can get approved as fast as possible.
With New Year’s Eve just hours away, what better time to talk about goals, motivation and personal development.
I’ve read countless books on these topics over the years. Not necessary for the “action steps” they give to better your life immediately, but for the reflection questions they often pose. Without a doubt Can’t Hurt Me by David Goggins is my new favorite. It’s a great blend between reflection, adversity, challenges, motivation, gratefulness.
Having a side project (often called a “pet project” or “side hussle”) is a great way for every software engineer to improve existing skills or learn new technologies altogether. It provides a safe environment where you can experiment freely and iterate faster. You’re not bound by other people’s requirements so you can try this new cool-looking library still in “alpha” stage. Of course no one (except you) will be upset if things go wrong and everything breaks.
Following are a few tips to make the most of your side project and learn as fast as possible. If you don’t have a pet project yet these will serve as a guideline how to start one.
RxJava has been gaining popularity in the past couple of years and today is widely adopted in the Android community. So much in fact that I can’t recall an Android developer interview in the past 3 years that doesn’t mention RxJava.
Here is a short list of the most common interview questions I have asked candidates (or been asked as an interviewee). Answers to all questions can be found further down.
Jacoco is a widely used library to measure test code-coverage in JVM-based projects. Setting it up for Android applications has a few quirks and having multiple flavours, using Kotlin and writing (some) tests in Robolectric makes it even tricker. There are already great tutorials in how to set it up, like THIS and THIS one. In this post however I’ll not only give you a ready solution, but share all details how I got to it – this way you’ll be able to adapt it in the best way for your project.
This is Part 2 of a short series about optimising your build speeds. If you haven’t already, please check out Part 1, which describes the different build caches you can use.
In this post, I’ll explain some other build properties you can tweak. Let’s start with the Gradle ones.
One of my last tasks @ASOS was to investigate the slow build speeds of the Android application. This post is part of a short series about how we approached the problem, what we tried and what we found out. To be clear, don’t expect miracles and 🦄 here, but you’ll get a better understanding of what you can do to optimise your builds.
Ideally automated tests should be predictable, isolated and precise, allowing you to find an issue quickly. If these conditions are met, you’ll never have to change a test unless to accommodate a changed requirement. This sounds great on paper, but in practice we often forget the isolated bit and start testing multiple things in a single test. If abused, we’ll end up with tests that need updating all the time, causing developer frustration and wasting time.
One tool that can help with isolation of tests is using matchers. As the name suggests, matchers allow you to match an object agains certain conditions.
Many Jenkins plugins require changes to the default Content Security Policy (or CSP) to work correctly. A refresher on what CSP is and why you should care about it can be found HERE and HERE. If you use a hosted Jenkins installation, you’ll probably need to contact your service provider to do the necessary changes for you. However if you have a self-managed installation, please read on.
With the exponentially increasing usage of
Kotlin these days, many developers face the issue of how to test the newly created Kotlin classes. As we know all classes and methods are
final be default in Kotlin, unless specifically
Mockito, one of the most popular mocking libraries for Java projects, can’t easily mock
final classes. Since we don’t want to
open up everything just for testing purposes, we need another solution.
Hadi Hariri highlighted in his excellent blog post that Mockito version
2.1.0 and above can perform the magic of mocking
final classes. Since mocking is something used only in tests … and usually it just works, we’ve neglected Mockito and were still using a very outdated version (1.10.19) in our project. There were a few pain-points while updating to the latest one, so hopefully this post will save you some time when going through the same process.