Principles of the Software Engineer

The first principle of the Engineer. Devotion to apprenticeship, learning, mentoring, and application. Complete command over the medium. The Engineer’s journey is one of mastery. A journey of growth.

Mastery requires years and years of dedicated focus and disciplined diligence. It requires apprenticeships to learn from experienced mentors. It requires reading and learning. Most importantly, it requires tremendous amounts of action.

Certain forms of wisdom can only be learned through action. Books and tutorials can only take the Engineer so far. Take Ben Fraklin for example. When yearned to be a writer. He would throw himself into literature and essays. He would read an interesting book or article many times over. Enough to where he could copy portions of the text onto paper without referencing the original. Then we would continue to rewrite those passages as if another author had wrote them. Experimenting with different forms and feelings to bring a character to life through the text. Ben Franklin understood the importance of doing and its impact on our own minds.

Mastery implies a certain focalization. An unwavering gaze towards a field. But, one cannot be a master of everything. In sufficiently complex domains, multiple experts must come together to synthesize their knowledge and combine their skills to create great works.

The Engineer must be well-adept at explaining over-arching principles down to minute details. Not because they are technical geniuses, but because they have taken the responsibility to synthesize and understand the learnings of their teams into a concise, approachable form. They can appropriately talk with relateable abstractions and swiftly move into details if needed. They are prepared rather than relying on raw talent.

Collaboration is not about getting others to do work. But rather, finding new ideas, generating strategies, and solving hard problems. Collaboration is syntony, being responsive to and in harmony with the environment. Immersion into the environment and being one with it. That environment being the problem space and co-workers.

As Atul Gawande says in Better, “we must recognize our ability to act skillfully will come in conflict with acting rightly.” The Engineer upolds their moral values and only acts honestly. Building systems, solving problems, or fixing things should never compromise the fabric of human nature. Acting with integrity may be the most important principle here. Software engineers have they unprecendented ability to immediately affect the thoughts of millions, or even billions, of people with software they create. Our duty demands us to do what is we believe is morally right and nothing else.

The Engineer must have the courage to say “No” in the face of pressure and demands. Not to the point that paranoia and fear prevent conquering seemingly insurmountable obstacles. But if there are clear signs of abuse or mishap, then the Engineer must step in to stop the system.

Consistency, the fourth principle of the Engineer. Consistency as a person and consistency in the systems they build (aside: our values tend to be reflected in systems we build as they drive our motives each day). As a person, The Engineer is consistent. Trust is built from consistency. Every person met is treated with the same respect. The Engineer shows up on time. The Engineer contributes. The Engineer follows through on commitments and only commits to what he/she can follow through on. Consistency requires a high degree of self-awareness and discipline. It starts within.

Consistency in the systems helps build trust with them. Same as with a person. If a system is consistent, people can build an expectation of how it works. Interacting with it, there are no surprises. Ask the system a question, the same answer comes out. Consistency is imporant because it allows the mind to turn that system into a building block. Since the relationship between input and output is relatively stable, that system can be incorporated as a part into further systems. For example, a bad case of consistency is the Atlassian suite for developers. Jira ticket and Stash/BitBucket pull requests use different markdowns for formatting. It creates an uncomfortable cognitive burden and disruption when using those two systems because they are inconsistent on their formatting.

The Engineer strives for consistency at the cost of personal preference. Stylistic choices match whatever code base they’re working in. Much like a copywriter will match the brand voice of an organization they are working with. The Engineer refactors entirely. Not half-refactor, where the old style or patterns are left to further rot. The Engineer makes a whole-hearted effort to improve the codebase and product by attacking inconsistency.