This post has been migrated from medium.com/@injulkarnilesh.

The other day, I was discussing with other few of my Software Developer friends about how they think they have grown in the industry; and we came up with stages that each of us have gone through in last 6–7 years of industry experience.

By no means, any of us called oneself proficient in anything, but we just grew in the industry becoming better versions of ourselves, and we went through these stages :

Learner

So, it all began with we joining the Software Development industry as we graduated from engineering colleges with Computer Science degrees.

We joined different organizations. Each of us went through 2–3 months of technical trainings where we were taught what we were supposed to learn. We learned different technologies; few went on mobile development, few on web development, few on mainframe and so on. What we had learned in college was helpful but was not enough to start with actual real world work.

We were learning even after training as to how to write readable code, how to test your code at unit or overall level and so on. We weren’t assigned much of responsibility because we were fresh out of college and hadn’t had much of a real experience, but we were supposed to learn and that is what we were doing. We sat with seniors and learned how they code, how they walk through code, what tools and technologies they use.

In this learning phase we mostly learned what it takes to do a day to day job.

We learned how to be done with given tasks.

We, out of own interests, learned new technologies but we would forget those if not used. We were having fun writing code and seeing it work on local machine and production.

But while learning all this, we were not really learning basics of frameworks and technologies that had been used in projects.

We had more to learn, as we were getting assigned more complex problems whose boundaries crossed methods and classes.

Frameworker

We had been working on a code that was using few frameworks but we never cared to understand how those work. In my case as a J2EE web developer, I had used Spring, Hibernate and tools like Maven. I had used @Component kind of annotations but never bothered to understand what happens behind the scene.

We loved these frameworks. Now that we had written code using these frameworks, we found it interesting to change or add configurations for these frameworks. It was a big a deal to know what configuration files are used for what framework and what can we do inside those configurations.

We started spending time learning more about these frameworks because we now were working on more of end to end flows for which it was necessary to know how these frameworks work.

With knowledge of such tools and frameworks we started working on our own small projects and ideas.

Basics adopter

Mesmerised by the magic of frameworks we became hungry for more. Having configured the framework to do something or someway, we got interested into how does that work? On digging into details we came across the fact that it all boils down to basics of programming and the language.

“Why” configuring a servlet is needed, “how” annotations work, “what” is http and stuff like this became matters of interest to us and we found our answers by researching and trying out stuff. We got to know importance of having clear basic concepts, so that understanding new frameworks and libraries wasn’t a big deal anymore.

Somewhere in this stage, many of us who were web application developers, caught in a whirlpool of Javascript frameworks. We tried many of them. We used a few on them. Initially it was a brave new world but after a while it was just yet another new framework trying to solve the same old problem. We followed, and still follow, as much as we can to keep up with the fast moving Javascript word; but then most of us gave up learning, trying new things until it’s essential for the job at hand.

One way or another, we realised all new libraries and frameworks, be it of any language, are just wrappers over basics of the language’s features and concepts. Many of us were lucy knowing the basics, many of our colleagues were not.

Googler

After a while, remembering a syntax, or how to do basic things become just too much to ask for. We become confident in languages and frameworks that we had been using for many years now. Googling a code for simple things became a daily task (especially for JavaScript). None of were ashamed of it, but rather were proud, because we knew what to google.

This is serious. Given the problem, we knew we could do it, because we knew we can’t be the first to face it.

Number of open Stack-Overflow tabs increased in browsers.

Writing code become a second nature. But with it, we started focusing more on other things like designs, code readability, programming principles, best practices etc.; these become next areas of interest for us. Designing systems at a little higher level than methods and classes become more interesting for us.

Problem Solver

We started realising that we write code to solve some problem, and it is important to solve the problem than to write the code. Our focus started switching from code to problem. Before jumping into the code, we started analysing the problem in more details.

We started proposing, discussing high level solutions to problems instead of just writing code for assigned tasks.

We learned listening here.

Looking into issues, digging into logs which were boring than the coding became equally important and interesting. We started looking for new frameworks, practices, tools suitable for our problems instead for just sticking to what had been used so far.

Coming up with ideas, running different scenarios, trying different solutions were the things we went to office for.

Designer

Having achieved some confidence in code, and solved some problems we started becoming designers. Designing new systems, refactoring existing ones with newly gained focus on the problems become more interesting.

We, the listeners in the meetings, stood up, picked up the markers, and went to the boards.

We started proposing design ideas and solutions. For it, we had to cross our language and framework boundaries.

We started questioning existing processes, guidelines, designs and started finding chances of improvements. Not only did we found out problems but also proposed (our versions of better) solutions.

It is fun; but sometimes boring, as we don’t make design changes that often. Coding is still and will be the thing, but these other factors have become equally (or maybe more) important and interesting.

Next

/* TBD */