How to Become a Better Software Engineer by Learning the Tools Around You

One underrated way to become a better software engineer is to create your own workspaces for the tools used around you.

There are loads of tools we interact with at work without necessarily getting the chance to properly learn them.

Jira, Jenkins, Bitbucket Pipelines, AWS (EC2, S3 buckets etc), Sentry, Datadog . . . The list goes on

Maybe another team owns your Jenkins setup. Maybe only a few people have access to your monitoring tools. Maybe CI/CD was already completely configured before you joined the team.

But you don't have to wait for someone to give you that access.

The access problem

There's a bit of a catch-22:

You need experience with a tool to be trusted with more responsibility, but sometimes you need that responsibility to get the experience.

My approach? Create your own sandbox.

A lot of these tools have free tiers or can be run locally. You don't need the full enterprise setup to understand how they work.

Pick a side project and use it as your playground.

Want to learn Jira? Create tickets, epics and sprints, and manage your project through it.

Want to learn Sentry? Connect an app, intentionally crash it and investigate the error.

Want to understand CI/CD? Build a pipeline that runs your tests, creates a build and deploys something.

The key is to actually use the tool, not just watch tutorials about it.

How I learned CI/CD

This is how I built a lot of my own CI/CD knowledge.

I set up my own Jenkins instance and Bitbucket Pipelines and started building real pipelines for my projects.

I configured things, broke them, debugged failures and figured out why they weren't working.

That experience transferred directly into my work. When CI/CD problems came up on my team, these concepts weren't new to me.

Over time, I became one of the people on my team with deep knowledge in this area.

Learn the tools around you

You don't need to become an expert in everything. Pay attention to the tools around your work and get curious about the ones you don't understand.

• Jira / ClickUp: Run a side project through tickets, sprints and workflows
• Jenkins / Bitbucket Pipelines / GitHub Actions: Build a real CI/CD pipeline
• Sentry: Capture and investigate errors
• Grafana / Datadog: Create dashboards and alerts
• AWS: Deploy something small and learn how the pieces fit together

You don't need thousands of users or an enterprise subscription.

You just need enough of an environment to build, break, debug and understand.

Solve more problems in your team

The goal isn't to collect tools for your CV.

It's to expand the range of problems you can solve.

When a pipeline fails, you know where to look. When monitoring comes up, you can contribute. When your team wants to improve a workflow, you understand what's possible because you've experimented with it yourself.

That's how learning a tool becomes valuable beyond just knowing how to use it.

So, if there's a tool you keep seeing at work but never get the opportunity to properly use, don't wait for access.

Create your own environment, use it for something real, break it, fix it, then bring what you've learned back to your team.