Thou shalt write things down: Making engineering more scientific

At HDDG18, Gerrit Coetzee discusses project management and how to track testing and requirements in a sane way.

“If you didn’t write it down, it didn’t happen”

Supplyframe’s mission is to create more access to information about electronics design and manufacturing. As such, we do a meetup in San Francisco called, Hardware Developers Didactic Galactic. These events include talks by industry experts in hardware and software. The speakers are often building hardware for recreation or as part of their employment. The common thread is that they want to give a view “under the hood”.

At HDDG18 on January 26 2017, Gerrit Coetzee gave a talk based upon his experience as a project manager and product designer. Gerrit is also a writer for the popular tech blog Hackaday (which became part of the Supplyframe family 3+ years ago). Ironically, Gerrit points out the very distinct differences between a “hacker” and an “engineer”.

The interesting piece is Gerrit’s perspective as both an engineer and a manager. He takes a no-nonsense approach to documentation and recalls his own experience with managers so he can be an optimal one. For example, Gerrit’s definition of a manager is “a servant of the team” and “an enabler”. Mostly that the manager should be doing everything required to help the team, even if that thing is going out to buy pizza so work doesn’t need to stop on the project.

Specification and test plans were the largest piece of this presentation. These documents are dreaded by many engineers because they represent a quagmire of meetings and back-and-forth with different departments throughout the company. Gerrit maintains that having these documents stored and formatted properly are an asset to engineers, because clear documents (and ostensible agreement on them at some point) will result in fewer questions of “Why did we decide that 3 months ago?”

Ultimately, how much documentation you do is up to you, but Gerrit makes a strong case for “making engineering more scientific”. As a project manager, he is able to keep tasks on schedule and show his management what went right and wrong at the end of the project. Viewers and readers here will do well to follow the same advice.

Do you follow his advice? Let us know below!