Just Jump Into the Stream
Tags: softwareengineering, learning, career
Published: 2019-12-29 19:23:34

---
title: "Just Jump Into the Stream"
description: Sometimes it can be rewarding, both personally and professionally, to break out of your technology bubble and dive into something completely new!
tags: software-engineering, learning, career
cover_image: https://thepracticaldev.s3.amazonaws.com/i/kbgvcvxkgkuqndri7q35.jpg
published: true
---

_This was originally posted on [my blog](http://rion.io)._

I've spent the better part of my ten-year career as a developer in a relatively safe bubble, technology-wise. 

Falling in love with a programming language or technology is a bit like the software version of having your first _real_ girlfriend/boyfriend. They might change the ways that you think, the related technology choices that you make, and it might cause you to potentially not realize what they are good (and not good at) until to try something else.

I was incredibly fortunate to be introduced to C# in my early computer science courses in college and fell in love with it (at least compared to some of the other languages being taught at the time). The language stuck with me throughout college and I used in whenever the opportunity presented itself. Plenty of languages were sprinkled in during my time there: C, C++, Python, Java, Lisp, Visual Basic, x86 Assembly, and countless others, but C# always just _felt_ the best. 

 At any rate, eventually it landed me my first intern position at a petrochemical company where it was the language du jour and I fit right in. It was here that I was introduced to the rest of the Microsoft Stack of:

 - C#
 - ASP.NET
 - SQL Server
 - IIS

These technologies have been a huge part of my career at every position I've had as a professional and any major side-projects or consulting work I've been a part of. There have been plenty of other technologies and languages along the way, but these few have been at the forefront for ... at least until recently.

A project came along that required the need for something _different_. **It was something that I had never worked with previously, using technologies that I hadn't touched since exercises in college (or ever), and they would be sure to burst any safe bubble that I had been living in, in a good way.**

##Bubble Burst

![](https://thepracticaldev.s3.amazonaws.com/i/w0wdro04owtyj6q22qk6.gif)

In a nutshell, the project required building a real-time streaming infrastructure to replace long-running batch processing jobs for a legacy application. Languages would change, technologies would change, databases and storage would change, and finally the entire programming paradigm itself would change.

The new stack would look something like this:

- Kotlin
- Apache Kafka
- Postgres
- IntelliJ

As you can see, not a ton of overlap with the previous stack, and by not a ton, I mean _none_. I had never written a line of Kotlin, downloaded IntelliJ, touched Postgres, or been in the same building as Kafka. Being an experienced engineer, I didn't have much concern for a few of them. Languages come and go and once you learn one, it's pretty darn easy to pick up another. IDEs, meh, basically the same way. A new database technology? Just a bit of new syntax. All these changes are totally manageable and basically negligible.

Except streaming. Streaming was a whole new paradigm to wrap my head around. Calls and operations weren't as procedural like most applications, you had to think about _when_ code was being executed, and any "race-conditions" that you had encountered earlier in your career immediately become totally irrelevant as everything is much, much crazier in the streams world.

> In a nutshell, I was taking everything I had done previously in my career and _voluntarily_ throwing it out the window to shift to an entirely different stack, programming paradigm, language, etc. I suppose it could have been terrifying, but of all things it was... exciting.

Pivoting over to a Java-oriented ecosystem was different. A different build system (Gradle/Maven) had a bit of a learning curve, but after dealing with countless Javascript frameworks, it was a walk in the park. **They key takeaway is that you'd think with all of these changes, this would be a scary proposition, but if you enjoy learning, and enjoy becoming a more well-rounded developer, you'd probably be just as excited as I was to get started.**

## Don't Dip Your Toe In, Dive!

![](https://thepracticaldev.s3.amazonaws.com/i/91i6obtmekj1abqzx74c.gif)

As I mentioned earlier, my entire career has been spent in various versions of the same silos. I knew C# and was _comfortable_ with it, I could write it all day, in my sleep, in a box, with a fox, etc. The Microsoft stack in general was what I had lived professionally (and in my free time) to write everything in, and while I had tinkered with some languages and technologies on the side to play with, it wasn't anything like _actually_ writing production applications and code for projects.

> I'd encourage any developer, if presented with the opportunity, to step out of your comfort zone with open arms. You know what you know, but you absolutely don't know what you don't. Working with different technologies, languages, tooling, will all make you better. Software engineering is cumulative.

The project that I reference in this post is still very much ongoing. It's still exciting (and at times frustrating), but I'm so glad that I made the decision to take the reins on it. Even after just a few months it still feels novel, probably because I spent 10+ years basically doing everything in a similar way, but most of all _it's fun_. Fun can be rare in engineering, especially if you've been doing it for a long time but having fun while learning and solving complex business problems, can be extremely rewarding, both personally and professionally.

**The opportunity to jump into real-time streaming applications might not present itself, but that's beside the point. It's about taking advantage of _any_ opportunity to learn something new, or more specifically, something different.** It's not just a matter of doing it but taking the time to _learn_ it. Learn why it works the way it does, what makes it so different that what you've done in the past, and carry that with you into every project that you work on, regardless of the technology or stack, in the future.