A recent episode of the EEVBlog mentioned some new engineering graduate's frustration with real world engineering, and asked about the reality of full design gamut jobs out there. As someone who has such an engineering job at a relatively young age (still in the 2's) I thought I'd share the pros and cons to working in a small team on projects, sometimes as the sole engineer.
Design Freedom
Perhaps the biggest pro to such a position is what engineers first think of, design freedom. There is never the problem of too many chefs, or of having every design decision dictated down to you. At the end of the day I'm still a design monkey (implementing another person's idea), but being involved in the design meetings does allow me to voice my opinion about creative ideas and potential product features. When it comes to design freedom, I'd say there is nothing like doing your own thing (such as for an Open Source project), but even when designing for someone else, having so much freedom goes a long way to fulfilling the creative bug that most of us engineers have.
Bubble World
The drawback to this design freedom is the lack of fellow engineers to bounce ideas off of, discuss design philosophies with, share experience, etc. This may not be the case if you have a full gamut design position within a larger engineering company, but it seems more likely that such positions will be in small companies. Smaller companies also usually offer less in the way tools, equipment and software. This probably isn't as big a deal if you are further along in you career, but in your younger years, there may be some missed opportunities soaking up the knowledge other engineers have garnered over years of experience. The hands on experience from carrying out and testing designs, however, certainly provides for some great experience in its own right.
Paper Work
The paperwork associated with professional engineering doesn't disappear. Bills of materials, manuals, assembly drawings, final test procedures... all still need to get done. In fact, instead of escaping this type of work, there is probably an even larger burden of it that falls on the shoulders of the designer in a one man gig.
Knower of All, Master of None
Coming up with a design architecture, going through the component research, designing the analog and digital circuitry, writing the software, testing the hardware and software, etc., means it's tough if not impossible to get bored from tedious work. It's definitely an ideal position if you like a change of scenery every once in a while. This also means there is no escaping or passing off any portion of the design, even things you may not find very exciting (e.g. reading through some European Union enforced safety standard). A drawback to this is that it is more difficult to specialize in one aspect of design. When I'm working on software, for example, I find myself buying and reading software books, taking online software classes to further my knowledge, etc. When I'm working on the hardware portion of the design, I'll probably be spending more free time studying the hardware side of things. The fact is, there are probably many more jobs out there for larger corporations looking for specialized skills. If I had to find a new job, I might be competing for a firmware position with firmware gurus who spend all their time (or the majority of it) studying the software side of things, or competing for a hardware position with people who ignore software and devote their energy to becoming hardware experts. I personally tend to think that specialization is over-rated. Technologies can change so quickly that the ability to adapt and learn and utilize new technologies is more valuable than just mastering one specific skill and staying within that comfort zone, which is why this doesn't worry me much. Also, many times experience in multiple disciplines can improve your skills across those disciplines. Still, in addition to mastering the fundamentals, I think it is probably a good idea to try and specialize at least to a small degree in one general area. Most people have a preference or a particular stage of the design flow that they may find more enjoyable or interesting, and so this usually natural occurs anyway. But depending on your point of view in the specialization versus generalization debate, this is something to consider before applying for a one man gig type job.
Responsibility
Releasing a product to the world can be very rewarding. It can also be somewhat stressful. If there are any issues that sneaked through testing and start popping up in the field, there is no 'shared responsibility'. If you are the type of person who stresses easily, or who does not like having a lot of responsibility, such a position is probably not for you. I find the best way to deal with this is through extremely thorough testing. I try to switch my brain into a completely different mode in the test phase, acting as if I have no idea who the designer is, and that I don't trust him. He must have made some mistakes, and they need to be found. Slower releases, with trial runs at a customer's location with whom you have a good relationship with can be helpful here. It is also necessary to be assertive if being pushed to release the product before it is completely tested. It is better (for your reputation and the companies) to release a fully tested and verified product late than to release a faulty product early.
No comments:
Post a Comment