Are you a hardware engineer or a software engineer?
In my first job out of college, I did both. As a freshly minted Electrical Engineering graduate, I was thrilled to begin my first full-time job as an engineer at a small company where I got to do both hardware and software design.
You would think, that after 4 years of college (Ok, 4 1/2… plus a couple summers…), with heavy emphasis on the hardware side of things, that I would be better equipped to perform the duties of a hardware engineer than software. Especially since I had only a single semester course that covered the type of software I was doing at this job.
You would be wrong. Believe me, I was surprised as well.
It had nothing to do with the coursework in college.
What I discovered rather quickly was that hardware engineering requires a fully thought out, completely developed, and perfectly designed product before it goes to production. Once you send out the design for printing of the circuit boards, you are committed. Any mistakes you find after that point are quite costly to fix.
On the other hand, software engineering allows for a much more iterative approach. You write it, compile it, load it, and test it. Even if you go to production and later find a bug in the code, rolling out a fix is far less involved and costly than a hardware mistake.
I make a lot of mistakes.
Or, perhaps more accurately, I prefer the iterative approach to development of ideas. I like to start, develop a small bit at a time, test it, fix it as needed, then move on to the next bit. Sometimes in the process of doing this, I discover that a path I intended to follow is not going to work out. Sometimes changing course is a simple matter of changing from that point. Other times it means backtracking and going from there.
This happens frequently when writing this blog. I typically start with the title, thinking I am going to write about a particular thought. But, as the words come onto the screen, I discover it is heading a different direction. Rather than fight it, I simply go back and change the title to reflect the new endpoint.
I also follow the iterative approach when writing material in the act, and content for keynote presentations. I start with a particular idea in mind, create bits and pieces, put it together, test it, see how it works, and adjust from there.
I take a software engineering approach.
Other people I know prefer to have everything mapped out ahead of time. They plot and plan, design to a specific goal or purpose, with a concrete end product in mind. They do not vary from that objective. They thrive on making it all perfect before launch.
They are hardware engineers in their approach.
Note: This is not to say that all software engineering happens as an iterative process and that hardware cannot use this methodology. It is simply a convenient way to describe it.
Which one are you? Do you prefer to have everything well organized, lined up, and not deviate from the expectations? Or, do you like to dive in, get started, and adjust as you go along?
Both styles can work. But, it does help to understand your preferences. If you are in a job where the boss or organization as a whole is heavily biased toward the hardware engineering approach, and you are more of the software engineer, you are going to have challenges. Likewise in the reverse.
Knowing your approach and that of others around you is a good first step in being able to work better together.
Having a mix can be a good thing. In the computer world, hardware without software to make it do something is useless. Software without hardware to run it on is also useless.
Know your style and that of those around you. Work together to make something really cool.