Cool verification you ask? Since when? Though most senior managers will be happy to tell you how much they value their verification team, it's likely that a majority of them have no idea what the team does. What they do know is that they have a sneaking suspicion the work done by the verification team could somehow be done by the design or software group. This is not universally true, but it happens enough to make verification one of the less appealing computer engineering related jobs to new grads. It also can make the job unappealing to those of us already practicing the profession. So what's a depressed, overworked, unappreciated verification engineer to do?
Yep, you heard it right... Look around... are you finding yourself wandering aimlessly through your day, sulking around the office because you know every meeting will be a waste of time, every minute of code writing will be followed by 10 minutes of compilation, or every bug found will be greeted with indignation by a designer, architect, or project manager who thinks the design team already fixed all the bugs with their personal block level testbench? What processes are keeping you and the rest of your team from being successful? Don't be afraid to stand up and make a change.
Ok, so now you've decided you're sick of spending hours the day after a release trying to figure out whether more tests are passing than with the previous build and how to get the damn thing to compile at the other two geographically remote project sites. It's easy to get stuck in a rut and accept the fact that things can't get any better. Every project team needs an instigator to stir things up and get them moving in the right direction. For that person to gain any respect they'd better be able to put their money where there mouth is, so to speak. Spend some time on the side and come up with a proposal and a working example of how your plan will make things better. While you're at it, try to remember that your problem has likely been faced before. Ask your computer science friends how they handle software releases. Ask the IT guy what's been done in other parts of your company to manage shared computing resources. Check out other sites such as www.verificationguild.com and www.deepchip.com. Network with other verification engineers and find out what they're doing to solve the inevitably similar problems they're having on their own projects.
Win Friends and Influence People with Results
It's a lot easier to effect change when you're producing superior results. Don't fall into the engineering trap of keeping your head down in your cubicle. Say hi to the project manager and his boss as often as possible. Track the progress of your verification effort through bug databases and functional coverage. Resist the temptation to use the information you've gathered for evil purposes such as evaluating other engineers and distributing bug bounties during the middle of a project. Keep the lines of communication open. If you're unlucky enough to be working on a cross-site team and the manager is not at your site, encourage travel, video conferencing, phone calls, instant messaging, or whatever else works for you to make sure you don't fall out of touch with the rest of the team.
Share What You've Learned
This is the part many engineers find most difficult (including myself). Don't keep all your good tips and tricks to yourself. The more people learn what you know the more opportunities you'll have to learn something new! This site is my attempt to share a bit of my verification knowledge with the rest of you, and create a permanent record of my thoughts for my own use. Feel free to share your comments.