My first few months as a software dev

Much of what I decide to write is driven by what I think I'd have liked to read or be made aware of. Reflections and takeaways are a common theme across all of the content on this blog. This article is no different and is something I've been mulling over for a while.

Here's a peek at what this blog covers

It's not easy picking a few lessons and labelling them as most important, especially when your first job is going to throw something new at you every day. Nevertheless, this is my attempt at condensing all of that information and offering a glimpse of the things we're less likely to hear about before starting our first software role.

Testing: unit, integration and the gazillion others

Writing code is just the tip of the iceberg. There are so many other things that go along with it. In the world of DevOps and increasingly cross-functional roles and teams, you'll spend a good chunk- sometimes, an annoyingly large chunk- of your time monitoring builds, application health and, the subject of this section: writing tests.

It's not that many of us weren't aware of the concept or that we didn't expect to do it; we just didn't realize how constant of a process it was, and how surprisingly bamboozling it could be at times.

Here are some things you should know

1. There are many different kinds of tests, but some common ones every software dev will probably end up writing are unit, integration and acceptance tests. Without going into the details, each one tests a class, multiple classes and the complete, end-to-end application respectively. Oversimplification: you test each part of your app individually, then put it all together and ensure that works too.

2. Ideally, writing tests isn't a task in itself; rather, it's a crucial part of every task. When you write a piece of code, you're expected to write the tests for it too.

3. An important measure of codebase quality is the test "coverage". It denotes what percentage of the codebase is covered by at least one test. It's likely your pull request (PR) may not be merged if a test doesn't cover the new piece of code you introduced. Or if overall coverage falls below a threshold. And this check is mostly automated, in the form of a Sonar Gate, for example. Bottom line: it's not something you can usually wriggle your way out of!

4. All jokes apart, tests do serve an important purpose at the end of the day, which explains the emphasis on them. From the POV of a beginner software dev especially, it makes you rethink the code you've written and it should make you evaluate things such as

   • what's the core purpose of this function

   • is there a better way to do this

   • how do I handle and test edge cases?

Git: the unfamiliar parts

Git and VCS (version-control system) is a no-brainer. Everyone knows this, and unlike writing tests, it's something most of us have had plenty of exposure to while at college or while working on a personal project.

(For beginners or those who need a refresher on VCS & Git, check out one of my previous articles on the concept.)

This section though, focuses on the parts of Git that are less used when working in small teams, but become an essential day-to-day aspect when working as part of a larger organisation. However, note that these are my top picks as to what might help you most stepping into your first role, and there's more you can learn as you go.

Stashing

You're making changes on a branch when you realize you need to address a quick comment or two on a different branch's PR. So how do you hit pause and save your changes before you switch branches? Committing your changes thus far may not be the best option, because you don't want a half-done stub of code showing up in the commit history. It's easy: just stash your changes.

git stash

And when you want to get it back

git stash pop

Read more here.

Creating/applying patches

This one is fairly common but is still worth a mention. If you're copy-pasting entire files to share your latest changes with teammates, don't. There's the concept of creating a Git patch for exactly that. It captures your changes.

Cherry-picking

Suppose you want to pick commits on a different branch, selectively, and apply them to another. Pulling changes isn't all that git offers! Read about cherry-pick here

History

Pretty low-hanging fruit, but try to check up git history/log on a branch, and maybe trace a commit.

git log

Here is a good resource.

CI/CD, lifecycles and deployment tools

As I mentioned before, coding is just one part of what you'll end up having to do. There's a lot of emphasis on writing code, and most folks get on a DSA spree to ace coding interviews. While that's alright, I think it's good to know about other things that actual software development would entail too: a major topic being CI/CD (continuous integration, continuous delivery and deployment) and tools commonly used. Again, no need to build experience using these, but it might be good to read up a bit about them.

A CS course usually touches upon these topics, but for those of you who aren't from this background here's a pretty basic list of the most common tools and topics you may encounter

• Jenkins

• Docker

• Kubernetes

• IaC and writing Terraform scripts

Networking, asking for help

A departure from the technical bits I spoke about earlier, but I just had to put it in here.

It's not just Hogwarts, it's true at most places. Speak up and don't shy away from asking the questions you may have- and you should have many. It's the easiest way to learn and fit into the culture. If you're worried about being judged, don't. Most folks are very helpful, and you have far more to lose by sitting mum than by asking a lot of questions. Having said that, it's just as important to self-learn and explore internal docs and content.

Networking, you've probably read of multiple times. I've learnt that effective networking can make all the difference in how you view yourself within the company, and how others view you.

In a role such as software engineering, it's easy to miss out on the interactions beyond your scrum team, but there's so much to be gained through those.

• speak to a diverse set of people, from different roles, levels of experience, and regions.

• events and competitions are a great place to begin. (besides, they're fun; plus who doesn't like to take a shot at winning a prize :))

• if there's a chance for in-person interaction, take it. I'm an ambivert myself, and lots of social interaction isn't something that I love all the time, but there are so many interesting conversations to be had every once in a while, it'd be a pity to miss out.

And as for my peers- what would you put on this list? Do put it down in the comments.