Oh please, K-maps my ass.
I haven't had to do a K-map by hand in years, except for implementing a boothe encoder for a hardware multiplier I did for VLSI class. Generally though, K-maps have been superceded by coding state machines in either VHDL or Verilog (or even one of those drawing programs where you draw the state-machine and it translates it).
I'm a digital hardware engineer who specializes in small embedded systems. Translated that means I do stuff with microcontrollers and fpga's, though I do have a little VLSI experience and went through all the prerequisite EE analog circuitry courses, and I use all of that occasionally, particularly in a mixed signal system (front end is an analog sampling system followed by a DSP processing system connected in some way to either a host or just a data logger).
People that are JUST software engineers seem to do alot more "in-depth" programming than I do. Fancy structures, long algorithms, etc. Most of the projects I've done involve figuring out how to hook different components together, reading all the datasheets on everything making sure the schematic is sound and I'll have clean power rails going to everything or the transients caused by clock signals aren't going to corrupt my analog data, that kind of thing. While I'm doing all of this, in the back of my head I'm also thinking about how this system is going to boot, a good and simple way for an application programmer to get his program into the system and make it easy for him to use for testing purposes.
Once I've had the system built I think test all of the power and signals and make sure there are no manufacturing defects. By that time I'll have all of the VHDL written (either just for glue-logic or any hardware support I feel the system needs - sometimes a digital filter if it's deemed that doing that in software is too much of a burden, and in these small embedded systems it often is), tested both functionally and with timing verification, and I'll move on to writing any kind of support libraries that will make the application programmers' lives easier. For instance, in some systems there is some off-chip flash memory that I'll write either functions or macros (depending) for so that the programmers can just use them to access it to get any constans or coefficients or whatever they want to store in it (after the boot sector of course).
Basically, what I'm saying is that if you end up as a hardware engineer you'll do some coding anyway, the depth of which depends on the project, but you'll also have a deeper understanding of the hardware system than a software engineer generally does (at least ones that works on general PC architecture, console and game programmers are generally very well versed in the hardware, but the number of software people I've met that do general windows app development that don't know how a basic register works is astounding).
I like being a hardware engineer because you have the satisfaction of building up an entire system and seeing it implemented, whereas when I'm programming for someone else's development kit or just for windows stuff I feel far too abstracted away from stuff and just end up trying to figure out how all of the hardware is tied together anyway.
