In the world of software engineering, your performance as a developer dramatically improves as you realize you will always continue learning!
There are some lesser discussed topics that aren’t always talked about in software. I thought it may be useful to share some of the things I have learned that I wish I had known when I first started my career as a software engineer. Before I dive in, let’s first discuss the difference between knowing and learning.
For example, I know I shouldn’t eat buffalo wings, but despite my doctor’s warnings, I order them almost every time I go to a restaurant. This is because I haven’t yet learned that eating buffalo wings in excess is hazardous to my health.
The acquired knowledge has not changed my behavior. I can read all kinds of books about the health problems that delicious fried, spicy goodness can bring, but my habit hasn’t changed.
When I was starting out as a software engineer, there were many lessons I knew, but it took me a while to actually learn them. I may have read these lessons in books or from one of my wonderful professors in my CS courses, but it took me a while to internalize them.
Much of the learning at Launch Academy is designed to be experiential, so that you can really feel some of these things prior to starting your career. Awareness must come first. My hope is that this article will help call attention to these areas, and to recognize their vital importance in the field of software development.
Majestic beard mastery aside, what can this dude teach us about Software Development?
Vilfredo Federico Damaso Pareto’s work in the 20th century led to what is now known as the Pareto Principle, which is a generalization that states you get 80% of results from 20% of the effort.
As developers, we learn to love patterns. We can stand on the shoulders of giants and apply the proven solutions of others to the problems we regularly face in our work. If we simplify and look at our workweek in the application of the Pareto Principle, the theory is that working 1 day out of a typical 5 day workweek provides us 80% of the results. Yeah, I totally know what you’re thinking, so when do we start having 6 day weekends?
When I was learning to become a software engineer, this principle fascinated me, because I saw it playing out everywhere.
As software engineers, our jobs are to deliver b usiness value. Imagine if all the software teams I’ve ever worked with spent 100% of their time on the features that made the most impact!
So, what is business value?
Effort that produces business value results in one or more of the following:
As a new developer, your job is to protect your time and ensure you’re doing all you can to deliver as much business value as possible. Below, you’ll find three traps all developers typically fall into at one point or another.
Imagine the product manager or CEO of your hip ringtone clipping app startup walks into your office. “I’ve got the coolest idea for a feature. We should build a drag n’ drop widget that allows for the uploading of songs, which we’ll embed in an iframe so that users can preview the song.” Either they’ve spent too much time reading buzzwords on TechCrunch this morning, or they have been thinking about this feature for a very long time.
The question to ask her is, 'will the business value of the feature warrant its technical complexity?’
As software engineers, it’s easy to spend our time building features that users do not want or need. Having a quick conversation around business value before writing any code can save a lot of unnecessary time and effort.
It can be even more tempting to build something technically complicated that uses the latest whizbang technology. There’s nothing more tragic than an elegantly built feature that no one uses.
Now that we know that you were hired to add business value it's time to learn a few things about business! Maybe you could learn a few things about management, marketing, sales, or the problem your software is trying to solve. The more context you have, the more attuned you’ll be to building what’s needed. For more on this idea, check out what Jeff Atwood has to say about it .
One of the things I love about Launch Academy is that our students take the experiences gained in their prior careers with them when they enter the wonderful world of software development. What unique background or perspective will you bring with you to your new career as a developer?
Like many engineers, I have a problem. I’m a perfectionist. I want my code to be pristine. I want my tests to be exhaustive. At a certain point, you have to be comfortable pressing the “ship” button.
If we go back to Pareto, is it really worth spending 80% more time to get the last 20% of the results? To quote another famous European, “perfection is the enemy of good”. As a developer, you’ll find that most software projects are never finished, and that the business value of a feature can never be realized unless it gets released.
As developers, our most precious resource is time. How will you use it to produce the most business value possible? Please email me at d email@example.com and let me know!