Value Assignment: Senior Engineering Values
As a senior engineer, I should be designing implementations and writing code to the best of my ability. I should also be advocating for best practices as I understand them such that my team is able to achieve its best outcomes.
I’ve learned a lot, often by making or observing mistakes. Ideally, I’d like to use that knowledge to help others not make those same mistakes. Conversely, I’d like to learn from my fellow engineers what worked or did not work for them. I have tons of experience, but that experience is really hard to bottle and hand out to my team members. If only it was that simple! Instead, I have to share my experience by sharing the product of those experiences: my values!
What are values?
Values are beliefs that the senior engineer should hold to be guiding principles in how they approach their work. These values can range from technical to ethical.
Each of the values that I’ve picked up are a result of first hand experience. Some of these I can relate specific stories about. Others have sat in my mind for such a long time that I don’t remember their origin stories and just accept them as truth.
There is a danger to that. It is very important to periodically test your values to be sure that you aren’t holding onto one that is no longer valid or perhaps is not evolved enough.
Not all values are created equal. There are exceptions I’m willing to make to some of these given the right circumstances. There are some I would refuse to perform work or quit over.
My Values
I’m going to list out some of my values below to give an example of what I am considering a value.
Technical
- Do not repeat yourself.
- Less is more: If all things are equal, use the simpler solution.
- Functions should do one thing and one thing only.
- Readability trumps brevity: Avoid clever code.
- Maintainability trumps performance: Only trade off maintainability in cases where high performance is critical.
- Dependencies add complications. Whenever possible avoid or reduce them.
User Driven
- Value the user’s interest over the engineer’s interests
- Work within user expectations: Interfaces should be as consistent as possible.
- Humans should not be doing work that a computer is better suited for. (Calculations, keeping track of data, double inputs)
- Easy to use security measures are good security measures.
Outcome Driven
- Cognitive load is important and it should be respected and managed. Break problems down. (Both for other engineers and for your users)
- Second opinions are extremely valuable.
- Documentation is divine.
- Refactors are a good and necessary thing, don’t be afraid of them.
Ethical
- Do no harm.
- Don’t contribute to the spam problem.
- Be security minded: Evaluate each feature in terms of how it can be exploited.
- Users are placing trust in you: Protect their data. Keep their information in confidence.
- Stand up for fellow engineers when they are lacking a voice or are put in a bad position.
Values at work
Given my above values, let’s say I’m asked to create an interface that displays total mileage driven by a user in my system.
Immediately some of my values come in to play. I have to ask, is this private information? What do I need to do to ensure it stays private? How can this information be exploited?
How should the user see this information? Is it in km or miles? The difference between those is a simple calculation, but the system should be doing that for the convenience of the user. How are we storing that information? Preferably we should be using the metric system because it is easier to convert and do calculations with. (Given two solutions, imperial vs metric, the simpler of the two is metric.) If we know their preference we should use it. If we don’t we should default it to the likely standard and record if they change it.
The code should have clear separations of responsibilities. There should be code that retrieves this data. And another section of code that renders it. And a third that converts it, if necessary.
These are all things that immediately go through my head when asked to build this minor feature.
I should ask these questions when the feature is proposed. And I should be capable of expressing why these questions are relevant and important. If I do that, then others will see what I’m looking at and why. They will begin to understand my values and begin the process of integrating them into their own.
Values evolve
The values I have now are not the values I had even a few years ago. I’ve slowly added and refined them as I’ve been exposed to other engineers’ values. These values get tested as code gets put to use and updated. There is nothing that solidifies a value more for me than when it is successful in a real world environment.
One of the joys of working with engineers who are better than me (either in part or in whole), is the ability to be exposed to their values and see what has worked for them. I then get to assimilate it in to skill set like a Borg and it becomes a part of my values.
This assimilation has been the difference between feeling like a mediocre engineer and feeling like an excellent one.
