Engineering Principles and Values

Great stuff, looks like you&#x27;ve come a long way.<p>I&#x27;d caution against the term &quot;over-engineering.&quot; It is a straw man[1] — no one is pro-over-engineering — so it is only ever used to discourage long-term thought. It&#x27;s a good thing to try and avoid, but maybe pick something neutral like &quot;predicting the future.&quot;<p>Hacking, on the other hand, is sometimes advocated for (e.g. Facebook) and can be good or bad depending on circumstances.<p>[1]: <a href="http:&#x2F;&#x2F;seneca.systems&#x2F;values#what-constitutes-a-value" rel="nofollow">http:&#x2F;&#x2F;seneca.systems&#x2F;values#what-constitutes-a-value</a>

A huge missing part of the &quot;Employees&quot; section — which is great as a focus, by the way — is specifying how your management works.<p>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.<p>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?<p>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.<p>edit: There is also nothing on employee growth. If that is a something you value, it would be cool to see it in there.

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&#x27;t be good at everything.

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.<p>But these are engineering principals, not company principals. And &quot;employees&quot; is last, not first. Nor is it particularly clear in what sense employees matter. Saying they matter does not describe in what way, it&#x27;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&#x27;ll take care of them when times get tough? You have to spell it out. Really spell it out. Otherwise, it&#x27;s too ambiguous and it&#x27;ll get swept under the rug.<p>each page is 75% art, 25% text. I think this ratio needs to be flipped.<p>Still, this is something. I don&#x27;t think it&#x27;s &quot;done&quot; but it&#x27;s more than most have.

My first reaction to this... the document says &quot;We are owners of each and every feature we build&quot;, but who is &quot;we&quot;? If I write a feature, am I expected to own it throughout the lifecycle?<p>It&#x27;s easy to hide behind &quot;We&quot;, and easy to say &quot;we isn&#x27;t me&quot;. I might suggest something like &quot;I own everything I build and everything my teammates build&quot;. That eliminates a whole class of avoidance and excuses for bad code.<p>Overall it&#x27;s a nice distillation of general corporate engineering teamspeak but I didn&#x27;t grasp anything new or enlightening. This document would be pretty easy to ignore if I were in that group.

Quick question for the ZenPayroll folks lurking here:<p>How do you handle situations where there&#x27;s a lack or breach of trust? If an engineer comes to you saying &quot;After $INCIDENT, I find it hard to trust $COWORKER&quot;, what do you do?<p>Trust is very important &amp; I&#x27;m glad to see you&#x27;ve given it an entire slide. I particularly like &quot;There’s little benefit to setting hard deadlines if you know everyone is doing their best&quot;.

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.

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&#x27;t and keep quiet. Would be nice to get that out in the open as a company and for specific positions.

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&#x27;d be interested to know if these principles are something you expect to evolve and how you plan to manage that evolution?

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

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.<p>its an essay in slide deck form. why make it a deck? just write it as an essay.

engineering good. abstraction bad. my rough rule of thumb.<p>I know that&#x27;s too high level of a description. but what I&#x27;m saying is... that you <i>always</i> 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.<p>however, I see lots of astronaut architecture and too-much-abstraction -- especially in all-Java&#x2F;enterprise shops -- where, I see folks spending lots of time on things which objectively don&#x27;t have any business value and don&#x27;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.<p>Simple-but-perfect is better than bigger-but-shoddy.

It&#x27;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?<p>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.<p>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&#x27;s the only thing driving their development.<p>tl;dr if the head of accounting thought you were a rowdy bunch of code monkeys, then read the agile principles you&#x27;d end up with this