Core engineering principles
Each day at work, I make tons and tons of small and big decisions about code, team, projects, and so on. It’s incredible how many of them are based on about a dozen core principles.
I settled down on them over a long time and a lot of (painful) experiences. And I continue to use them repeatedly in different companies, teams, and projects.
I found that it’s gratifying to work with people who share most of these principles. This is especially true when the times are tough. It’s much easier to persevere when people around you share your values (instead of fighting you each step of the way).
Goal
The goal of software engineering is the delivery — of solutions, products, and ultimately value to customers. That’s how individuals, teams, and managers should be measured up.
I saw so many times when a manager claims to hire the best people (based on their shiny resume, experience in BigCo, jive personality, and ability to navigate interviews smoothly). And after managers just sit back and wait until the magic happens.
Hands down, great people are the essential part of the delivery. However, just getting people in the door is not enough. First, all the markers described above (like navigating interviews smoothly) could be wrong. Second, it takes a substantial amount of time to see a person deliver and establish trust before you can truly call them great.
Also, Your engineering process/environment matter as well. You can have great people and force them to jump through so many hoops that they won’t have time and energy to do anything substantial.
And finally, way too often, managers start confusing intermediate steps (hiring people, keeping people happy, and so on) with the final goal (delivery). Just to be crystal clear, all of the intermediate steps are necessary and good, but they are not sufficient.
The goal is delivery, and everything else should be aligned and evaluated in its context.
People
Trust
Trust trumps performance. Simon Sinek has a great video about it. Having to second-guess somebody (even a genius) all the time sucks a tremendous amount of time and energy. As a result, it’s paramount for everybody to say what they mean, mean what they said, and do what they say. This is the only way to establish trust.
Also, people (even with a limited amount of info) tend to figure things out. So it’s better to tell people the bitter truth than let them figure it out on their own and be pissed at you. It’s a bitter pill to swallow, but it also helps you to build trust.
It takes time to establish trust. However, if a trust is broken (especially repeatedly), there is no way to go back.
Protect your best people, get rid of problematic
The best people do care a lot (sometimes even too much) and work hard. And as a result, these people accumulate more and more responsibilities and became go-to people on all kinds of problems. Such hardworking people are great for the company. However, you need to protect them (quite often from themselves). Even the best people need to have time off, and they need to have clear priorities, time to process things, etc. Putting more and more responsibilities (and pressure) on an overburdened person’s plate is a recipe for burnout.
Each person is different. One person can handle more than another. However, everybody has a breaking point. Pushing your best people even close to the breaking point is not smart.
And on the flip side of this coin. You need to clean up the house if people don’t deliver. Anybody deserves a second chance and tons of accommodation for personal circumstances. However, keeping low-performing people is unfair for the rest of the team. It can feel like compassion for a low performer, but the rest of the team pays for it in spades.
Overcommunicate context
Overcommunicate (so people know what, why, how and when needs to be done). Talk to people, write documentation, share tools, discuss better approaches.
You have to explain why you do something and why you don’t do something and the inputs which come into your thinking. Saying something without putting a context is almost useless. People don’t live in your head, they may not be a part of all previous meetings, and they don’t have your experience.
Work should be enjoyable.
Work should be enjoyable. An important distinction, not “fun” but “enjoyable.” Fun is short-lived and fades away fast. An enjoyable environment can sustain you through rough patches.
I think many organizations concentrate on fun (let’s add a ping-pong table and have a Friday beer bash) and underinvest into the “enjoyable” part. The simple litmus test is: How do you feel about coming on Monday to work? If the work is enjoyable, you will be looking forward to it (even if the times are tough). If the work has fun parts but is not enjoyable, you will start dreading Mondays.
Process
Clean water view
The messier and more chaotic things are, the harder it is to distinguish between good and bad decisions.
Let’s say you work in a clean and straightforward environment, and somebody decided to bypass many checks and deploy to production. Your reasonable reaction would be, “Are you damn out of your mind”? BTW. Most likely, the person would not even have permission to do so.
However, if you work in a messy environment, people will say, “Oh… that thing was broken. We were waiting on another team for a month, and it is not getting fixed. And they are blocked by something else. We can’t wait any longer because of some critical priority. So we were pushed to do so,”. And your reply most likely will be, “I don’t like that. Are you sure you want to do it? Did you run it by somebody”?
Notice that your opinion has already moved from “WTF” to “Hm.. Maybe. Seek authoritative approval for the newly created mess”.
The problem with a chaotic environment is that everything becomes dirty fast (even things you wanted to keep clean).
The muddy waters are great for playing political games, dividing people and pitting them against each other, making people feel guilty, and using it to squeeze out extra work. However, such an environment makes it very hard for people and teams to flourish. Moreover, since nobody can easily distinguish between a plain bad decision and necessary evil, everything becomes unbelievably subjective and political (in the worst meaning of this word).
Iterative/incremental development works. Long-term planning doesn’t.
“No plan survives contact with the enemy” — paraphrased Helmuth von Moltke the Elder
I strongly believe in short-term planning (figure out what you are doing today and this week). I like visibility into what’s coming (the next several months), and I hate long-term planning (more than a quarter). The long planning always goes out the window literally a day after it is finished.
I am very skeptical of attempts to estimate long-term projects beyond T-short scope sizing. The amount of uncertainties (changes of scope, changes of priorities, people leaving, getting sick, taking vacations, some external dependencies, unknown unknowns, etc.) could not be compensated by adding any kind of buffer.
The agile principles were conceived more than 20 years ago and won hands down. However, it’s still widespread for top management to demand precise pinning of deliverables for an extended timeframe. This is causing all these problems with a need to plan/replan/to come up with contingencies and create huge estimates.
The standard counterargument (to being agile) is that the business needs to know when things will be delivered. The most effective things I saw being implemented to counteract this argument — defining high-level directions for a year, mid-level initiatives for a quarter, and features for the next month or two. This eliminates the need to estimate some massive projects and pinning them down to some months in the distant future. On top of that, most of the time, sales are way happier if engineering can genuinely have a constant stream of deliverables (vs. being stuck in planning and failing to deliver).
And getting back to the earth to incremental and iterative development. Break down everything into small chewable pieces. Get each of these pieces fully done (implemented, tested, documented, released, and on). Rinse and repeat.
No big bang projects, no long science experiments which go nowhere, no big rewrites.
Crawl, walk, run and keep it simple
This one has a lot of overlap with the iterative development mantra.
You don’t start training your infant for marathons when they are six months old. First, they need to learn to crawl, walk and run and only after that can you decide whether advanced training is what they are interested in and what you want to do.
Too often, people who got burned by some previous bad experience and trying to squeeze everything into a product way too early. This creates a very unnatural state when the barely walking product is forced to deal with that marathon requirements.
Another angle of the same issue is simplicity. The problem with trying to add too many requirements, use cases, and complicated design early is that it drastically increases complexity. And complexity is always very costly. You want to keep things simple as long as you can. There will be natural things (like the increase of a customer base) that will push the product to become more mature and complex.
High-quality + Constraint gardening
Software is way more like gardening than building.
You have to work on your quality constantly: fix bugs, improve tests, clean code, etc. To bear fruits, your product should always be in good shape, and you shouldn’t have to stumble over dozens of issues, untangle messy code and fight build systems just to get some trivial thing done.
You have to fight weeds (small nagging problems) when they are small enough. Wait long enough, and they will overtake your garden.
There could be only one top priority
“If everything is important, then nothing is.” ― Patrick Lencioni
You may have several critical items for a team and several swim lanes. However, each person should have a crystal clear priority list. There should be no “here is a critical task, first priority, immediate and urgent task and go figure them out”.
This is very common in mid-size companies. Priorities are coming from all kinds of directions and there is no choking point where all of them are triaged and prioritized. And when something falls through (and something will), there is increasing pressure to figure out why this specific thing (regardless of everything else) wasn’t a top priority.
I believe even for a team, it’s useful to have some level of prioritization to indicate critical projects/items vs. less critical. This enables the team and individuals to quickly adjust and continue pushing forward with what is most important.
Devil is always in the details.
It’s always easy and fun to talk about something from a 30k feet view. You don’t see any cracks in the story. Everything is smooth and predictable. As soon as you dive into details, everything changes and things that were glossed over have to be resolved. I am talking about edge cases, compatibility with some old functionality, unspoken requirements, limitations, and a gazillion other things.
BTW. This is applicable way beyond technologies. You look at the team from outside, and it works smoothly and nicely. However, you come closer and may find that it takes an immense amount of coordination for it to run smoothly, that there is unhealthy tension in the team, somebody constantly working over the weekends, etc.
You should never shy away from details. Details make things look complicated, but that’s the only way to understand what is truly going on.
This is the reason why managing (purely) by metrics doesn’t work. Metrics abstract away details. They could be good to take a temperature, but they are bad for setting the diagnosis.
Who is making the last call?
The question of who is making decisions is unbelievably complicated. Egos, jobs titles, opinions are involved. So, people feel very passionate about it.
I firmly believe that democracy is good for a country but bad for the product.
It’s great to facilitate advice, gather different points of view, and so on. However, one or a maximum of a couple of people should be making the final decisions.
Great companies and excellent products are started and built by few visionaries (vs. big committees).
Important note. It doesn’t mean that one person should make all decisions in the organization. It means that each area should have an owner, and this owner should have the final say about his area of ownership. This owner should have the freedom to make a decision and bear responsibility for these decisions.
And for such owner’s benefits. Sometimes you have to make hard decisions. Not making a decision is a decision on its own. If you don’t decide, it pushes this decision-making in a hidden form in random directions. And as a result, somebody (most likely a less experienced and less informed person) will decide for you.
Summary
Obviously, this list doesn’t cover all possible situations. However, as I wrote at the beginning, it’s amazing how many day-to-day decisions can easily be traced back to some of these principles.
I would recommend to everybody think through what are their principles. You don’t have to write them down, but crystalizing them makes it easy to make consistent (and hopefully) good decisions.
P.S. If you enjoyed this article, please follow me on Medium or subscribe via email.
