Based on my work experiences…. The following posting, considers an Individual Contributor as a Software Engineer
So you have secured your Computer Science graduate or post-graduate degree, and now have earned the right to be called a Software Engineer. You join the professional ranks of Programmers, Software developer, Software Engineer – in the office workplace. Whatever title you may go by …. Your primary task is to crank out code, using Software languages — for new products, and provide code/bug fixes for the lifecycle maintenance of these products. You are highly respected in the world of professionals, as someone who is somehow smarter than others are. You are classified as an Individual Contributor, as you work best alone in the majority of cases. Of course you interact with your peers to develop and integrate a larger software solution.
Not everyone can enter this profession of nerds. You not only need a well-developed left part of the brain – for logic, math and science…. but also a pronounced right half for creativity. You have the ability to quietly think in ether space and resolve complex logic and structural problems as you develop solutions for new software products and applications. Two categories of skills are required, for every successful Software Engineer:
Qualitative Skills (you either have them or you do not – you cannot acquire them). Of course, your Computer Science studies helps you sharpen these skills:
- Ability to work with logical abstract constructs
- Ability to work with complex intangible concepts which are inter-related
- Ability to translate a real life requirement into logical machine language based software components
Quantitative Skills (Skills that can be “learned” … or acquired)
- Syntax and structure of Software languages and associated tools
- How to write/develop, compile/make, run/debug, integrate and test any new software code components – the logistics of software development
Ass you progress in your Software Engineering profession, your Qualitative skills will constantly be honed and sharpened, as you become more and more proficient in your evolving career
What most of us often times tend to neglect, is our Quantitative skills. They tend to stay close to the start line of our careers and our new learnings tend to be limited to our specific work/organization environment. Look around you at the constantly changing technology environments. My observations apply to the majority of the Software Engineering professionals who are guilty of this approach/attitude. At the same time, I can say with confidence that I know lots of software professionals who stay in touch with emerging new software languages, operating systems, new tools and techniques – which help them bootstrap their careers. There is no end to the pursuit of knowledge and learning. This process has to be driven internally by the same desire that drove you to become a Software Engineer in the first place. The day we stop doing this – our decline starts.
The irony here is that almost all other professions – doctors, nurses, lawyers, technicians, civil engineers, and teachers – are required by local/state laws, which mandate their professions to periodically be “re-tested” to ensure they can continue their practice. The premise here is that the changes related to their practice are so rapid – that they have to relearn the deltas, to continue their practice.
Although such a requirement has never been imposed on Software Engineers – I believe that such a mandate should be self-imposed. A SW Engineering degree acquired, let us say 10 years ago – has become obsolete from a Quantitative skills perspective. We owe it ourselves, and the sanctity of our profession to, regularly attend courses, read technical literature, and experiment with new skills to stay in touch with our changing technologies.
Take my case for example…. When I studied Computer Science, my Quantitative skills at Programming was limited to Basic (Beginner’s All-purpose Symbolic Instruction Code) and Fortran (Formula Translation) where every 80 character line of code we wrote, had to be ‘punched’ out on a single card like the one below:
So if my program had 150 lines of code, say to identify the prime numbers between 1 and 100 – I had to first get my stack of 150 punched cards (being very careful to ensure the ordering was maintained) based on my Basic / Fortran code. Then I would go to the Computer center, where my punched cards would patiently wait in a queue (batch processing) for a specially trained operator to submit it for “compilation and execution”. Once executed, the output was a few sheets of Computer printout, listing the prime number set. The process would take at the very least 1-2 days. Under heavy workload, probably 2-3 days. SW Engineers today are extremely fortunate to live in our world of ‘instant gratification’. If a build takes several hours to complete today, everyone complains. Imagine living in my time where a lifetime would pass, by the time we solved simple software coding problems.
Clearly, I have had to learn and re-learn my Quantitative skills multiple times, due to my pre-historic background, and the quantum jumps in technology over the last 30-40 years. Even, if you have graduated just 10 years ago, I would vouch that every few years you may be feeling the same way I have felt every 10 years.
Recognize this, and for a successful and satisfying Software Engineering career, devote that extra few hours every week, reviewing technical literature and browsing the net for latest developments in our profession. Ensure that you are always a few steps behind the leading edge of software technology
Life experiences to share.... 