Software Engineering is much more than just building APIs

With the advent of new and charming frameworks like Spring Boot and Hibernate, there has been an observed shift in the definition of “Software Engineering” and “skills” of a Software Engineer.

Many of the resume that I come across have one or more of the following “skills” highlighted:

• Spring MVC
• Spring Boot
• Hibernate
• JUnit
• Jenkins

It goes without saying that all of the above tools/frameworks barring Jenkins primarily work with Java, as most of the candidates that I interview come from the same background.

The thing which baffles me is the fact that how can “using” a framework become a skill. I can understand that these frameworks have made the lives of developers easy, because abstraction is the most valued Object Oriented Programming Principle among developers today. However, over time, we, as developers have failed to realise that this simplicity comes at a cost. Although most, if not all frameworks are open sourced, but there’s just a handful of developers who actually take that effort to dig into the source codebases and explore the work behind the scenes.

If I choose a software developer at random, and I ask him/her that how would they develop a HTTP based API. Chances are, that 2 out of the first 5 words in response would be “Spring” and “Boot”. Very few care about what an API is, or how does it get exposed over internet, resulting in us being able to access those as “ReST APIs”.

If a developer just knows about these frameworks without understanding the core concepts, then he/she inherently inherits the limitations of these frameworks. What I really wish these frameworks to do, is to take up the role of supporting cast i.e. the developers should learn and understand concepts, design patterns and coding conventions that concern them and then make use of these frameworks to reduce the overhead of writing boilerplate code.

Once this happens, the resume would start looking very different. The skills would be as follows:

• Designing a software subsystem using the established design patterns
• Conversion of designs to functional code
• Automated Quality assessment of the code
• Setting up auto deployment pipelines

Now this gives the interviewer a much better idea of what the candidate can do. This also creates an impression that the candidate isn’t tied to a single tool/framework to solve a problem.

I have always been of the opinion that Software Engineering is an art, which makes Software Engineers artists. Flexibility and adaptability is critical to an artist and the same goes for us as well. And getting hard wired to a tool, framework or even a language is certainly not the way to go.