There are clear ideas, mannerisms and principles that have been stored in my head for the longest time. These are principles that relate to my craft - software engineering. At the time of writing this, I am making a slow transition from being an individual contributor to leading a team, and I think it is more important than ever for me to have a solid set of values and world-views to work with.
I really like writing, and after recently reading some of Marcus Aurelius' works, I came to like his prose of aphorisms.
As with his work, you should also digest mine with some slight skepticism. In these works, I am not prescribing a complete rulebook. Rather I am simply speaking my mind and the culmination of almost 5 years of commercial experience in software engineering now.
In other words, I just felt like writing this.
Stupidity is dangerous, but those who are also ignorant of this become lethal. This statement is terse and jagged as this holds relevancy outside the domain of engineering, so please measure this rationally. It is the responsibility of the system to defend itself from such known actions, and the responsibility of the team to architect the system in this way. Even if one were to release a chimp into the codebase, one should not expect an outage. Subsequently, and favourably, architecting for such unsophisticated behaviour causes the emergence of simplicity akin to Occam's Razor.
Code is merely a language, and a computer is simply the recipient of a message. The prose, syntax, and choice of language for our message is only enhancing our convenience of changing it, and experimenting with new ways of coercing the behaviour of the computer. The difference between code and any other language is that it's sophistication demands a particular and precise, coherent understanding between all messengers.
If you were to quantify your salary to attempt a comparison to your inferred "output", you are destined to experience a dread that will drain your energy and your soul, leaving you a sycophantic husk that will forever be teetering upon the edge of art and insanity, like an impoverished beggar. Imposterisms form determinations that will lead you to a defined edge of a court, and are no doubt a fantastic survival tool. But those who acquire lucidly genuine dedication have solved this, and now aim for a metaphysical plane that extends itself from survival. An example of this is simply the pursuit of knowledge beyond their own, or that which can lay the concrete for the next step of the organisation.
Behind the ivory plaque of a company structure exists an organism. This organism is not unlike our own human cells, it contains organelles, obeys certain processes, and when observed at a macro scale, exhibits emergent behaviours and cultures which determine the tangential destiny of the organism.
That which is also spoken by Marcus Aurelius is the statement which describes that of a limb being separated from the body. That is, if any one function, person, or process is not fully integrated with the organism, it's cause and circulatory system (flux of capital), then it will eventually become gangrenous and must be skimmed like a cruft.
A mechanical system is predictable, predictability implies conductivity. A system without humans involved is one where the experience of the user flows freely, unabated by the meaningless quarrels between minds behind the curtains who are incapable of full cohesive understanding of the system or the problem it intends to solve. Any time that a human must be involved in the activity of the system is a failure of the organisation to address that particular combinatorial pattern of complexity (and important to note that this is not in any way a negative consequence).
In the worst of all scenarios (that of an incident), a mechanical system is favourable as it's behaviour can be eloquently diagnosed given adequate parameters being exposed to the investigators. This is akin to solving a polynomial with only a few known inputs - you may get multiple solutions, but usually this is enough to isolate the realm of possibility down to a domain which is palatable to human intuition.
What does it imply to have solved a problem?
To say that it is the formation of a solution is facile and an insult to that of humanity beyond the realm of engineering.
Any solution to any problem is an application of knowledge which is architected from the degree of understanding of the problem. This is the most foundational and formidable lesson that I have endured through my crafts.
Wit without cause is merely ponyshow. An engineer can know everything about kubernetes, but will merely flail their arms when explaining the benefits cluster auto-scaling to a board of senior non-technical leadership.
Consider instead a situation where every twitch of your finger over the keyboard is directed by a lucid understanding of the desires, complications, complaints, volition, direction, 'whats', 'whys' and 'hows' of both your seniority and that of the customer you serve. As if you were to write your software and architect your systems for your mother, father, brother or sister.
A trunk is the place in which all engineers solidify their creations into history and expose them to the org and the world. Before this, such as in a branch or pull request, it is merely an ephemeral confabulation intended to quantify an idea into a common language that beckons the dialectic of the tribe before assimilation.
The importance of this analogy of the tree is that of its cellulose. In general, a tree cannot change its colour, or the formation of its bark once it has manifested in its core. If this lumber is crook, then the tree may stunt, and fail to weather next summer's storm. The moral of this is that one should strive to ensure the cellulose that is produced and formed into the core is of its highest quality, as there is often not much room for pruning and coercing at any later date.
Re-work is the worst type of work. Personally, it is a signifier, a medal of dishonor awarded to one who either:
- Chose not to understand the problem
- Did not have all the information about a problem
- Did not have the correct information for a problem
- Chooses to engage in gross negligence
And the beneficiaries of this award are those around them who led this person to their defeat.
If any engineer at the helm of an incident marres their conscience with that of defeat or anguish, then the org is afflicted with the same condition.
If any engineer is of the belief that their work is an absurdity, then it must be that the org engages in the business of meaninglessness and charade.
If any engineer believes that they must be frugal in all efforts to deliver value, then this is indicative of a constriction of the organisation's limbs by that of a vapid whim. In some cases, this is cowardice of senior leadership.
If any engineer believes that haste over eclipsing omniscience of the problem is necessary for survival, then the customers of the organisation will receive haste and misdirection between every experience.
If any engineer feels as if their abrupt absence from work will cause an avalanche of problems, then it must be that the organisation or function is opaque about its fortitude, or has not been battle-tested.
Space is defined as the mental and temporal cavity that exists where an engineer does not have an urgent priority to attend do. This space gives realm for an engineer to sharpen their tools, and scratch itches that no one else thought they had.
Conversely, an engineer under constant urgency will fight through foliage with a faded axe and a blunt resolve. The force needed for such efforts is far greater, and a person can only cover so much ground as an atom.
Those who will see, will know. To know more is to act better to deliver better. To see more, the organisation needs more eyes and just as many ears.
If things are valuable, then they should be watched, and when starved of sight, managers should be wary of where they try to re-allocate that vision.
Information left unshared is not valuable information.
Constricting access to anything is a signifier of distrust in subordinates. Treating them as children will rob them of the opportunity to grow, and also for you or the organisation to capitalize on the magnificent products that this phase of growth in oneself produces.
If an organisation wishes to be prudent with ongoing costs, then it should provide access to transparent billing for all members to see. That is, of an organisation imagined as a tenanted abode, if the blinds on one's windows are finally undrawn, then it's occupants would be encouraged to finally mow the lawn.
Any engineer can complete a ticket, but only a few dare question them.
Never trust a single word given by a customer, whether this be product feedback or a support ticket.
Customers do not know what they want, it is the job of us and the organisation to discover this for them. Focus instead on user behaviour analytics and recorded usages of the product.
If not rooted in observation and precise questioning, customer support can resemble that of the blind leading the deaf. That is, there is a cascading effect when invalid assumptions are drawn from a facile interpretation of the customer's message, then ingested and summarized by a support agent without thorough internal dialectic or skepticism.
Again, most problems can be solved by simply understanding them better.
If anything is unknown, then test it in a secure environment where the business is at no risk from the anticipated failure.
If such environment does not exist, then you should consider making it - this here may be the true definition of software engineering as an occupational role.
If you are uncertain of any action you are taking, stop for a moment and ask yourself: why do I feel that? Not with a presumption of incompetence, but with a prospect of discovering an axiom that would prevent you from falling 3 steps back in the future.
It's better to start with something small than nothing at all, then delivering an outcome that no one had asked for.
Starting small means you have the least amount of assumptions encoded into the program, and can fine-tune as you receive feedback.
No project is ever actually completed. This is because a project is a continuous field rather than something discrete, like a ticket.
That said, although a project can never be finished, it can reach a state that is good enough.
You should claim any opportunity or idea that allows yourself or others to go from first token of code to customer hands faster.
This is based on the theory of constraints.
In general, as a Junior, I expect you to know your craft, and complete tickets.
As a mid-level, I expect you to excell at your craft, barely flinch at tickets, and contribute to the greater engineering team.
As a senior, I expect you to be capable of making business-wide impact without the need for tickets.
As any engineer, I expect you to be capable of open-mindedness, and being alert for the next opportunity to push your limits.
Some readings are good, but too much will cause you to hear echoes that may turn into hallucinations.
Ask those senior to you what recommendations they have for books. Pick only those that intrigue you by their blurb, and avoid fluff and grandiose lustre.
Those books that must invest in marketing, slogans, platitudes, buzz and cruft are those where the author is insecure about their idea for the likelihood that it has no real foundation in primary evidence. These books will use the art of misdirection to take you into an eddy that has no substantial moral at its eye.
Architect systems with the understanding of maintenance being conducted by the most lay of engineers in mind, then set your reference point lower than this.
To be clear, this is not a jab at the competency at others, it is simply a terse way to encourage the development of systems that are durable to changes.
Work on every ticket as if you will be coming back to it to fix something that someone was unhappy with.
- Make written note of everything
- Architect your solution for change
- Make the least assumptions and effort as necessary
Carelessness leads to the obvious. Ostentatious and obtuse dedication fosters an external representation that frames you as misdirected and underworked.
On your journeys in resolving problems, you may come across small pains or irks. Make it a responsibility of yours to improve, at most, one of these for every pull request you make. That is, so long as the solution is trivial.
Treat every tidbit of information like you are a goldfish. Create a ticket, write a note, track an action item, scribble a post-it. Whatever it is, make it systematic and build a corpus.
Instead of answering with no, provide an avenue for the other person to continue with. This could be something they could do, or a question they can answer.
Instead of showing a dead end with a blunt 'no', you show them a new path they can follow.
Work is defined as the time that is consumed in delivering solutions to problems. You should have a single place to track all upcoming work, and meticulously track all of the places in which work originates from. By knowing where it comes from, you will potentially find the root of a weed.
That said, you should also be ruthless on questioning the work proposed to you by both others and yourself. Never make 'yes' or 'no' your default answer to any new work, and instead lead it with a reasonable and measured inquiry.
Never just bring problems to your manager, bring solutions with them.
To better embody this, know that your manager does not have the role of solving your problems, instead, their role is to do whatever is necessary to facilitate the solutions you propose - that is, so long as they are sound.
When you are talking to a customer, and are in doubt of a response, consider something that they are capable of doing or answering, and something that will get you more information. Stalling the customer in this way is justified because it makes them feel like there is a solution to their problem, and that they are making progress towards it.
If you want to improve something, measure it.
If you feel like some process, a goal or something else is meaningless and makes no impact, first think of a way you can change it to have value, then if that proves fruitless, discard it.
Perfection is impossible when working with other people (or agents). Instead, aim for a magnificent, sopping patchwork. It's something that works rather than works correctly.
The center of this mudball is solid, but the sludged edges will surely become detached when thrown. In time, you can shape this as a ball of clay, but to add to it would imply soaking it in more mud.
To let the mud harden, you must expose it to the elements. Be wary. You will want to ensure that the final shape is how you would like it to be. The drier the mud has become, the harder it is to mould.
If you are doing something that happens often, and can be done better going forward, then change it.
Given your assumptions are valuable, if your resolve is reasonable, and the work is elaborate, then your likely course of action will be to continue doing it the way it was - and that's more than fine.
If it is easy to do, and makes a big impact, then make this your top priority.
If it is hard to do, but makes a large impact, consider this when there is space, or when times are desperate.
If it is easy to do and has low impact, then consider discarding this work.
If it is hard to do, and has low impact, then this work is irrelevant and should be discarded.
Everything you encounter as a software engineer should be treated as a hypothesis. You should know this subliminally and not take it to any extremity, as your posture towards that which is trivial will become pedantic and unreasonable.
We are lucky in the science of computers to be able to rely on discrete foundational facts that bring us so close to the truth that it is reasonable to rely on them as such blindly.
Take an incident for example. It would be reasonable to question whether or not a system was online at the time, but it would be unreasonable to question whether the computer was capable of correctly executing a line of code from the program.
LLMs do not contain any sentience. If anything, they are merely a series of people in cubicles with an input tray and an output slot. Any existing messages are passed in through the input slot, they are examined, then a response appended, then delivered to the output tray which leads to the next person.
Anything in the appended output that is not contained in the existing letter should be considered as volatile information (prone to hallucinations). Hence to improve the reliability of this output, you will need to present the LLM with as much information as possible that is concrete as a pre-amble to your query. This way, it has easy access to the information that it needs which is correct and relevant.
Take a debugging situation for example. First you may coerce the LLM to reproduce the error with some tool so that (in its own paradigm of working and thinking) it may collect and organize some critical information, then form a root cause hypothesis and test it. When it is confirmed, you may then use this deliverable as context for a new interaction to resolve the issue.
Consider any incident process like red alert on the Starship USS Enterprise. The incident coordinator is the captain - they do not necessarily perform any function, but will command others to do two types of things; uncover additional information for decision-making, and execute actions within their expertise.
During all red alert sequences, personnel are required to be at their stations and prepared for any orders that may follow. Personnel will also abandon any regular orders or duties such that they are free to accept these orders without hesitation or delay.
By disconnecting themselves from the process of searching for and resolving the issue, the incident coordinator can have the adequate space to hypothesize and consider possible courses of action.
The process of choosing a course of action is an important role. The incident coordinator should seek counsel on potential actions that may solve or mitigate the issue, and whether or not they will impact customers. The coordinator should prioritize anything that will get the customers back to a state of correctness, even if it is temporary.
Unmentioned in this analogy is the communication to the customer. During all stages of understanding and resolution, the customer should be informed. They need not know fine details, but merely enough to know that the smartest people have been assigned the task of resolving whatever is the root cause.
You do not serve your boss or your product manager. You serve the customer. Your senior leadership is merely just a source of truth to help you understand the customer better.
When dealing with third-party libraries, at some point you will reach the limits of its documentation (if any). In this particular case, you should resort to examining the source code.
Be sure to diligently verify that the correct branch or commit sha is selected for the version you are using.