Wednesday, October 22, 2014

Yet more salary surveys

Every so often I like to look at salary surveys.  On average I have changed jobs about every two years over the past two decades.  So surveys come in handy.  Here's a couple that I came across recently.
This is a pretty good survey from a respected name in software.  Not really my cup of tea, but I program often enough to find it interesting.

Design News 2014 Salaries for 10 Engineering Disciplines
I check Design News a few times a week.  Usually they post/repost interesting items.  But this survey is really more of a overview of salary ranges.  There's no commentary about regions of the country, years of experience, etc.  I suppose it might be useful if you were a parent talking to your kid about how much they might make as a n engineer.  I'm in that situation for at least the next few years, so that's why I looked at it.

Sunday, October 19, 2014

Yet another company

A dozen years ago the biggest risk of a startup smacked me upside the head: the company ran out of money and closed it's doors.  Since that first experience in the high-tech* startup world, I've worked at a half-dozen or so other such companies.  Over half of them are no longer in existence.

I have accepted that, but I was never happy with it.  This past summer things went downhill with my latest company.  Within a month I had offers from three companies: a temporary contract gig at a mid-sized company, a large fortune 500 type, and another startup.  Sometimes it is good to mix it up, so I decided to ride with the behemoth.  I've been here two months now - we'll see how it goes.

* My definition of a "high-tech" startup includes actual hardware.  I'm sure a lot of smart people work at companies developing new apps for smartphones, algorithms for web-hosted databases, or some other clever software tool.  But unless it involves some newly-discovered applications of physics/chemistry/biology, it doesn't meet my criteria. That's just my bias.

Sunday, July 13, 2014

PXI work

So I found this link on EDN about PXI systems last year when I was doing some research for a new project.  I was going through old notes this weekend & cleaning up some files when I found it.  I'm not quite sure anymore why I saved it.  Maybe it's because the author mentioned hybrid slots?  I bookmarked the link last year when I was shopping for a PXI chassis for a new test system, but that's as far as memory takes me.

Anyway, I started thinking about PXI-related issues again this past week, and stumbling across this link reminded me of the experience I had selecting the hardware last fall.  After I had determined how the the test system would work, I made a list of all the hardware I needed: DMM, power supply, multiplexer switches, and relays.  It was too much for a cDAQ to handle (as much as I liked the concept), so I started shopping PXI companies.

I priced out what I needed from four different vendors.  At a startup company you try to keep the costs low, so I spent over week justifying the cost for the system.  If the test system would cost $10k or more, I had to show the legwork to minimize that cost.  Of course the expense of someone like me - getting paid what I was paid - digging around to save a grand or less didn't make much sense.  But so it goes.

I ended up buying the PXI gear from NI, and the test system worked.  And the one thing I got out of that week I spent shopping PXI prices?  There wasn't much difference between the vendors.  Originally I tried to shy away from NI since I assumed their stuff would be pricey.  But in the end it was barely more expensive than what I could get from the other three companies.  Learn something new every day, I suppose.

Sunday, July 6, 2014

My experience with Labview OOP

About a year ago I started working at a new company.  One of my first tasks was to automated  functional testing for a robotics controller.  When I started we were shipping individual units out for sampling, and I had to test them by hand.  That took about 3-4 hours (including setup time and recording all the data), and we didn't cover all the testing we should be doing.  So my goals for the project were to:
  1. Reduce the time down to ~15 minutes
  2. Automate it so a technician could easily run it
  3. Run additional tests that couldn't be done by hand
  4. Save all the data to a database
Once I mapped out the program requirements and logical flow, I decided to make this my first foray into object-oriented Labview.

I had taken a class in LVOOP years ago, and I had read how-to's and  case studies with OOP in Labview, but I had never used it for a work-related project.  There were several reasons I used.

  • I was re-engineering a program written by a previous engineer so I had to stick with pre-existing logic.
  • I was writing small VIs for a larger TestStand implementation
  • My programming partners didn't know LVOOP at all.  
Plus I may have been a little intimidated by the whole idea of an unknown architecture.  So I stuck with the standards: state machines, producer-consumers, and event-driven programs.

But now I had no excuses.   It was a brand new project, I was the only one working on it, and the project's complexity cried out for a sophisticated solution.  This was the perfect time.

And you know what?  It wasn't hard at all.  Maybe it was the OO programming I had done before in VB and C++, but the implementation went smoothly.  The only Labview-related glitch I had was early in the project when I tried to update a VI class member, but I worked it out.  And those classes I wrote for that project ended up being very reusable for two other projects I developed later on.  Excellent.

Tuesday, May 13, 2014


So I read this interesting little tidbit about an ancient language that I used for my grad school work at Fermilab.  Kind of neat.

Tuesday, April 15, 2014

Noncompete agreements and who owns experience

In Massachusetts, the governor is proposing to ban noncompete agreements.  Go Deval!

My first experience with such agreements stretches back to 1996.  This tech company wanted to hire me, but one of their conditions was I sign a piece of paper stating that if I left the company I couldn't work for any other place doing similar work for a couple of years.  When I first read that I was thrown for a loop and almost turned down the offer.  But then I talked to a friend in law that said those things were hard to enforce - such docs were used more for scare tactics in the tech industry.

Why would a company want to use intimidation tactics to keep their employees from jumping ship?  I can understand not wanting someone to go to a competitor with trade secrets, but there are already some laws in place to prevent that.  But wouldn't a more positive solution be make working there too good to quit?  When I worked at Hewlett Packard in the late 90s they called it "golden handcuffs."  All the perks of working at HP just made it too depressing to leave for some other company.

Another thing that comes to mind is that the company using a noncompete agreement is being hypocritical about experience.  When they look to hire someone, they prize that person's experience in the industry.  But then they turn around and damn someone who wants to take the experience they've acquired to a different company.  That really irks me.  Any experience I've gained in the course of my job (writing programs, building test systems, going to conferences, etc.) is MINE.  The company pays me for the work I do, and they own the product of that work.  They do NOT own the knowledge that I've gained in the process.  That knowledge and experience I've gained by being a good engineer and deliberately learning new things.

On a related subject, you could always watch that bad Ben Affleck movie Paycheck.  Then again, maybe not.

Monday, March 17, 2014

Job satisfaction

As my children have grown older, I've tried to describe to them two important things about the working world: doing a job the right way, and the hard-to-define satisfaction you can get from a job well done.  I had the perfect example described to me this past weekend.

My wife teaches at a local high school, and the hockey team made it to the state championship game.  To show our support, we attended the game.  At the game I bumped into Gus, whom I used to work with at a startup company I left back in 2011.  His company runs the IT support for that company, and I worked with him to implement the database I developed as well as my test systems and analysis software.  We talked some about how the company was doing, and Gus mentioned that the database, the test systems that write to that database, and the programs that pull and analyze that data are all still actively used by the company.

Now THAT is a really nice feeling.  I must've done something right.