Below is a transcript from work Slack today. Only the names and some code are changed. It ended up causing a bit of drama. DevRanters, what do you take from this?

---

Delivery Lead:
Hey Gang. What's the blocker for FEATURE-123?

Dev1:
FEATURE-122 crashed on iOS app when viewing Feature Introduction page.

Teach Lead:
I've talked about this with Dev1 on a side channel.
And diagnosed the stack trace.
It looks like there is/was some bad handling of a List in the Feature Introduction view logic.
But this is confined to changes that Dev2 is still working on.
(It's not present in master)
Dev2, what's your current position on this?

Dev2:
I have tested at my end with Dev1 but it seems to be working fine

Tech Lead:
There is a race condition related to the use of someList.first()
My guess is that theres a Flow of those lists defined, with an initial value of emptyList
And that on your machine, that Flow is updating with a new value quickly enough that it doesn't matter.
But on Dev1's, for whatever reason, it doesn't get there in time, hits the empty list and falls over.
The logic that's performing the first() needs to gracefully handle empty lists as well.

Dev2:
Where is that logic called?

Tech Lead:
Here's the stack trace Dev1 provided in our conversation earlier:
Caused by: kotlin.NoSuchElementException: List is empty.
...
at 3 iosApp 0x00000000 kfun:kotlin.NoSuchElementException#<init>(kotlin.String?){} + 00
at 4 iosApp 0x0000000 kfun:kotlin.collections#first@kotlin.collections.List<0:0>(){0§<kotlin.Any?>}0:0 + 000
...
at 9 iosApp 0x0000000 kfun:kotlin.coroutines.native.internal.BaseContinuationImpl#resumeWith(kotlin.Result<kotlin.Any?>){} + 0000

This line:
kfun:kotlin.collections#first@kotlin.collections.List<0:0>()
...says that it's first() being called on an empty list.

Dev1:
FYI: Dev3/Dev4/myself are seeing the same issue with the same stack-trace above.

Tech Lead:
So Dev2, have you introduced such a call?
Because I checked master branch and there isn't one, in that version of the file.
Ok, I'll check your working branch Dev2
...
Yes you have here:
var processed1 = someList.first()
var processed2 = someList.first()
...
Lines 123, 124.
Solution looks really straightforward guys.

Dev2:
Okay, I will fix that and push the change

Tech Lead:
Check if someList is empty and allow for generating / handling null processedValues in the view.

Now; I'm going to be straight with you here.
This issue has been discussed over several hours today.
I expect that either one of you could have gone through the process I did in the last 10 minutes above, and resolved it in the same way :point_up:

Dev2:
I went on a break and it's not reproducible on my machine

Tech Lead:
I didn't reproduce it on mine either.

Dev1:
Dev2 and myself are now on sharing screen to sort this issue out. Hope to update back later.

Tech Lead:
<Screen shot of diff with changed code>
:point_up: That change should do it.

Dev2:
Already have pushed the change.

Tech Lead:
...just seen it, is good - same approach :ok_hand:
Dev1 please let us know when tested on your machine.

Dev1:
That does it. It fixes the issues. Thank you, Dev2. I will pick it off from here.

Tech Lead:
Glad to hear it guys.

Dev1:
I have to say this that it is not because we are not working on the issue - Dev2 and myself (together with Dev3/Dev4) have been on this issue all this morning. It just difficult to connect the dot when it wasn't reproducable on Dev2's machine. I brought the issue up because I wanted to switch to working on other tickets while waiting for this to resolve. Still thank you largely for Dev2's work and your keen eyes that spot and resolve the issue quickly.

Tech Lead:
Noted Dev1.
I think the take-away has to be to read the stack-trace carefully... don't worry - we've all been guilty of not reading the error in full, at some point.
The stack trace said that the 'first' element is being referenced from an empty list - that's just logically impossible, right?
Looking for that call to first, we saw it wasn't in the code before, and is after (two of them, in fact).
So then we ask ourselves, how can we deal with an empty list - and then solution almost presents itself.
It didn't really take reproduction of the error to resolve.
Maybe working with a new tech stack creates an anxiety that every issue faced will have a complex solution related to that stack; but I think you'll agree, this particular issue really just required a deep breath and your trusty 'debugging skills 101'... don't lose them! :smiling_face:

This started as an update to my cover story for my Linked In profile, but as I got into a groove writing it, it turned into something more, but I’m not really sure what exactly. It maybe gets a little preachy towards the end so I’m not sure if I want to use it on LI but I figure it might be appreciated here:

In my IT career of nearly 20 years, I have worked on a very wide range of projects. I have worked on everything from mobile apps (both Adroid and iOS) to eCommerce to document management to CMS. I have such a broad technical background that if I am unfamiliar with any technology, there is a very good chance I can pick it up and run with it in a very short timespan.

If you think of the value that team members add to the team as a whole in mathematical terms, you have adders and you have subtractors. I am neither. I am a multiplier. I enjoy coaching, leading and architecture, but I don’t ever want to get out of the code entirely.

For the last 9 years, I have functioned as a technical team lead on a variety of highly successful and highly productive teams. As far as team leads go, I tend to be a bit more hands on. Generally, I manage to actively develop code about 25% of the time to keep my skills sharp and have a clear understanding of my team’s codebase.

Beyond that I also like to review as much of the code coming into the codebase as practical. I do this for 3 reasons. I do this because as a team lead, I am ultimately the one responsible for the quality and stability of the codebase. This also allows me to keep a finger on the pulse of the team, so that I have a better idea of who is struggling and who is outperforming. Finally, I recognize that my way may not necessarily be the best way to do something and I am perfectly willing to admit the same. I have learned just as much if not more by reviewing the work of others than having someone else review my own.

It has been said that if you find a job you love, you’ll never work a day in your life. This describes my relationship with software development perfectly. I have known that I would be writing software in some capacity for a living since I wrote my first “hello world” program in BASIC in the third grade.

I don’t like the term programmer because it has a sense of impersonality to it. I tolerate the title Software Developer, because it’s the industry standard. Personally, I prefer Software Craftsman to any other current vernacular for those that sling code for a living.

All too often is our work compiled into binary form, both literally and figuratively. Our users take for granted the fact that an app “just works”, without thinking about the proper use of layers of abstraction and separation of concerns, Gang of Four design patterns or why an abstract class was used instead of an interface. Take a look at any mediocre app’s review distribution in the App Store. You will inevitably see an inverse bell curve. Lot’s of 4’s and 5’s and lots of (but hopefully not as many) 1’s and not much in the middle. This leads one to believe that even given the subjective nature of a 5 star scale, users still look at things in terms of either “this app works for me” or “this one doesn’t”. It’s all still 1’s and 0’s.

Even as a contributor to many open source projects myself, I’ll be the first to admit that have never sat down and cracked open the Spring Framework to truly appreciate the work that has been poured into it. Yet, when I’m in backend mode, I’m working with Spring nearly every single day.

The moniker Software Craftsman helps to convey the fact that I put my heart and soul into every line of code that I or a member of my team write. An API contract isn’t just well designed or not. Some are better designed than others. Some are better documented than others. Despite the fact that the end result of our work is literally just a bunch of 1’s and 0’s, computer science is not an exact science at all. Anyone who has ever taken 200 lines of Java code and reduced it to less than 50 lines of reactive Kotlin, anyone who has ever hit that Utopia of 100% unit test coverage in a class, or anyone who can actually read that 2-line Perl implementation of the RSA algorithm understands this simple truth. Software development is an art form. I am a Software Craftsman.

#wk171