| I was a software contractor in Seattle for 13+ years, pretty much all of this holds true for that area as well, and I assume most of the U.S. at least. > If you turn up and are rubbish, your contract will be terminated really quick. And if there are layoffs, contractors would (sometimes) already be well gone already. This is one piece of advice I haven't found to be the case. I have told the following lies as a contractor: "Sure, I know PHP", "Sure, I know Ruby", "Sure, I know Python". The reality is that most of the time you're working on the shit that no employees at the company want to do, so no one is paying the least attention to you. Yes, you have to deliver functioning code on time, but you can get away with tap-dancing for a while until you learn the stack you're working on. In 13 years, I was never fired, and usually got my next clients via positive referrals. The above explains why this statement IS true: > You are always seeing new companies, new tech, new tech stacks, and the job never gets boring That was the best thing about contracting: variety. Also the worst thing. I got about 3-6 months of experience on dozens of different technologies, but never mastered anything except the skill of learning skills quickly. But in my experience, if you only worked on things for which you were already hot shit, you wouldn't get that level of variety, and you probably wouldn't get enough contracts to sustain a business. People do specialize, but the tendency in contracting is always to be a generalist because you have more options. The two biggest skills in contracting are communication and faking confidence. They are paying you to deliver something, but really they're paying you to happily accept some of the stress they feel. If you practice saying "That shouldn't be hard, let me handle it" you are well on your way to being a success. |
I also had a brief contract to teach Excel where I stayed a chapter ahead of my students in class, and similarly got great feedback...
So much contract work has a really low bar.
But then on the other side of the difficulty, I also delivered a library to provide a reliable data transfer layer on top of GSM data for use between two ships in motion (just adding some retries and automated redial etc. the only hard-ish part was minimizing the time to catch up after a redial where you might be suddenly lagging 40+ seconds behind), one of which was tracking an unmanned submersible. That certainly involved taking in their stress - they were demoing the system for US Navy brass, and my part was what'd relay the demo data from the tracking ship to the workstation they'd show it on, and it was clear a large part of the pay was so there was someone to shift blame to if needed (thankfully everything went smoothly).
But that variety was fun. I much preferred the short contracts like that - didn't appreciate the stress of finding new ones which came with the short projects though.