Become software engineers, not software integrators.
Ever since its inception, the IT industry has been evolving every day, by giving better and more awesome technology experiences to end-users.
On the other hand, the industry has also continually focused on reducing the development time and cycle for software engineering teams.
A significant portion of IT engineers & organizations are motivated to ease the development process. This in turn has become a race to give the best technologies (frameworks, tools, etc.) to engineering teams.
In this race, their focus has gradually shifted from “ease of development” to almost “no development at all”, i.e. making tools, which allow the engineers to just integrate stuff to provide the final product. Essentially, plug and play.
Of course, the big advantages because of this are that:
- Now the companies which are building software for businesses can focus more on business ideas.
- With a reduced development cycle, companies can build many more software products.
However, the concern starts when engineers, who get used to the plug & play tools, start losing core engineering skills like optimizing, maturing, and architecting the code.
For example, in the early era of Android native app building, engineers needed to focus on maturing various list screens by optimizing memory consumption and reusing each view in those. Now, the Android framework itself has provided so many mature views that developers just need to integrate them into the system.
Or we can look at something like Flutter. It has made app development seem like a piece of cake. But in this convenience, do we try to understand how Flutter makes it a piece of cake? Do we go under the hood? Most often, we don’t.
We have developed a mindset which priorities ease of developing applications over developing better applications.
This over-dependence on plug & play frameworks also results in engineers blindly following practices “recommended” by tech giants. For example, when Google started recommending the MVVM pattern, teams started implementing it blindly, without even understanding its actual purpose or whether it is even relevant to their application.
To stop this knowledge shedding, we must try to understand how the library/package/pod/gem that we are using actually works under the hood. We must try to understand how exactly it solves our difficult issues and time-consuming tasks.
This will empower us to ask ourselves the most important questions like:
If I solve the same issue, can I make it more optimized? Can I make it consume even less memory? … and more.
This will help us build systems that are much better for our needs. This will also help the new generation of engineers build a stronger engineering mindset.
P.S. This doesn’t mean that we reinvent the wheel and restrict ourselves from using already available tech frameworks/packages etc. Rather, while using any technology, understand how it works and solves the problem.
