The I-K-E-A model of improvement for Software Engineers: Part - 1

Let me start with a disclaimer that this acronym isn’t associated with or an attempt to campaign for a certain chain of furniture superstore, but I am happy if that also is a side effect of using this acronym!

In today’s day and age of social media, internet and ease of access to content on the various platforms on just about any topic, anyone and everyone can appear or claim to be knowledgeable in just about any field. This gives rise to a very interesting question: how do you find out if someone (or yourself) can do a given job well or are growing and learning in their field of work? Let me explain.

Let’s take the world of software programming for instance.

Picture a newbie developer who has been asked to implement a feature or enhancement to an existing project. He/ She being a smart cookie and possessing great skills in finding something on the web and faster skimming or reading skills, will quickly go to the web, search for the same or similar problem they are looking to solve and they are most likely going to find several existing solutions or suggestions which they can readily apply and get their job done. This does not need them to have extensive experience in that particular problem space, the language constructs or even programming practices in general.?

Now picture a developer who has extensively built their knowledge and command over programming, the specific language and the domain over the years with a lot of practice and hard work including making many mistakes. They might rely on their skills and experience and come up with a solution and implement it in similar or faster time with similar or slightly better quality. In fact it might take them longer since they are looking to try and do things by themselves and might take a few iterations to achieve a solution which meets the quality bar.

So why is this a problem you may ask? Well..

Not one, but multiple problems

A. You as the leader of the organization

1. how do you justify or distinguish having a seasoned developer for the given job and thus the (dollar) cost of development?
2. how do you know if your engineers are learning and improving over time or not
3. how would you be able to put the best possible solution out there and beat the competition?
4. how do you foster innovation if most of the readymade solutions are just a few clicks away?

B. You as the engineer in question

1. how do you grow yourself in your skill levels, being a better version of yourself? How do you know if you are gaining experience?
2. what incentive does one have to dig deeper and build expertise in a given domain?
3. how do you compete and be successful in the fiercely competitive industry where for each since job opening, there are thousands of skilled applicants lined up?

In this article, I am looking to focus on the latter (“as an engineer”). Let’s save the organization view for another time.

So, again, why is this a problem?

As an engineer, you will likely get into a false confidence zone that you are able to deliver (or have been delivering) and doing a great job in your role. This also will fatigue or get you into boredom after a while because the cycle will be similar and will start to get ‘mechanical’ regardless of which work assignment comes your way. However, the organization knows better (let’s assume :-)) and will not treat you with differentiated rewards or extended scope. So bored, stressed and desperate for growth or higher salary which you think you deserve, you will look for or make job switches frequently. You will likely get a slightly better or fancier title or one time slightly higher salary when you jump jobs (because, again, the organization knows best...about how to attract engineers to join them :-)).?

However the same cycle will keep repeating and after a few years and few job changes later, you will find yourself stuck and unable to get hired elsewhere as well!! Heck, you will not be able to do a good job with or clear the interviews as well for the higher level of jobs and you will wonder what just happened: I used to be so great at my job but all of a sudden I don’t know what hit me?

Does it sound familiar? (well, firstly, let me clarify, this is not my autobiography so that angle is out of the picture :-))

OK, so now I have your attention. So what should I do, you may ask?

Here I would like to introduce 4 terms: Information, Knowledge, Experience and Application [or I-K-E-A for short]. Lets review them

I: Information

“Information” is a self explanatory term. In this day and age, “information” is available in abundance online. To obtain the right or relevant information, one needs to look for the right places and should know the best keywords or techniques for an internet ‘search’. In cricketing terms, this is like the reams of articles, editorials as well as the scorecards or live match telecasts. In software engineering terms, these are like programming language manuals and pre-solved Q&A pages like say on stackoverflow or quora to name a few.

K: Knowledge

The parts of the information which are useful and worth learning or knowing is what in this context I would call as ‘knowledge’. Essentially, according to me, ‘meaning’ of ‘information’ is ‘knowledge’. In cricketing terms, this is like extracting trends, techniques and establishing retrospectively what a player would have done better. Which shot should be played in which match situation and which kind of delivery or which length to bowl in which pitch condition is an example of knowledge. In software engineering terms, this means knowing which language construct does what and which one should be used in which case: e.g. abstract class vs interface or for loop vs while loop etc.

E: Experience

Doing something multiple times in different ways, doing similar things at least one time, observing something alongside you being done multiple times by someone and observing similar things being done by multiple people alongside you leads to experience of having seen something in action. It completes the picture which starts at theoretical ‘knowledge’. In cricketing terms, it is like being part of “match practice” or “net practice” where you are part of the action as well as you are observing other players going through it. Here you practice or see someone practice what needs to be done in which pitch, weather or match situation. You practice something multiple times over and over if you want to improve that aspect of yours. Heck, it also means going into bat when 2 early wickets were lost and one needs to consolidate or when the openers have piled on the agony and one has a free pass to slog it out in the last overs.

On the software side of things, it means writing code (and reading others’ code) for multiple types of problems and products and which are in multiple different stages of development like developing from scratch or a V2 of a product or one which is in maintenance mode. Heck, it also means executing different aspects like fixing a bug or working around it, testing your changes, debugging a problem or releasing you product to the customer.

A: Application

This is really where the rubber meets the road. One has to ‘react’ or ‘act’ to the situation which presents in a real life and should ‘do’ what needs to be done. In cricketing terms, it is ‘shot selection’ and ‘execution’ of your favorite shot in a real match situation for a batter. In software engineering terms, this means being able to pull out the right language or design construct or choose the right architecture for the problem at hand and being right about it based on the constraints like time to market, scale of the solution needed or whether writing code from scratch or trying to enhance an existing product towards its next major version.

How do they come together in this context?

If you are hooked, please wait for the part-2 of this article and like/ comment if you would like to see that come out!