Saturday, August 30, 2014

New Job = New Tech Stack

Every software engineer has been here, you start a new job and get introduced to the companies tech stack and either do not know or out of practice with half of it.  When you encounter this situation you are forced to choose where to start investing your time learning it.  Some things you are going to pick up just going about your day to day activities and others you need to work at.   The question is where to start.

Here is the parts of the tech stack that I need to learn or get more familiar with:

So where do I start?  The first thing that needs to be done is assess what makes a something important to learn which is a combination of usefulness and personal marketability in the software engineering community. I can immediately eliminate things like Mercurial, Confluence, and Rally because those are just something you figure out as you go unless there is need to become an admin.  There are other things that I can rule out due to them being easy to knock off when the need arises to accomplish a task like mockito, WireMock, and Jackson.  That leaves me effectively with two options Spring and AngularJS.  AngularJS is a very valuable skill ATM and Spring is the defacto standard Java framework that I haven't been exposed to yet in a professional setting.  Spring has a more immediate need so I will start there for my day to day activities.  So I will be reading up on the basics of Spring and doing tutorials while getting an environment setup to do AngularJS work as well. 

How to you figure out what technology to learn first when you start a new position?

Friday, August 29, 2014

Open Source Development Contribution Fail

As part of my efforts get more involved in the software engineering community and improve my personal brand I have been making an effort to get involved in an open source development project or two.  On one of my first days a new job I ran into a situation where I needed a utility method for a collection which was not handled by Apache Commons. Perfect opportunity to contribute back, right?  The change would have been a failure straight forward utility method so I went to the Apache Get Involved page and signed up for their Jira instance.  I wrote the code and was ready to submit my diff back to the community when I found it.  Someone else wrote a method very similar to mine and had an open ticket to have it merged in.  So close but a couple weeks too late.  The story won't end here I will find an opportunity to contribute back and write about my experiences doing it.

If anyone is involved in an open source project and wishes to pull me into it please contact me.

Monday, August 18, 2014

Contracting aka Betting on Myself

Today I starting working as a software engineer contractor.  It is a big change for me.  My entire career has been spent at two companies.  The first job at Kemper Insurance was where I saw myself working the duration of my time in the workforce like my father who is still working there.  However I moved to Boston with my now wife and Kemper was kind enough to lay me off and outsource my position on the same day I was interviewing at the company in Boston I would later work for.  Working for Safari Books Online, now going by just Safari, was an amazing company to work for.  They showed just what I should expect from an employer in terms of company culture.  In order to make sure my kids were in a good school district we had to move far enough away from the city that made my commute untenable so it was time to move on.  That leads me to here; contracting at ADP spending less than half the time I was commuting into the south Boston.  My goals as a contractor are to round off my resume, acquire a few new skills, and set myself up to land a great job.

A couple things I want to keep in mind while working as a contractor:

  • Be flexible.  It is not my code in any way shape or form.  Go with the flow.
  • Be positive.  There are team members who have been struggling with the project before you joined this team and they will be struggling after you leave. Just be a positive element on the team to help keep things moving.
  • Find a way to contribute in a meaningful way that your coworkers can remember you for.

This blog was started after I read another blog titled "Why software engineers should maintain a blog" by Chase Seibert so I am going to try to keep this blog active.  I have started a half dozen blogs over the years but hopefully I can stick with this one.