Tuesday, August 22, 2017

Long Hiatus - Software Engineer Level 1

So I work at an automation firm now, and hopefully it will provide a good means for me to gain more experience and start learning some good, practical skills for computer programming.  After a few months, my official title is now "Software Engineer Level 1" and working on company software projects.  I was really excited to be transferred into the department, because I'd be around people who know way more than me who I would be able to learn from.

There have been some surprises already.  To build our software, we're using Visual Basic.  I did not know Visual Basic even existed a few weeks ago.  Our team leader is comfortable with Visual Basic and prefers to program in it, so since I'm the new one on the block, I just shrugged my shoulders.  So far, in the past few weeks I've had to do a crash course in MVC in VB.Net, C#, SQL, and Jquery.  I won't be able to use my Python skills for awhile.

Visual Basic was not difficult to learn.  It was annoying to go from Python where variables are automatically typed to VB where you have to declare a variable type yourself.  I was so used to typing "a = 5" and just leaving it that it took me a good while before I got into the groove of it with VB.  I had to also learn a bit about how classes and namespaces are handled, but a lot of the general idea is the same.    I do find VB a bit verbose, but that's coming from slick, clean Python world.

The main thing I'm learning is how to plan out a large program.  The software we're making for the company is pretty big.  We have dozens of objects, we have a big database of all our employee information, dozens of stored procedures, and pretty much everyday, one of the managers drops by our programmer cave, leans in Office Space style, and says that they want to be able to log in to our program on their phone and start their cappuccino maker remotely so it's steaming hot by the time they sit at their desk.

It's difficult to sit down with someone who isn't a programmer, but will be the end user of your product, and translate their needs and problems into code, but also a fun challenge.  You have to identify the things that computers are good at and how to best leverage it to solve the problem:

  • Is it repetitive?  Let a computer do it.
  • Is there lots of relevant data to store and remember for later? Let a computer do it.
  • Need to transform the data multiple times?  Let a computer do it.
People tend to be very helpful in describing what their needs are, but a lot of planning out our new software is anticipating certain needs that maybe the end user didn't think about.  In the end, our software is going to save hours and hours upon hours of time spent doing repetitive tasks and will offer accuracy of information which should improve all facets of the business.  I love efficiency.