Leveling Up Your Developer Career

Recently (on July 7, 2023), I was involved in a discussion around this topic along with other panelists. This was part of a larger event around Empowering Developers to Build Faster and Innovate More.

Since I think it's worth sharing some insights, I wanted to write a post to review our discussion. It's a topic close to my heart (developer enablement) and it's a good change-up from the usual stuff I usually write about.

Discussions revolved around:

• Our journeys as developers
• Learning paths and opportunities for developers
• Deep specialization
• Re-skilling, especially for mid-career folks
• Being a cloud-native developer

Just so that you know, these discussion points (and my opinions) are not "novel." Most of it is common sense and I am sure you have heard it before. But there's no harm in a recap, is there?

What About Learning Paths and Opportunities for Developers?

I highlighted a few non-traditional options, which are more open-ended and exploratory as opposed to completing a course or getting certified.

• Open source contributions: This may sound very daunting, especially for developers early on in their careers. But that's where the secret lies: because it's not easy, it can really set you apart.
• I have personally witnessed many success stories over the years, including students and early career professionals.
• Answering questions on online forums: StackOverflow is a great example (but not the only one!). Just pick your favorite tag and filter the unanswered questions. Start small, maybe one or two questions a week. Once you do this consistently and go through the process, you will be surprised by how your debugging and problem-solving skills improve.
• Documentation: Yes, read the documentation! Next time you get that exception, go read the API documentation. Maybe you are following a tutorial and can't get it to work. Don't go directly to a search engine, or StackOverflow (or worse, ChatGPT). Please dig into the official documentation. It will be hard at first, but as a side effect, you will build a lot of knowledge in the long term. And, maybe if something is really missing in the docs and it's open source, just make that contribution and help other developers!
• The last one is to start blogging/writing: This will really force you to think. Knowing something and explaining that, especially in writing, are two different things. By the way, as someone who is a regular blogger, I am definitely biased toward this (just calling that out!).

These are all resources and opportunities hidden in plain sight. You don't have to pick all of these at the same time. Take it slow and steady. Start with one perhaps or maybe discover others. I am sure I haven't explored them all.

Our Journeys as Developers

I wrote about "learning" first since it's a topic close to my heart.

Well, I wasn't really a geek trying to tinker with computers since I was five; so in that sense, it started out being quite boring, actually. But I have been lucky to have experienced a wide spectrum of roles. I started off as an engineer, working on Java-based middleware products, triaging issues, solving bugs across a variety of operating systems and databases, and LDAP systems - Docker wasn't a thing at that time. So you can imagine what it was like!

Then, I moved on to implementing these products for customers, in production. From there on, I forayed into the cloud and open-source space and switched back and forth between Product Management and Developer Advocacy. And if I reflect upon my journey so far, I think back to the beginning of my career and the "baptism by fire" that I had. It was tough, trust me. But it did two important things:

1. Forced me to understand large systems in and out
2. It sort of wired me up to learn new technologies rapidly

If I were to pick one takeaway, especially for folks early on in their career, it would be debunking this myth or confusion around "transitioning into an architect or a PM or engineering manager (or similar) role, and remaining technical."

It's really important (in my humble opinion) to stay hands-on at the same time. Sure, different individuals might have different ways of going about it. But, overall I think there is a lot of value to be gained from always building things and getting your hands dirty, and spending time in your IDE because that's where the real magic happens.

“Deep Specialization” for Developers

I am not sure if folks have heard of the term T-shaped. If you have, please bear with me and consider this a refresher.

A T-shaped developer is someone with broad knowledge across many aspects of software development represented by the horizontal bar of the "T." Yet, they also have deep expertise in one or two areas, signified by the vertical stem of the "T."

But it is easier said than done and there is no "one right way." I can cite a few examples for you:

• For example, you could be someone who works on databases. You could specialize in NoSQL but have a broad knowledge of distributed systems concepts, or enterprise challenges like migration, etc.
• Similarly, a Cloud Engineer could have a broad knowledge of how to implement solutions using various cloud providers but have a deep specialty with containerized services on AWS like EKS, ECS, App Runner, etc.
• Another classic example is Specialist Solution Architects at AWS. They are champions in their respective areas, but at the same time, they cannot get away with not having a broad knowledge of AWS.

So I guess the point I am trying to make is: Yes, absolutely go for deep specialization, but not in everything. At the same time, don't turn into a "jack of all trades, master of none" persona. Try and strike a good balance. There is a fine line - tread it carefully.

How About Re-Skilling, Especially Mid-Career?

Continuous learning has pretty much been part and parcel of my job. I really enjoy it and am thankful for it! But, I do agree that it can be a bit exhausting at times.

There was a time when NoSQL ruled the roost. Then, there was this Kubernetes wave that was happening (which I think is kind of stable now). And then it was something else - Web3 maybe? Now it's ChatGPT, and I don't know what's next. And all this will be different depending on who you are talking to...

For mid-career folks, it can be tricky to keep up with the hectic pace, and I would actually recommend sticking to the T-shaped strategy. If you see an overlap between your expertise area and this new wave, I advise using that to your advantage and applying what you already know in order to navigate a new landscape.

Here are a couple of personal examples, where I learned new stuff by marrying them with previous concepts:

• How to run stateful systems like databases on Kubernetes, or what the nuances are of running large-scale processing pipelines on Kubernetes
• More recently is in the context of Generative AI: How do we think about data in this area? This has given rise to vector databases and so on.

There is one more thing, and it's probably (really) underrated: that is reading a lot.

I am not talking about blog posts, etc. Read high-quality material or books that cover the fundamentals of areas you are working on. For me, it would be something like "Designing Data-Intensive Applications." The goal is to have really strong fundamentals. It will keep you ready for the next "big thing" in the market, which is always around the corner.

Being a Cloud-Native Developer: How Is It Different?

I didn't actually talk about these... but the opinions expressed by the panelists were similar to what I would have said. So I am just going to add my two cents here.

This is (probably) not a new topic in 2023, but an interesting one, having worked on helping ship such platforms in the past.

Remember that you are not sitting in your on-premise server room anymore (like I was, literally!), or not talking to system admins to bring up a fleet of servers to deploy your software. In the cloud, you have moved up the stack. It's a different abstraction level now. Just like DevOps, cloud-native is also a different way of thinking. Being a cloud-native developer, you need to embrace the new paradigms that come along with it.

I can actually think of a few areas here:

• Microservices approach - I personally don't like using the term "microservices" (I like to think of it as distributed systems). Whether you like it or not, or you realize it or not, when you are building on the cloud, you are building on top of a massive distributed system. That brings up the point about...
• Embracing failure - Systems should be designed to be fault-tolerant, with automated recovery and rollbacks... and all the good stuff. "Failures are a given and everything will eventually fail over time" - enough said!
• Automation - If you are in the cloud and still doing ClickOps using the console to go from dev to production, well, then you aren't really cloud-native.

One could talk about so many other aspects here, especially around observability and monitoring. But these are definitely top of mind for me.

If you think of concrete areas where these have manifested:

• Docker - Packaging your apps as containers and running them on compute such as Kubernetes, or another PaaS (or CaaS?)
• Serverless - It's not just the compute (like AWS Lambda or Fargate), but also databases (like DynamoDB).
• Infrastructure as Code - All infra is available at the tip of your fingertips (literally an API call away).

For folks that are new to their cloud native journey (yes, there is always someone who is new!) - don't fall prey to myths and misnomers like "Serverless is equal to functions," "Kubernetes is the solution to all the problems," etc. Use the right tool for the right job.

And remember, just because you came back from this conference and learned this "awesome new thing" doesn't mean you need to put it into production the very next day.

Alright, back to the usual posts again! See you next time.