So far, building things with code has been one of the coolest, and most sought out fields of profession. Yep, no doubt there. However, sometimes I get the feeling that a lot of people confuse software development with the misconception that our job is to code. Solely, code. Nope, that is wrong. Well, in part it is correct, I know. However, being a software developer is much more than that. Because sometimes things can only be learned from working with fellow engineers with more experience than us, or perhaps different experiences, I thought sharing my thoughts in this would be useful for you somehow, fellow engineer.
Development is not only coding
I started this post with the misconception that our job is to code, code, and code. And even though that is true to a certain extent, our tasks go way deeper than the code we write.
During my day as a software engineer, I find myself doing more than simply deploying features into prod. I would say coding is a reduced fraction of what it looks like to the people around us. It involves tasks like planning, estimating, writing tests, fixing tests, fixing tests (again), designing user interfaces, writing documentation, fixing bugs, doing quality assurance, helping, being helped, asking questions, being asked questions. Anyway, the list goes on and on. This should be enough to give an idea that our job is much more than building, there is a whole other realm of tasks that we have to do to make sure our work brings any value to the end user. Brent Rambo supports quality work.
Take the following example. Imagine you were a developer, and a client asks you to build an application which allows them to manage their whole inventory/stock, track sales, and get access to all the data in a dashboard with charts, and such. Now, you as a software developer need to have a good understanding of what the client wants, right? Yes. Correct. Next, you need to plan, estimate, and deliver. You will also most likely face bugs, just like any other application. And your client will ask you for more features, so you have to reestimate, replan, and adapt. These are just a few of the things you will have to do, and be aware of before, and during the process of building the project for them. This will help you ensure quality work, and a satisfied customer, because the faster, and better you can build, the happier they will be, right?
What does "software engineering" even mean?
Well, this is another big misunderstanding that people seem to have, and it is completely normal, by the way. First, what question should we ask before we even ask ourselves what "sofware engineering" means? We should ask ourselves what engineering means in the first place. That is where software engineering comes from. Without it, there would be no software engineering anyway.
The term Engineering by itself means "the application of an empirical, scientific approach to finding efficient, econmic solutions to practical problems" ("Modern Software Engineering", David Farley). It is basically the foundation of the thinking we should adapt in our profession as software engineers. If we rely on the notion that coding is the main "tool" to achieve the result, then we are fooling ourselves to believe that it code is by itself the means, and the end.
Code is a tool, a language like any other spoken language, just interpreted by our computers to perform tasks. That is what coding in its rawest meaning is. However, in order to produce high-quality code, and build solutions to business problems, we need to apply a rather scientific reasoning (combined with our code, of course). By doing so, we are ensuring that we are in the pursue of a more authentic meaning to what our role actually is all about, and pursuing solutions that are more efficient, cleaner, and fun to build, too.
Conclusion
While coding is definitely the languages we "speak", and use as a means to building something, our jobs involve much more than just that. It involves the scientific, engineering-based reasoning that helps us go beyond the code we write, and come up with more clever solutions as we gradually maintain a project. By understanding what the term engineering means, you are hopefully able to apply a more scientific reasoning to your work as a software engineer, and therefore build more clever solutions to solve real-world problems.
About the Author
I'm a software developer, and technical writer based in Portugal. I'm passionate about software engineering 👨💻 and I love to explore new tools in my day-to-day, and find interesting, and creative solutions to common business, and techincal problems. You can find me on GitHub. If you have any questions or feedback, feel free to reach out! 🚀
Top comments (3)
I like to think every problem can be broken down into manageable parts, start there, and Occam's razor your way through. Nothing is really so complex that with careful and slow organization it can't be solved. That's basically how I function :P
Yes, that, too, absolutely agree with you Martin! What is even the point of trying to eat the whole plate in one go when it is easier to bite smaller bits, one by one, right? :D Thank you for your useful contribution to this post! :)
You're very welcome!