Non-Code Aspects of Software Development

Not just engineering

Developers sometimes get too engrossed in polishing up their technical abilities. They forget that code is only part of software development; there are others like managing expectations, and establishing trust with stakeholders. The following advice speaks to the non-technical half of the process, and is particularly relevant for junior and mid-level software engineers.

Take initiative

Mentorship can be great, but it’s not always available. Senior engineers are typically too swamped to give new developers the guidance they may (rightfully) expect.

You need to take a proactive approach. Onboarding documentation is prone to falling behind on current processes, especially when there’s a transition being made. This is usually the case for enterprise shops transitioning a legacy system to modern cloud-based deployment. Ask questions! Show interest in why certain decisions were made. Document their responses, or at least make small notes about them.

You could be in a team whose members typically come to meetings right on the dot. If the team is small enough, you might find it useful to arrive ahead of everyone else. You could set up the conference call (if some are working remotely), saving your team those 5 minutes of getting set up. You also give yourself a nice buffer to get comfortable in the different environment. Which leads us to..

Have your ducks in a row

If your product owner comes to the meetings, it might help to give them an overview of everyone’s current tasking. Someone (if not you) should be sharing their screen with JIRA (or whichever tracking software is in use) up before the meeting even begins. It not only saves everyone the trouble of fumbling through authentication or internal network issues, but also gives your product owner confidence that the team has everything in order.

Simplify

Your product owner seldom is a software engineer. They neither care nor understand the implementation details of what your team is building. Learn to translate technical issues and accomplishments into something more digestible. It doesn’t have to be blatant business-speak like synergy, or engagement; just easier to understand.

Speaking of which, this also means that you have to..

Make the costs and benefits clear

We often treat software development as a thing we do in isolation. The reality is that a lot of it can feel like sales, particularly when you’re working closely with the customer. Your product owner needs to see that every effort is measurable in costs and benefits.

There’s rarely a one-to-one mapping between story points and man-hours, but they’re usually related. This means that you can somewhat easily discern what each effort means in a dollar-sign perspective.

Product Owner: We need to make X change to feature Y.

Bob: That’s a pretty costly change. It’s a 3 point story just to look into, and likely a 5 point story to implement. That’s about 10 to 12 days of work, or 80 man-hours. Worse, the user probably won’t even notice the change. And we’re still backed up on the other priorities. We can create issues for this, but we’ll need to set this aside in the backlog.

If you can do this well, you can even play up more subtle (but crucial) efforts, such as infrastructure migration, as necessary for the success of the product.