Personally the way I examine dissatisfaction with a project is by comparing my (mostly subconscious) expectations with reality, then asking why the major gaps exist. These gaps could sometimes be equivalent to the values mentioned in the article (e.g. I was expecting to learn this cool new technology but we're using the same old thing), but many other things could bubble up. E.g. expectation to spend all day developing new features vs. reality of hunting down bugs, expectation of everyone agreeing with my opinions vs. reality of some disagreements, etc. Many times it's surprisingly easy to match my expectations with reality once the gap is explicit. I've found that the feeling of disillusionment described is usually the result of my subconscious finding it progressively harder to ignore the gap between expectations and reality.
I think this is a valuable thing for a team to think about and understand. However, I don't agree that if someone's ranking of these values differs from others on the team that means that someone should leave.
As I see it, finding ways to accommodate the different goals, outlooks, and personalities that make up the team is one of the team leader's responsibilities. After all, there's not really much need for leadership if everyone is the same.
I work on a team with a portfolio of ~30 separate features and 5 people. I’ve almost never been in conflicts with my teammates’ values or aesthetic sensibilities, since we can almost never afford to have two people working on the same thing. If I’m working on someone else’s code it’s usually because they’ve left, so I’m free to change it to my liking. When we do surge several people to a project, there’s still one owner who calls the tune on design, style, etc. so just not much debate about it. It’s their house; the extra contributors are just passing through.
We always do code review, so no one goes too far off the reservation, but you accept diffs that are acceptable in their own context; values disagreements are nonblocking.
Indeed. I also really like that this hierarchy is... not a hierarchy. I.e., there's no universal "correct" ordering of what/how/why.
Lots of people emphasize the "what"/"why" when talking about software engineering ethics, and lament that everyone only ever talks about the "how". I think that view kinds of misses the point. The three questions are rarely completely separate. Plus, for most engineering projects most folks will work on throughout their career, the "what" and "why" are extremely straight-forward and at least relatively uncontroversial. The "how" (good security, good uptime, etc.) is by far the most important question.
> However, I don't agree that if someone's ranking of these values differs from others on the team that means that someone should leave.
The use of the word “agree” suggests that the article says the thing you say you don't agree with but it doesn't.
The importance (to be fair, absolute importance is probably more important than ranking here) of the questions is important to ubderstabing how much you can or cannot accept divergence in the subject matter of each question between your preference and that of (or imposed on, for those where the decision comes from outside) the team.
And the same works in reverse for the team’s perceived importance of each question and their ability to accommodate/tolerate divergence from you.
So understanding the ranking, yours and the teams, is important to understanding fit, but fit isn't driven by alignment of the rankings (in fact, to the extent that there is disagreement in preferences, it is ideal that your importance order is inverted from the teams—that you are flexible where the team is inflexible, and vice versa.)
In the worst case scenario, a bad design or implementation can be the equivalent of multiplying all effort by zero.
- It can cause you to be unable to demo a product to a customer, or offer them the product as a trial period, because the product simply doesn't work or is unusable.
- A bad implementation can make you waste all your funding in something you cannot monetize and leaving you without an exit strategy.
- A bad implementation can violate regulations and be effectively illegal.
- A bad implementation can make you lose clients and affect your company reputation, sometimes permanently. Even if you hire an army of customer support representatives to contain frustration, or offer refunds, gifts and discounts, the bleeding won't stop until you fix the implementation.
- A bad implementation can make it necessary to hire an army of engineers to implement a simple change, because all your engineers spend 99% of their time trying to keep the Jenga tower of spaghetti code they can't refactor running. They cannot refactor it because you told them that "how" is not important.
- A bad implementation and bad practices can frustrate your engineers and cause them to actually leave their job.
So, implementation is not only some abstract nerd problem about spaces vs tabs, it can be an HR problem, a financial problem, a reputation problem, a legal problem, etc.
That's not how I read the article. The author didn't say that "how you build it" was at the bottom of the hierarchy or anything like that. They presented an unordered list of values and asked the reader to rank them.
It sounds like "how you build it" is very important to you, which (as I read the article, and in my own opinion) is a perfectly acceptable value. That's the point of value systems, you don't have to agree about them but if there is a conflict between your values and values of your organisation, be aware of it because otherwise it will eventually cause conflicts.
What's particularly pertinent to software engineering, is in `How something is built` often appears to override `Why something is built` and `What is built`.
Even, not infrequently, in safety critical environments, if some case studies are to be believed.
The same is true for bestseller business books, all concerned with the How and not the Why, when it's the Why that moves the needle.
And you see this blind adherence to "process over purpose" everywhere in software teams, with things like Agile, Scrum, Kubernetes, microservices etc. where none of this actually matters to the user.
Henry Ford's autobiography is one of the few that focuses on the Why, and it is ironic that business schools tend to talk about him in terms of the How ("he revolutionized the production process"). Henry Ford's secret to everything was not his production process, but the basis on which he conducted business and approached industry.
The thing is, if you get the Why right, then the How automatically follows: do things in the most direct way possible with a minimum of red tape.
Maybe it’s just me, but I don’t see Scrum prioritising the “how” over the “why”. It advertises itself as a “how” (and a very flexible, minimal one at that), in order to get out of your way to focus on the “what” and “why”. Because it completely avoids speaking to the “why”, adoptees are free to use it in whatever relation to “why” they see fit. To me it’s clear the “why” comes first.
I do agree that we find it very easy to talk about “how” ahead of “why”. Especially those of us whose job it is to make the “what”.
I’d happily dig into whether a “how” does indeed fall out of a “why”. My knee-jerk reaction was “probably not”, but on A bit of reflection you may be right in more cases than not. The “why” helps frame customer/user expectation, which in turn suggests tolerances for usability, functionality and quality, which in turn should suggest a “how”.
I think problems tend to arise from the following...
- The clamour over "HOW" something is built, will most certainly shape 'WHAT' is built
- After "WHAT" is delivered, it's existence is then found to conflict with "WHY" in someway (missing features, design made to fit the tooling, people implementing ideas they feel is right for the user, etc)
Two years later, you're re-writing vast portions of the originally defined "WHAT", based on a renewed declaration of "WHY".
By this time, the engineering team will have new and innovative ideas related to "HOW", even though the "WHY" never changed...
But the "WHY" has been forced to move on a great deal, because the "WHAT" made the original declaration of "WHY" look misguided. Although it wasn't.
Tbh, the "HOW" is extremely hard, which is why this is such a common state of affairs...
Not sure if that makes any sense, but that was fun to write!
"When you build it" is missing from this list. In my experience, the "when" often tends to take precedence over the "how" and occasionally over the "what" as well.
For me, as important as any of these factors is “who are you building it with”. Great teammates and a great manager can go a really long way towards job satisfaction.
A great team is great, but not if "we're on a road to nowhere".
And even a good (or possibly mediocre) team with a great direction, a noble goal, must be better than a great team with a dead-end direction, because people will sacrifice and put up with all kinds of politics if the cause is worthy, if there are lives on the line.
That’s a fair point. I guess my point is that even with direction, if I’m not surrounded by a great team, I’m probably not going to be enjoying my job. Both of these things for me are more important than the specific problem I’m solving or whatever tech I’m using to solve it.
"How you build it: How much do you value the application of specific technologies, engineering practices or processes when building software?"
And the inverse: How much do you value doing things in the most direct way possible with a minimum of specific technologies, dependencies, frameworks, practices or processes (i.e. red tape)?
What is the fundamental reason why a software engineer is expected to care about what feature he's building, whereas a plumber isn't? Is it due to how differently the two professions are viewed by society, or is there some intrinsic difference between the two professions?
(Just don't tell me it's because software engineers are "creative" whereas plumbers are mindless drones; when faced with a problem, a plumber has to propose solutions and evaluate trade-offs, same as an engineer)
A plumbers' work basically always improves society.
A software developers' work sometimes improves society, sometimes harms society, and sometimes is a meaningless waste of time. Society encourages developers to use their judgement and ideally improve society.
At it's core, I think caring about the feature you're making is a judgement on whether you think the feature will improve the world or not.
You can probably list all the reasons for plumbing to exist. There’s a few, but they’re largely well documented and understood. Cleanliness, sustenance and comfort seem to be the main three. Of course there’s detail, nuance and special cases, but all within the scope of those three.
Software can help in more situations and hence gets prompted by a wider range of “why”. I doubt you could list all the reasons for software to exist before the heat death of the universe overtook you.
Could you talk more about it? The site is vague and low info density. It comes off like The Secret or other kinds of weird neurolinguistic programming ideas crossed with a multilevel marketing scheme.
Here's a TED talk by Sinek on the concept (it turned into a book, Start With Why, and now a set of courses, etc.)
It's a simple but powerful concept - one of those you should revisit on a regular basis to test your beliefs and the difference you want to make at work, in your society, etc.
