|
> A variety of projects sounds like it could be engaging, but on the other hand, maybe I’ll get bored writing the same boilerplate over and over? I've worked in a couple machine integrator shops (kind of a mix of product and consultancy, basically building products that the OEM can't build themselves) over the past decade. There have been lots of 200-800 hour projects from lots of customers. My takeaway has been that every project that's valuable enough to contract someone to do has at least one really interesting problem to solve. Every project also has some boilerplate to make it work, I don't think anyone gets out of that. Even tenured research professors have to write grant proposals. > But I’m worried that being involved with shorter term projects means I won’t get the chance to gain _deep_ expertise in any one thing, which might hurt my future job prospects? Shorter term projects mean that you're gaining adequate expertise to be productive in dozens of things. If asked "We're using the X stack to build a product that does foo, are you capable of working here and helping us?", and you can say "I've used the X stack to build something that does bar, and I did a project that mostly automated foo using stack Y, I'm confident I could do it with stack X", you're clearly ready to hit the ground running. If you can say that you've never used stack X or done foo, but have learned V, W, Y, and Z, and have not done foo but have been successful with similar projects like bar, baz, and qux, well, HR drones and hiring managers aren't always the brightest bunch but they're often capable of a small leap of faith like that. You're in a much better position than someone who's only ever used stack W to build baz, and doesn't know anything else. Also, it's really hard to gain deep expertise with one thing if you're only building a small number of products. Early architectural decisions often mean that you're stuck with the first thing that worked, while on a ton of short projects you can figure out what does work and what doesn't. For example, as a controls engineer, I've had the opportunity to try at least a dozen ways of representing a machine operation or actuator. I've built systems that are inadequate and had to be extended with cludgy add-ons, that are too rigid and had to be forked into subtly different varieties, that are too flexible and bulky, and finally settled on a representation that really works well. It's kind of like being given the opportunity to do a complete rewrite of the software, except you're not writing quite the same software each time...highly risky at a product org, but at a consulting org you're basically expected to do that. |