Welcome to Sift’s document on Engineering Culture and Development on how we operate and what our goals as engineers at Sift are. We hire really smart people and trust them to make good decisions.
“It is amazing what you can accomplish if you do not care who gets credit.”
Harry S. Truman
Table of Contents
Culture
Accountability
The Ten Commandments of Egoless Programming
Development
Software Engineer
Junior
Software Engineer 1
Software Engineer 2
Senior 1
First and foremost, we deliver. If we don't do what we say we are going to do we will be seen as unreliable and unable to build what is required to make a great business. Perfect is the enemy of done. Although we strive to build a beautiful codebase, sometimes it will be messy and that is ok. First make it work, deliver, then make it better.
-
Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.
-
You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
-
No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
-
Don’t rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
-
Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
-
The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.
-
The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
-
Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say "I told you so." Never make your dearly departed idea a martyr or rallying cry.
-
Don't be "the coder in the corner." Don't be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.
-
Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
source: The Psychology of Computer Programming, Gerald M. Weinberg, 1971
Our development/career paths should always remain clear. Each level has a core set of values and expectations, in addition to the The Ten Commandments, that the engineer is able to exhibit. Progressing upwards means an engineer has been successful in exhibiting all aspects of their previous role and those before it.
This path is where most engineers will begin their journey at Sift. Each title change represents a significant level up in both maturity and technical capability.
A Junior Software Engineer is at the beginning of their career. They should have a reasonable understanding of core Computer Science concepts.
Learning Software Engineering techniques such as source control, testing and planning/estimation.
Focuses on smaller components of a system and is capable of completing well defined subtasks with the mentorship and assistance from more seasoned Software Engineers.
Communicates effectively with their peers and seeks a better understanding of their craft.
Software Engineer 1 has had real world development experience working on a team and shipping a product. They may have been focused on one particular language for a year or two, or have been spread across technologies but have worked on their core engineering skills during that time; i.e. not just working to consume a framework but working to understand it.
Engineers at this level should be focused on bettering their craft and understanding best practices and how to utilize them for their area of work.
They communicate well and are capable of delivering feedback to their peers. They regularly partake in code reviews and responds well to criticism of their code.
Software Engineer 2 is capable of taking well defined tasks and completing them in a way that is considered to be high quality with supervision from more senior team members. The progress through this level is focused on taking tasks of increasing complexity, scope and importance and completing them with very high quality with a lessening need for manager/tech lead oversight.
This level is the bread-and-butter level of engineering growth. Engineers at this level should be focused on becoming great engineers, learning how to set high quality bars for their work without sacrificing productivity. All engineers at and above this level should religiously follow stated best practices for the team without excessive handholding. Engineers at this level will continue to make mistakes, but should be improving the speed at which they learn from these mistakes. By the time they are ready to be promoted s/he will have focused on some technology as their expertise and become capable of mentoring interns and new engineers in these areas. They will start to participate more in the technical design process, often with guidance from senior engineers.
Engineers at this level are assumed to be constantly making steady progress on tasks that are assigned to them and know when to ask for help when they are blocked. They can own their independent small-to-medium features all the way through from technical design to launch.
They are capable of prioritizing the work in front of them and able to make forward progress, avoiding the temptation to focus on unimportant details or excessive bikeshedding.
The impact at this level is focused on task completion and depth in a larger area of the code base. Engineers at this level should be capable of release responsibilities for their area as well as on-call support for simple incidents in areas that they are not always familiar with.
They communicate well and are capable of delivering feedback to peers and their manager. When given a task with unclear requirements they know how to ask for clarification, and ensure that all assumptions are vetted before work starts to reduce the need for re-work. They understand how their work fits into the larger picture for their team, and use this to identify conflicting requirements to their tech lead and product manager. An important focus of this level is developing empathy for the users of their software, whether they be internal employees, customers, or other developers on the team. A team member at this level is seeking out the context they need to understand the why of a particular feature and nurturing this empathy via that understanding.
Senior Software Engineer 1 should be seen as a solid engineer who is a master of their specific domain. They are capable of owning technical design for projects of moderate complexity, and understand the tradeoffs in creating good software in their area. They hold a depth of knowledge in systems that enables them to debug those systems effectively without flailing. In addition to writing consistently high-quality code they are aware of industry best practices and trends, and have acquired at least one major skill outside of programming such as monitoring, performance optimization, documentation, integration testing or visual design.
They get lot done and deliver. They are responsible for complex tasks and complete them despite roadblocks, grabbing others for help or insight as necessary. They require very little oversight beyond high-level direction; they can take a complex user story, break it down into sub-tasks, and complete their sub-tasks with relative ease. The senior engineer 1 shows initiative beyond knocking tasks off a list; they are able to identify and suggest areas of future work for themselves or their teams. They seek evidence to support their ideas and start to build cases for these ideas. They deliver products to QA that they believe are well-baked and bug-free.
The Senior Software Engineer 1 has end-to-end responsibility for projects of increasing complexity that encompass more than their own development. They contribute to the common code bases and standards for the team. They understand the business that their code supports, and possess empathy for the users of their software; they use this understanding to influence their task prioritization. They assist QA in identifying and validating test cases and can identify regression risks in their features. In general, they can identify risks in code, features, and design, and communicate these to the appropriate parties.
Maturity is a big part of becoming a Senior Engineer. While technical mastery in various areas comes along with being a Senior Engineer we will focus on the personal characteristics that give us an indication that this person can be influential to the organization in the domain of engineering.
A great read this blog post.
The Staff Engineer is the technical owner, or in partner with other engineers, of a particular Pillar in our technology such as our API, Infrastructure or Security. A key role of the Staff Engineer is to multiply the effectiveness of others by facilitating cross-team work. They help breakdown barriers and coordinate with other Staff Engineers to keep our technology stack holistic and in sync.
They shape architecure, ship multiple large services, complex libraries or major pieces of infrastructure. All while understanding the tradeoffs between technical, analytical and product needs and leads to solutions that take all of these needs into account.
During technical discussions a Staff Engineer seeks to understand. They help guide debates to reach a consensus and then clearly communicates back decisions that have been made.
Consistintely delivers large systems involving one or more teams.
Primarily acts as multiplier by building systems, authoring tools, or introducing policies or patterns that raise the productivity level of the entire organization.
Sets techinical direction.
Not everyone has to become a manager and have direct reports to grow in their career. The Individual Contributor path at Sift offers signficant leaderships oppurtunities in different capacities other than having direct reports.
You are ready to lead a team. You have started taking on the responsibities of a mentor to many of your peers in the organization and have spent time as a Tech Lead.
Much less time will be spent writing code. It is still expected though that an engineering lead stays engaged in the code base and assisting where needed. Their primary responsibility however lies in ensuring the success of their team by focusing on delivery; identifying bottlenecks and removing roadblocks.
The Engineering Lead partners closely with a Project Manager and Product Manager/Lead to manage scope and ensure the technical deliverables are met.
The Engineering Lead is an independent manager. They are comfortable managing team members with different skill sets from their own. They communicate expectations clearly to all team members, solicit and deliver individual feedback frequently (not just in the scope of review periods). In addition to strong management skills, the engineering lead acts as a leader for the technical roadmap for their pillar. They clearly communicate the timeline, scope and risks to their pillar partners, and lead the delivery of major initiatives on clear timelines. Additionally, they identify areas of strategic technical debt, do the cost/benefit analysis for resolving this debt and communicate suggested timelines for prioritizing this to the management team.
TBD
TBD