Must read/view for LabVIEW Consultants
If you are a LabVIEW Consultant, here are a few resources that are invaluable.
I am part of this group that my friend Malcolm has organized called "The Business of LabVIEW". We are a group of LabVIEW Consultants that get together regularly to talk about running LabVIEW-based consultancies and all the various challenges. Most of us are fairly accomplished LabVIEW programmers, so the challenges are rarely technical but often revolve around the business side of things: sales, marketing, contracts, etc. There are several resources I often find myself posting frequently in there and other forums, so I thought I'd share them here to reach a wider audience.
Fuck You Pay Me
The title of this presentation may be a little vulgar and it's obviously NSFW in case you couldn't figure that out from the title. It's just the audio though, so if you have headphones you are fine. The content is very much worth watching. It talks about contract negotiation and getting paid and has some very good advice on how to manage those types of things. Big Takeaway - A good lawyer makes you money!
Hello I write high-quality LabVIEW Code
My friend Chuck Blakeman says the last words of a dying marketing department are "Me too!" I'm sure you write great high-quality LabVIEW code and I'm also sure that every LabVIEW developer out there makes the same claim. The client who is looking to hire a LabVIEW developer hears that phrase all the time. How are they supposed to know which one to hire? You need to have a differentiator, a reason they should hire you instead of everyone else, and writing high-quality code isn't it. This article explains why you should continue to do high-quality work and find a better differentiator.
Erik Dietrich
Explaining why your process is important
In line with the above article, I often hear some LabVIEW developers say things like "You should hire us because we write SOLID code or we do <insert some agile process or framework, like Scrum, SaFE, TDD, or CI/CD>" That's great! I understand what that means and so do many software developers, but do your clients? If they already understand why your way is the best way to do software development, why aren't they doing it themselves? why did they call you? They probably don't have a clue what you are talking about or why they should care. Doing good work is obviously important to you, but why should it be important to the client? Stop assuming that they already know the benefits. You've got to explain them in terms the client can understand. JB Rainsberger gives a perfect example of how to do that here:
