My Engineering Manifesto

The Engineering Manifesto. There are many like it, but this is mine; the one I strive to abide by regardless of where I am, for someone else’s company, or my own.

  1. As an engineer, my first and foremost obligation is to my employer and/or client (barring, of course, violations of state or federal law).
    • Many potential objections to this pertain to situations in which the client/employer’s agenda is immoral or, at best, morally ambiguous. The important corollary to this statement is that alignment with the company’s vision is critical, and misalignment is more than enough grounds to seek partnership elsewhere.
    • A weaker formulation of this statement (but still true, nonetheless), is that my own preferences and wants are secondary to fulfilling my duties.
  2. The software I create should account for all reasonable requirements, mentioned and unmentioned, balancing time to delivery, risk, performance, suitability, maintainability, cost, and more. During the assessment of an approach, approaches should be appraised for each of these qualities in order of most importance, which will often change depending on the nature of the assignment.
    • It is easy to fall into the trap of caring only about, say, performance, at the expense of other qualities. Having an intuition for what is important when is an important skill all engineers should develop.
    • In situations where a client/manager/lead/etc disagrees about prioritization, a reasonable effort should be made to communicate why something warrants additional time or consideration.
  3. My goal for every project is timely delivery of something which functions to specification, packaged in a way that is usable and maintainable as per the project requirements.
    • Engineering is especially prone to volatile timelines, occasionally due to changing product requirements, but more often than not, due to “missing a beat” due to underestimated complexity, espcially as projects get more difficult. Even if time estimation is hard, good estimates are something I should aspire to.
    • My credibility as an engineer and employee depends on my execution, as I am a critical component in a company’s executive arm.
  4. My value as an engineer is dependent on not just my technical ability, but also my ability to communicate and educate.
    • At no point should I expect others to blindly assume I am doing the right thing or on the right track.
    • My coworkers, managers, and clients have a right to know what I’m doing or trying, how long I expect it to take, and my rationale for taking the approach that I did.
    • Pursuing wanton endeavors without communication is both toxic, and dangerous, to team and company objectives (although there is a time and place for experimentation that I should strive to recognize also).
  5. My personal mistakes should be communicated and addressed transparently and without fear.
    • Failure to acknowledge fault stymies forward progress. How can a team collectively understand why a project deadline slipped without transparency? How can I improve as an engineer without being honest with myself?
    • Mutual transparency within an organization prevents costly, systemic error. I should not expect transparency from others, if I cannot offer my own.
  6. I am an engineer, but not a martyr, victim, or patient.
    • Extreme measures of self-imposed obligation, expectations, or rebukes compromise my well-being and effectiveness as a whole.
    • I should work hard, but keep in mind that working in an unsustainable manner is ultimately not in the company’s best interest.
  7. I should respect time.
    • My own time.
    • The time of my coworkers.
    • The time of the company.
  8. My respect of time applies equivalently to other resources such as money, materials, equipment, and more.
    • The engineer constantly labors against waste and entropy of all forms: dead code, wasted CPU cycles, excess usage of storage, and more.
  9. The standard I abide by applies equally to things seen and unseen.
    • Lines of code that I write are my responsibility, with or without a code review.
    • The time I spend in the absence of my manager is equally valuable.
    • Test cases I write that run silently, without pomp and circumstance are virtuous.