Wanna be a ROCKSTAR Developer?

LaurieH — Mon, 20 Nov 2023 13:55:04 +0000

As a software engineer, you probably sharpen your skills by staying on top of the newest, coolest technology. This is an obvious place to focus for growth, but there’s a less apparent area you should consider that will make you stand out among your peers: Business Analysis.

I started my career as a software engineer but took several side roads along the way (some of them more interesting than others) and eventually found myself in a BA role. After a few years of gathering and communicating business requirements I realized I’d strayed too far from where I wanted to be. As I began clawing my way back into development, and learning all the new technology I’d missed, I found the skills I picked up during my detour ended up putting me in a strong position as a developer.

Let’s explore a few of these skills and see where you can apply them in your career.

1. Seeing the Big Picture
While you’re working on a new feature, have you ever wondered, “why do they want this?” The card you’re working on has few, or no, details about “why” this feature is important and instead just outlines “what” the client wants. Understanding the business need gives you critical insight into how your feature fits in your overall project.

2. Understanding Requirements
Business Analysts are skilled in eliciting requirements from project stakeholders which is a very valuable skill for developers. Asking questions and truly understanding the request will result in delivering a product that meets your client's needs instead of your interpretation of the requirements. NEVER be afraid to say, “I don’t understand”.

3. Learn about the Business
I’ve worked as a developer for manufacturing, health insurance benefit enrollment, and logistics and found that understanding the business is a huge bonus when writing code. Oftentimes a BA or stakeholder will use terminology specific to their business. If you don’t understand what they’re talking about, you’ll miss key information about the problem you’re solving. Ask the BA or a key stakeholder to spend a little time giving you an overview of the business and see if there are any resources they can recommend. For example, while working with benefit enrollment EDI, I became Human Resources certified so I could have a deeper understanding of the laws and various complexities of different benefit types. This gave me a huge advantage over others on my team because I had knowledge that wasn’t explicitly noted in the requirements.

4. Communication Skills
I can’t stress this enough: being able to effectively communicate with the business and others on your team is key for any developer. Whether I have a question about a feature, or want to propose a solution, the time spent interacting with clients as a business analyst has paid off in spades. Be sure you can communicate complex ideas without using technical jargon. Non-technical stakeholders know their business, not software development. If no one understands your ideas, they’ll discount anything you propose.

5. Understanding your Users
After you get the “big picture” and have a handle on who your users are and what problems they’re trying to solve, you’ll be in a great position to develop user-friendly and intuitive software. This will lead to happy users and clients.

After all, that’s why they hired you!

Code Reviews for Sport

LaurieH — Tue, 07 Jun 2022 16:59:32 +0000

While many developers dread doing code reviews, I realized several years ago I actually enjoy reviewing code when I approach it like a sport. Since no one's code is perfect, I challenge myself to hunt down issues to keep our code efficient, bug-free and easy to follow.

Ok - you're probably thinking, "Geez, I would hate to have my code scrutinized by her if her goal is to find something wrong". But, I've had many developers seek my reviews after their initial introduction to my pull request feedback.

No Rubber Stamp Approvals

As a seasoned (read: OLDER) developer, I am well aware that my code is not perfect. I count on the code review process to find where a null check is missing, or where logic could be more efficient. Or, heaven forbid, I have a glaring bug. I am passionate about code quality, so I will never rubber stamp my approval on anyone's PR - even when I'm reviewing code for more experienced developers.

"The first thing I want to see when I find a bug in our application is my approval on the PR" - No One Ever

If you're looking for flaws while reviewing code changes, you'll either find something, or learn something. Either outcome is valuable.

Follow the Logic

I always try to follow what the code is doing when I'm evaluating someone's work. Skimming the code doesn't do anyone any favors - seek to understand what's happening.

What is this variable and where is it set?
Does the name of this method match the functionality?
Is there a more efficient way to get the same result?
Could this duplicate code move into a separate method?
That's a cool approach - I never thought about doing it that way (see... I learned something new)

Ask for Clarification

When you're in the zone during development, you can easily follow what your code is doing. But, if you hand that code to someone else they may end up very confused. Or, you may come across your method months later and wonder, "Who wrote this garbage?".

If you find yourself confused (even for a minute) while evaluating a code change, you should absolutely ask the submitter to make adjustments. Sometimes simply renaming a variable or adding a comment in the code will help with readability (and everyone will appreciate the clarification when they're troubleshooting later).

Be Kind

I've yet to meet a developer who has written flawless code, so there's no sense in berating your coworker when you find an issue during a review. Uncovering problems is what you set out to do in the first place! While some people have been put off because I rejected their changes due to a typo or misspelled word, I assure them my feedback is strictly about quality.

When I review someone's code for the first time, I always explain that I'm thorough and ask them not to take anything personally. I also request they scrutinize my changes since I'm expecting them to call out my mistakes. Peer reviews are a valuable part of the development process and I want everyone on our team to have high expectations for the quality of our code.

Scrutinize, Scrutinize, Scrutinize

The definition of scrutinize is to examine closely and minutely. When we scrutinize code changes during the pull request process, we are ensuring code quality - and that is the goal.