2 Things That Could Be Holding Back Your Development as a Software Engineer

Many software developers are understandably eager to jump into their first job with both feet. They’re raring to write great code to change the world, but then in the first few months they find themselves frustrated. “Why all the red tape? Why so much bureaucracy? Why don’t they just let me write code and get out of my way? Why am I only doing small UI tweaks?” If this sounds like you, you may be encountering two of the most common roadblocks in a young engineer’s career.

A bit of background

I’ve been in the software industry for over 15 years, which makes me both seem and feel ancient. Two of those years have been spent as the Director of Engineering for NGP VAN’s DC office. It’s an exciting time to be part of the political and non-profit tech industry, and we are growing rapidly. Along with that growth comes the opportunity to work with a wide variety of people, many of them fresh out of school. It’s incredibly satisfying to play a part in the maturation of a new developer. But that process can sometimes be painful, and having helped a number of people through it, I’ve come to believe that a little perspective can help facilitate that growth.

Common issues that can impede growth as an engineer

Many misconceptions about younger developers are totally misguided. For instance, some believe that younger people are more prone to job-hopping – in fact, the numbers seem to indicate that is untrue. One of the benefits of experience is that it allows you to recognize common patterns more easily, whether they’re in code or in the behavior of the people writing it.  The two issues I list below are ones that I’ve seen time and time again in new developers that inflame their frustration:1) Unfamiliarity with the pace of professional software development

It is highly likely that if you are relatively new to software engineering as a profession, you likely haven’t worked within the constraints of a full software development life cycle. For many new software professionals, some of the most salient and satisfying software development experiences are major projects they completed in college or even high school. But there are vast differences between completing problem sets and delivering enterprise-class software. In school, you switch projects every few weeks. And there’s never any tech debt, as you almost always start with a greenfield design. In school, there’s also the satisfaction of getting a definitive piece of feedback in terms of your grading. Schools have improved a lot in the past decade in terms of the nature and frequency of feedback they give students, but companies still lag. Newer employees that are used to a more frequent feedback cycle may assume the worst when they don’t get a grade at the end of a project.

2) Frustration with the scope of software development tasks

Between Facebook and LinkedIn, you’re constantly bombarded with a (well-cultivated, surely) stream of new and exciting jobs and projects that all of your friends are working on. Meanwhile, your seemingly small sprint task of changing a UI element, or tweaking a back-end process to support what seems like a relatively minor feature feels insignificant. You’re upgrading a JavaScript library while your friends are changing the world! This leads to the second factor that can cause frustration: The rise of Agile software development practices.

At NGP VAN, we practice Scrum, and are fully committed to Agile software development. Our ability to rapidly deliver features and fixes, and then incorporate feedback from our diverse set of clients contributes to our reputation as market leaders. Frankly, as a manager, I love Scrum. I believe it provides visibility, accountability, and efficiency. Obviously, no methodology is perfect, but one of the complaints about Scrum that resonates the most is as follows: By breaking down tasks into such small, discrete chunks, it changes the role of the software engineer from a creator of “cool things” to a completer of small, marginal tasks.

While I sympathize with those who feel that way, on the balance, this critique rings hollow. As someone who spent over a decade developing using Waterfall methodologies, I get it. There really is a deep sense of satisfaction when you release a new version of a product with tons of exciting features you’ve been working on for months and months. There’s catharsis, accomplishment, celebration, relief. Under Agile, it can feel like you’re just a cog in a machine, digging through a never-ended backlog of stories. Finish a sprint, start another, like you’re working on an assembly line. But I can also tell you, as someone who spent over a decade developing using Waterfall methodologies, Agile is superior for many organizations for a number of reasons. And since it’s the new norm, the best approach is to figure out how to mitigate the frustration it can cause.

These two factors, combined with a general cynicism that software developers sometimes possess, can make coding feel like drudgery. There are always more tickets. You’re always accumulating tech debt. You’re working in code someone else wrote. Things don’t seem to change. What’s the solution? Well, it’s a pretty simple: At least once a year, your department or organization should take a step back and look at the work you’ve all completed since your last introspection. If done properly, it can inspire your whole engineering department to do great things.

The (at least) annual checkup

As we all know, everyone should go to the doctor once a year for their annual checkup. The doctor will look at your current health, but often will also ask “What’s happened to you in the past year?”. When assessing how healthy you are, it’s important to know about recent history. The same applies to your software development organization. It’s hard to know how to improve going forward if you don’t take a look at where you’ve been and what you’ve done.

Diagnostics

Here are some questions to consider during your annual checkup:

• What features have you shipped? 
• What tech debt have you addressed? 
• What infrastructure or architectural improvements have you made? 
• What documentation improvements have you made?
• How have you improved application performance? 
• How have you improved your deployment pipeline?
• How have you helped your fellow developers improve?

How does this work at NGP VAN?

One of the first things I noticed when I started work at NGP VAN is how seriously we embrace the “Inspect and Adapt” component of Scrum. Each development team conducts Sprint Retros, but we do much more than that: We have Epic Retros that analyze how things went cross-staff. We regularly take surveys that solicit input from all areas of the company about how effective a certain policy is. And we have quarterly all-staff meetings where we talk about where the company has been as a whole and what we’re doing next. One of our new team members, after his first retro, exulted “I have never been in any meeting like this!”

At the first all-staff of the year, we viewed a short video prepared by our Vice President of Product Management that summarized every single project we had completed in the prior year. It mentioned every team, what they had done, as well as all of the fantastic Democratic political campaigns and progressive non-profits we support. It was stunning and inspiring to see how much we accomplished, and help motivate us to do amazing things in 2016!

Do you really need to do this?

It not often that “one size fits all” when it comes to software development practices, but the answer here is clear: Yes, you do. There are numerous reasons, but especially if your software organization is young and growing, a periodic retro will provide much-needed perspective. It helps with morale and offers an opportunity to thank others for their hard work. If things aren’t going well, it provides an opportunity to talk about how you can do better in the future. That’s another reason why a regularly-scheduled retrospective is valuable – it forces you to grade yourself, at the very least. (Side note: This is also a good argument for sprint reviews and sprint retros.) To be sure, an annual retro isn’t a cure-all, but it can absolutely help address the two issues I describe above.

Especially for new developers, this perspective is key. You ARE changing the world, bit by bit. Nothing comes into the world fully formed. Some things take years and years before they catch on or are seen as revolutionary. Everything seems easy and more glamorous from the outside. But as will become apparent if you start holding an annual retro, changing the world is hard, time-consuming work, which is what makes it so rewarding.

Care to join us? We’re always looking for talented engineers. We have challenging problems, incredible clients, and all the free snacks you want. Join our team at https://www.ngpvan.com/careers, today!