Successful engineers at Sourcegraph
The following is an idealized archetype of a successful engineer at Sourcegraph. Its purpose is to give engineers something to strive towards – regardless of which level they are currently on.
It’s a combination of attributes that multiple successful engineers, on various levels, show at different times in varying degrees. Nobody checks all boxes all the time and how exactly these items play out may vary by level.
The most successful engineers check a lot of the boxes most of the time.
-
Great programmers
They can write code in the languages they work with as well as the best in the world.
They know their tools enough to use them to maximum efficiency.
They know what they don’t know.
-
Continuously improve things around them
They leave codebases in a better state than they found them.
They improve processes.
They ask “do we still need this?” about code, features, products, processes.
-
Unblock themselves
They ask for help – as early as needed.
They debug and try alternative approaches.
They know how to continue working while waiting for an answer from a colleague in a different timezone.
-
Get better on their own
If left alone, they will find ways to get better and improve. If you nudge them and give them tips and directions, they get even better.
-
Ship value to customers; they don’t write code for code’s sake
They know that delivering value to the customers is all that counts in the end.
They really want their work to end up in the hands of customers, where it’s used successfully.
They see Engineering as a business function and understand that Engineering isn’t there to serve Engineering, it’s there to serve the business and provide value to it.
-
Great communicators
Slack, RFCs, code reviews, GitHub comments, commit messages, pull requests, Zoom calls—they know that all of these are forms of communication and they know in which situations and how to use each medium best.
They know that communication counts a lot in an async/remote communication and that communication is the work at times and not just something that gets in the way of coding.
-
Share their work regularly
They know that sharing work and progress is not about boasting; it’s about keeping others in the loop and fostering moments of “Ah, I remember when $name shared how they did $project, maybe we can take this approach”
-
Find work and problems to solve
They look around them and at the company goals and find ways that we can do better.
They are aware of where the business is headed and what our customers want.
They advocate for their work, seeking the alignment that is needed to decide whether or not now is the right time for that work.
They propose fixes and solutions, product ideas and roadmap additions.
They will be busy improving our product and codebase even if the rest of the company goes offline for 4 weeks.
They are skeptical of red tape.
-
Have a sense of urgency
They know that we’re a startup that has to move fast.
When someone says “next week” they ask “why not tomorrow?”
They know that a sense of urgency is not about shipping hacks, but about finding the quickest solutions with the right tradeoffs for the problem at hand: they don’t build out a full system where a prototype is all that’s needed, but they also don’t bring a hack to solve a systemic problem like security.
-
Not solo players
They know that a team is more than a collection of individuals that share a ticket board.
They value a well-running team and try their best to make it a well-running team because they know that a group of engineers working together on a codebase over time is one of the best ways to continuously ship value to customers.
They work with Product, Design, Security, CE, TS and other departments not because they have to but because they know that their input will improve their work.
-
Care about the whole software lifecycle
They care about shipping software from end to end: from planning, to coding, to demoing, to docs, to announcement, to getting it in the hands of customers, to helping customers use it, and to making improvements over time.
They think actively about the consequences their choices will have on all parts of this life cycle: is this a breaking change? Does this need to be backwards-compatible? Do we need a slow rollout here? How do we test this at scale – can we test this at scale? When and how do we need to loop in the Security team? How do we enable CE? What do we/CE/TS/customers do if it breaks?