All programmers are software devs, but curiously not all software devs are programmers
This is my logic about the relationships and distinctions between different terms that are often used in the tech industry, such as computer scientist, software engineer, software developer, programmer, and coder. These terms may seem similar or interchangeable, but they can also have different meanings and implications depending on how you define and differentiate them. For example, some people think that a programmer needs to have a certain level of skill or experience in coding, while others think that anyone who writes basic instructions for a computer can be considered a programmer. Another example is that some people think that a software developer needs to have knowledge of multiple languages and frameworks, while others think that anyone who writes a program or builds a component can be considered a software developer.
However, before I proceed, I'm warmly clarifying that this is just my opinion and my way of thinking. I do not claim that this is the absolute truth or the only way to look at these terms. I understand that different people may have different definitions or criteria for what makes someone a computer scientist, a software engineer, a software developer, a programmer, or a coder. I also understand that the context or situation in which these terms are used may affect their meaning and relevance. Therefore, I do not intend to offend or exclude anyone who may disagree with my logic or who may identify themselves differently.
So, ending the confusion (or actually increasing it ??) for you techies...
Computer Science > Software Engineering >= Software Development > Programming >= Coding
#ComputerScience encompasses #SoftwareEngineering, which either encompasses #SoftwareDevelopment or is synonymous with it, which encompasses #Programming, which either encompasses #Coding or is synonymous with it.
In other words: Coding is a subfield of programming or interchangeable with it, which is a subfield of software development, which is a subfield of software engineering or interchangeable with it, which is ultimately a subfield of computer science.
The deeper logic
Still confused, ha?
Let me explain it via storytelling and personas.
A computer scientist who's not dealing with software engineering?!
Meet…
Thea Pedersen, Computer vision researcher.
Ankur Gupta, Algorithms expert.
Thea and Ankur have different backgrounds, titles, and responsibilities, yet both are essentially computer scientists. They deal with the science/math aspects of the system that other employees do not, while dedicating less than 10% of their time to actual engineering.
A software engineer who's not dealing with development?!
Meet…
Lorena Moya, Software architect.
Eyal Katz, System designer.
领英推荐
Lorena and Eyal have different backgrounds, titles, and responsibilities, yet both are essentially software engineers. They deal with the engineering aspects (high-level stuff) of the system/app that other employees do not, while dedicating less than 10% of their time to actual development.
A software dev who's not dealing with programming?!
Meet…
Mariam Al Qubaisi, Tech lead for automated testing.
Luká? Novotny, Tech lead for Android app development.
Mariam and Luká? have different backgrounds, titles, and responsibilities, yet both are essentially software developers. They deal with the development aspects of the software that other employees do not, while dedicating less than 10% of their time to actual programming.
A programmer who's not dealing with coding?!
Meet…
Ye-jin Choi, SDK Integrator.
Ye-jin is a programmer who specializes in integrating SDKs for clients. He deals with the programming aspects of the software that other employees do not, while dedicating less than 10% of her time to actual coding.
An employee who's purely coding?!
Meet…
Luis Reyes, Coder (internship).
Luis is an intern coder who handles coding and testing aspects of the software that others do not. He also spends time acquiring skills and accumulating knowledge during his first year of his career.
Well-defined roles and responsibilities matter more than you realize
Having clear distinctions in place is essential for effective collaboration, accountability, and achieving optimal results. They help to clarify expectations, prevent misunderstandings, and ensure accountability. Unfortunately, the current state of blurred lines between roles and responsibilities is all too common in many organizations, which can lead to confusion, inefficiencies, and conflicts within teams.
This lack of clarity can result in tasks being overlooked, or worse, completed twice. It can also lead to a lack of accountability and finger-pointing when things go wrong. In addition, team members can become demotivated and disengaged if they don't understand what is expected of them. Overall, it can have a significant impact on the success of a project and the productivity of the team. By establishing and communicating clear lines, teams can work together more effectively, stay focused, and achieve their objectives.
Game(r) programmer at Zorbix
1 年Nice! Actually I've been waiting for such article.