
Engineering Principles and Values - edawerd
http://engineering.zenpayroll.com/our-engineering-values-and-principles/
======
tyre
Great stuff, looks like you've come a long way.

I'd caution against the term "over-engineering." It is a straw man[1] — no one
is pro-over-engineering — so it is only ever used to discourage long-term
thought. It's a good thing to try and avoid, but maybe pick something neutral
like "predicting the future."

Hacking, on the other hand, is sometimes advocated for (e.g. Facebook) and can
be good or bad depending on circumstances.

[1]: [http://seneca.systems/values#what-constitutes-a-
value](http://seneca.systems/values#what-constitutes-a-value)

~~~
akamaka
I have quite strong feelings on the subject of over-engineering.

I've had to argue against over-engineering many times in my career. I wasn't
about discouraging thinking. I was fighting against actually implementing
specific features that attempted to solve poorly-defined problems whose
details had not yet come into focus. Developing those features would
significantly impair other parts of the project.

For example, the problem might be "What if our database becomes overloaded one
day?" Choosing to implement, say, sharding, could lead to an over-engineered
system which gets in the way of solving the many different future performance
problems that could crop up.

I think it's quite reasonable to use the term "over-engineering" in this sort
of situation.

~~~
tyre
I definitely agree that over-engineering is a problem. My feedback was meant
to be about how to communicate that balance.

In your example, if you tell the other person that their database sharding is
over-engineering, they can say one of two things:

a) No it isn't. b) Yes it is and I think over-engineering is a good thing.

I have never heard someone say (b); if they thought it was over-engineering
then they wouldn't have advocated for it. The negative quality is part of the
definition.

What you're likely disagreeing on is how far in the future you're team should
be thinking or how much data is necessary to make a confident decision.

I don't think it was your intent to stop long-term thinking, but if someone
says "we shouldn't over-engineering things", I don't think that solves any
ambiguity because no one was intentionally over-engineering before.

It's akin to saying "don't do bad things." People never do bad things, only
things that are bad under a different set of principles or based on other
values.

My feedback is that this document should define what over-engineering means in
their context (since it, like what is "bad", is context-specific) and lay out
what engineers should look out for.

~~~
yetanotherjosh
If you agree it's a problem, I'm not sure why you think it shouldn't be talked
about. Your (a) and (b) responses would come from an engineer who is not open
to dialog, and I'd say from an engineer I'd prefer not to work with. I would
add another option to your set of possible responses: (c) Let me now think
harder about whether we really need database sharding and justify why I think
it's needed, and allow this further analysis to possibly lead to a revised,
simpler design. That's the route that the open-minded, discursive engineer
will take.

~~~
darkerside
I think the problem with a loaded term like "over-engineering" is that you are
assuming they haven't fully through their idea through, and that's why they
don't see things your way. I've seen much better results come from explaining
why you think database sharding isn't necessary yet (even if you think the
reasons seem obvious), and then asking your colleague to help you understand
what you might be missing.

~~~
yetanotherjosh
That's a reasonable perspective but the assumption I would be making isn't
that they haven't thought it through, it's that they're using a higher bar for
what's necessary, and are thinking it through from that point instead. The
dialog is then about coming to a shared understanding of what the actual
requirements really are. Therefore it's not critical or something to be taken
personally about one's proposed implementation, it's the symptom of unclear
requirements and the need to clarify them.

~~~
kybernetikos
> Therefore it's not critical or something to be taken personally about one's
> proposed implementation, it's the symptom of unclear requirements and the
> need to clarify them.

Absolutely, and that's why I agree that the term Overengineering is an
unhelpful shorthand that implies criticism to an unnecessary extent.

------
chralieboy
A huge missing part of the "Employees" section — which is great as a focus, by
the way — is specifying how your management works.

Especially in engineering organizations, a consistent problem is moving people
into management positions based on their skill as an individual contributor or
tenure. Both are orthogonal to people-management skills and, though good to
have from a team respect standpoint, far less useful.

Is it a priority of yours to avoid those problems? If so, it would be great to
see it listed out. How do you organize teams to be optimized for Employees?

Especially as you grow, I would imagine managing people towards their goals
and those of the company is going to be a larger and larger part of that
employee happiness.

edit: There is also nothing on employee growth. If that is a something you
value, it would be cool to see it in there.

~~~
ryandrake
Most places I've worked had no career path above Senior Software Engineer that
did not involve moving into management, which as you point out, is not
necessarily a skills match with "that smart individual contributor who you'd
like to reward".

I've heard some larger companies "solve" this by providing some title
advancement past "3rd Senior Engineer from the left". But is it satisfying to
you folks on these tracks? When you go from Senior Software Engineer to Staff
Software Engineer to Super Staff Software Engineer to Super Duper Staff
Software Engineer, do you consider it to be real career growth? Do you find
that this is truly a _parallel_ path with management, or does it eventually
plateau (i.e. the management path ultimately ends up reaching farther)?

~~~
Sophistifunk
What does it matter? If you're having real impact on the decisions you care
about, and your pay goes up who cares about "career growth"? What is a career
these days? There's no loyalty, no gold watch coming.

~~~
omouse
The titles and the career track matter because that's how you get to have real
impact and that's how your pay goes up. If you don't want to be thrown a spec
and told to just implement it we need more developers who have better job
titles and who can play the political game well.

If you're a dev you're more likely to have to bow to pressure from marketing
or other departments and won't have any real impact.

------
coldcode
Yet another team that seems to think the programmers should QA their own code.
I learned that lesson 30 years ago, good QA people are worth their weight in
gold. QA is a set of skills separate from the skills that programmers have;
expecting a programmer to be good at both is asking for trouble. I never would
hire an architect to wield a hammer and saw. You can't be good at everything.

~~~
patmcguire
I used to ask in interviews if they had a QA team, because it was on the Joel
on Software list
[http://www.joelonsoftware.com/articles/fog0000000043.html](http://www.joelonsoftware.com/articles/fog0000000043.html)

I stopped asking because the answers were always some variant on "that
encourages programmers to be lazy, because they know QA will be there to catch
it" and because it seemed like lot of companies treated that question as a
culture fit red flag. The responses were pretty hostile, like I'd asked why
none of the engineers were wearing suits.

I have no idea whether it's a good idea, but the current tech culture seems
pretty opposed to it.

~~~
ryan-allen
I once ran a small team with a specific QA guy, he was awesome. He had more
technical knowledge of the product than the remainder of the team (3 other
programmers) combined.

As a new manager, he was who I leaned on the most to find out things, and who
saved my ass on a number of occasions.

He deserved more respect than he got.

------
meesterdude
I applaud such a clear document; this is how company culture should be
defined. When people make decisions, at any level, they should be able to
reference a document like this to ensure it is within alignment and is proper.

But these are engineering principals, not company principals. And "employees"
is last, not first. Nor is it particularly clear in what sense employees
matter. Saying they matter does not describe in what way, it's a blanket
statement. Do they matter that you will pay them at or above market rate? that
you will help them with training and certifications? that you'll take care of
them when times get tough? You have to spell it out. Really spell it out.
Otherwise, it's too ambiguous and it'll get swept under the rug.

each page is 75% art, 25% text. I think this ratio needs to be flipped.

Still, this is something. I don't think it's "done" but it's more than most
have.

~~~
edawerd
I'll write more about this in my next post, but we started by going on an
engineering retreat and came up with a pretty massive document. The hardest
part was distilling all the text down to a point that was easily consumable. I
actually feel that the amount of text is just about right.

~~~
chralieboy
I agree and think you did an excellent job here. Distilling down such critical
information shows how much time and thought you put into it.

It's easy to ramble on for 100 pages, but capturing the essence of your values
in a few slides with a couple of tidy examples each is really hard.

~~~
meesterdude
sorry, but... really? these are bullet points. I could come up with these
points in literally 10 minutes. They aren't THAT original or revolutionary.
What matter are the details; the push come to shove stuff.

Maybe this is good for a TL;DR, but if you don't spell out the details you
leave room for ambiguity. Details help everyone think the same and gives them
all the same reference points. They all have examples they can pull from
already built in, so they are more likely to make the preferred decision.

------
michaelvkpdx
My first reaction to this... the document says "We are owners of each and
every feature we build", but who is "we"? If I write a feature, am I expected
to own it throughout the lifecycle?

It's easy to hide behind "We", and easy to say "we isn't me". I might suggest
something like "I own everything I build and everything my teammates build".
That eliminates a whole class of avoidance and excuses for bad code.

Overall it's a nice distillation of general corporate engineering teamspeak
but I didn't grasp anything new or enlightening. This document would be pretty
easy to ignore if I were in that group.

~~~
edawerd
What we meant by "we" is that the individual engineer who wrote the code is
ultimaetly responsible for it. From building/modifying the backend APIs,
frontend code, testing, QA, and ongoing maintenance/bug fixes.

I guess "we" really means "you"

~~~
codeonfire
That will never work because economic returns to a piece of code will not go
to the engineer. Both management and company owners will want most of the
returns of the code, leaving no profit motive for the engineer to be
ultimately responsible for it. The engineer will move on and the owners and
management are stuck with rotting code. Or management gets rid of all the
engineers because they want to keep all the revenue and discount both cost of
maintenance and need for engineers to profit.

~~~
hliyan
I believe you described Marx's theory of alienation[1] as applied to software
engineering.

[1]:[https://en.wikipedia.org/wiki/Marx's_theory_of_alienation](https://en.wikipedia.org/wiki/Marx's_theory_of_alienation)

~~~
codeonfire
Yeah, which is why companies should stop going on about 'owning' things. If
I'm going to own its creation and operation, I'm going to own all the revenue
it produces. All of it. I have all the means of production (no 19th century
power looms needed to create software) and all I really have to do is survive
while it is being produced.

~~~
omouse
This is actually what Philip Greenspun did at ArsDigita. Each project had its
manager/lead own the profit-and-loss:

From Founders At Work:

 _" I'm organizing this company like McDonald's. Each restaurant is going to
be managed by a few people, and they're going to have profit-and-loss
responsibility. If they make a profit, they get to pocket half of it. If they
make a loss, we're going to know who's responsible, and we're going to go
there and fix it, and there are going to be consequences for those people."
People have all the right incentives to make their customer happy, to do the
thing on time, to take the customer's money, deposit in the bank, and then
move on to the next one and get their bonus at the end of the year._

And apparently at one time Accenture had this philosophy too:

 _At the time Anderson Consulting (now Accenture) didn 't have any
salespeople. They always had the people who were executing the project sell
it. "You eat what you kill" was the phrase at Accenture. You don't have a
salesperson go out and tell the customer, "We can do this", making promises
and then handing it off to a programmer"_

------
RKoutnik
Quick question for the ZenPayroll folks lurking here:

How do you handle situations where there's a lack or breach of trust? If an
engineer comes to you saying "After $INCIDENT, I find it hard to trust
$COWORKER", what do you do?

Trust is very important & I'm glad to see you've given it an entire slide. I
particularly like "There’s little benefit to setting hard deadlines if you
know everyone is doing their best".

~~~
edawerd
That has definitely happened here. And I've personally had my fair share of
breaching people's trust. We're human. It happens.

There's no magical solution to fix it. I think the best thing to do is
acknowledge it to the person you've violated and tell them you're going to do
your best to earn their trust back over time (and actually do it).

------
omouse
I always like these types of books not only for the information but for the
idea that they will bring a team together around a joint identity. Instead of
people feeling like they gotta ask Alice or Bob about the right thing to do,
they can refer to the book and be guided toward it.

------
cdnsteve
It would be helpful to have an indication on these types of career sections on
what a companies stance is on remote employees. Many support it but never give
hints, many don't and keep quiet. Would be nice to get that out in the open as
a company and for specific positions.

------
farbenheinz
I like this a lot having a set of values that are created and owned by an
engineering team can only serve to improve software quality. I'd be interested
to know if these principles are something you expect to evolve and how you
plan to manage that evolution?

------
dkarapetyan
Trust, Competence, and Autonomy. This is not specific to software engineering.
If you have one of those missing then there will be dysfunction.

------
metaphorm
no critique of the content here, but that slide deck is like a case study in
how not to slide deck. no useful graphics, all the information content crammed
into a tiny sidebar with squished text.

its an essay in slide deck form. why make it a deck? just write it as an
essay.

------
mkramlich
engineering good. abstraction bad. my rough rule of thumb.

I know that's too high level of a description. but what I'm saying is... that
you _always_ pay the price for poor quality, rushed work, whether you pay that
price in an hour, tomorrow, next week, you always do, somebody does. so better
to get quality right.

however, I see lots of astronaut architecture and too-much-abstraction --
especially in all-Java/enterprise shops -- where, I see folks spending lots of
time on things which objectively don't have any business value and don't
objectively increase quality (reduced failure rate, reduced bug rate, etc.)
instead arguably seem to increase it, or increase the complexity and quantity
of moving-parts which can fail or otherwise bite people later. Quality good,
quantity bad.

Simple-but-perfect is better than bigger-but-shoddy.

------
yarper
It's a good idea but the whole document comes off as really patronising. I
mean - do good engineering teams need to be told to write tests and code
review each others work? Do good engineers need to be told that the customer
pays their wages?

Good engineers are always focused on delivering value to the customer, and
good engineers will always select stable systems rather than be swayed in some
kind of hormonal feature porn frenzy.

On top of that, in my experience, humility is not something you have to ask
for in an engineer. He or she will be painfully aware of every mistake they
make, it's the only thing driving their development.

tl;dr if the head of accounting thought you were a rowdy bunch of code
monkeys, then read the agile principles you'd end up with this

~~~
yetanotherjosh
We're all always on our way to becoming good engineers. Most of us really
aren't good engineers in one way or another. These kind of principles help
guide the whole team towards a set of high standards, in which individual team
members may be more or less deficient.

