For many early software developers and engineers, they view their role as mainly coding. Then they become disappointed when they find out they don’t really get to code that much. They think that their day should just be pounding away at the keyboard for 8 hours a day, but that’s far from reality. There is so much more to software engineering than just coding. In this post, I am going to cover other aspects of software development that is often overlooked by early software developers and engineers.
Problem Solving
Before you can code, you need to have a solution. In order to have a solution, you need to understand the problem you’re trying to solve. So, before you can code you’ll have to figure out the solution to a problem.
Depending on the company you are working at, you might not need to go through the problem-solving process because someone else has already done that for you. Instead, you’re told what to code and that’s it. However, in other instances, you would get the opportunity to come up with the solution first and then code it.
Understanding the Customer’s Need
Coding something just for the sake of coding something will not be beneficial for anyone. Coding something is only beneficial if it can bring value — in most cases, it would need to be valuable to the customers.
So, that means before you can code you’ll need to understand your customer’s needs (problems). To do that you’re probably going to be working with the business side of your organization (who are usually not technical people) to understand what the customers want and where they are having trouble. Depending on your organization, you might not find yourself dealing with this because someone else (usually higher rank) will be.
Evaluating Trade-Offs
Evaluating trade-offs for a solution is often something that is necessary when it comes to software engineering. It will be unique and specific to the purpose of the application. For example, if the app needs to be more reliable than fast then the focus should be a more reliable solution where it can be slower. Again depending on your organization, you might not find yourself making any of these decisions and instead be told what to implement.
Maintenance and Upkeep of the Architecture
The overall architecture of the software you’re building is very important. It is like the pillars that hold up a building and keep it from falling apart. Every time you add or change code you’re changing how much for the pillars to support and if it is too much it can start to crack and eventually break. As a software developer or engineer, this is probably outside of your territory (it’s the software architect), but it is important for you to understand what will happen to the application’s architecture as you add or change code.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What do you think that is part of software engineering that I didn’t mention in this post? How is your experience as a software developer or engineer? Do you mainly code or partake in the other things that are mentioned in this post?
To get in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.