Tuesday, September 18, 2018

Be the change, don't wait for change!


Let me walk down memory lane for a few moments. My first formal job in the technology field was actually not doing software development, but was in sales and training. I sold IBM PCs, Compaq Computers and System 36’s. I was also expected to teach courses for the store that I worked for – Lotus 1-2-3 and dBase III. For those of you with memories going back that far, yes, I’ve dated myself. I would venture to state that most of the team that work with today, would have no clue what a Compaq luggable computer was nor even understand what an IBM Baby 36 looked like.

I sold computers for a year before I found a company that would hire me as a developer. While I did well with the sales aspect of it, I knew that selling was not my cup of tea and was not something that I wanted to pursue as a lifelong career. Getting that first development job felt right. Ok, I had been doing contracting since I was a teen, so this was really just coming home to what I knew I was meant to do. Pounding out code was comfortable, solving problems gave me a rush and was what really fed my soul. It was good to know what I wanted and then to find a company actually willing to let me pursue my passion.

I was hired to come in and develop software using Clipper (this was a compiled version of dBase III). Creating financial solutions for a very specific industry. I learned a lot in that first professional development role. How to truly plan for and test code – testing was not an afterthought, but something that was worked on just a diligently thru the development process as was the actual coding. I learned how to work on a team – understanding the role of the people creating the requirements, performing user testing, performing QA testing and then having to package up and deliver the code. Team also meant working with other development engineers to ensure that the stuff I was building fit with the stuff that they were building. When I was doing contracting, I was a one man show and did not truly appreciate the interactions needed to fit my stuff in with the work everyone else was performing.



Over the years I have had to learn and use several languages. In middle school and high school I formally took a Fortran course and taught myself how to code in basic. I can’t remember if I took Cobol or Assembler as a class, but I know by the end of high school, I could use both of those languages. Assembler was not something I enjoyed, but I could do it. I had also learned how to program using Basic. So, by the ripe old age of 18 I was able to hack around with 4 separate languages. College reinforced Assembler and added Pascal into the mix, along with several different theory courses. While I was acting as a sales rep, I was able to have access to a Compaq luggable and during the evenings I was able to teach myself Turbo Pascal. I also taught myself dBase III and was able to get a hold of the Clipper compiler and teach myself how to use that to compile the dBase III programs I was creating. Since then, I’ve taught myself additional development skills – C, C++, MS Visual Basic, CA Visual Objects, Java, Python, Ruby, Ruby on Rails, JavaScript, PHP, Objective C, Swift and others. I’ve also figured out how to use HTML, CSS and other web tools. This doesn’t include all the frameworks that I’ve learned along the way. I will be the first to admit that I’m not an expert in most of the previously mentioned languages, but I at a minimum can hack my way thru a development session using the languages mentioned above.

Why am I listing off all this stuff? Well a couple of reasons:

1)      Lifelong learning is critical within the technology arena. Those who think that they can learn 1 or 2 things and use that their entire career are in for a world of hurt. I would say over the last 30 years, the pace of change and expectations of picking up different development skills has accelerated – much the same as in other professions. Today’s focus on DevOps and other paradigm shifts, is forcing developers to learn new skills and become even more adaptable.
2)      There is a tendency to ‘get comfortable’ and develop new code using technology that you are familiar with – you can get it done quicker! However, at least in my organization, I sometimes need/desire to have people jump between teams and this requires that they be able to utilize different technology skills – C++ vs Java vs Objective C, with a little Python thrown in here and there to make things interesting.
When I first started programming there was no internet, no on-line help, no instant messaging to help me figure out how to get around different programming problems. There were thick manuals that I had to sit back and read. Today, engineering teams can use the internet to find solutions to problems, to find sample code or entire libraries/code that solve the particular problems that they encounter.

I remember having to write my first authentication and control system to wrap around a system. Today, I can go out to git and find dozens of complete libraries that perform basic application authentication to complete 2FA and access control within applications.

The tools available today make it much easier for developers to gain a basic proficiency of a given language. You can find on-line tutorials that guide you thru downloading a new language, creating your first project and stepping you thru the ins and outs of the frameworks. I would have killed to have access to those types of tools as I was starting to develop software.

As software engineers, we shouldn’t be afraid to pick up new skills. As leaders, we should be encouraging our team members to take a look at the new languages, scripting languages and frameworks. We should all be looking at ways to increase our efficiency, deliver functionality faster, increase the quality of what it is we are building and keep an eye on emerging trends that may impact the systems we create and support.

If you'd like more information on my background: LinkedIn Profile

No comments:

Post a Comment