Read on Twitter
As a software developer, you may be called upon to perform some of these tasks in your career.
How well a CS degree prepares you for these tasks (and whether it even should prepare you for these) is left as an exercise to the reader.
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧵" title="collectie" aria-label="Emoji: collectie">
1/
How well a CS degree prepares you for these tasks (and whether it even should prepare you for these) is left as an exercise to the reader.
1/
Make a behavioral change to a medium-to-large system that you don& #39;t understand. 2/
The system is "slow". Figure out why. 3/
Review a colleague& #39;s code and provide meaningful feedback. The code may be in a part of the codebase that you don& #39;t have any personal experience with. 4/
Write user-facing documentation (this includes API docs). 5/
The system is down. Help get it back up as quickly as possible. 6/
The system is down. To get it back up, you will need to perform a number of repetitive manual actions. Alternately, you can write a script to automate them. Determine which approach to use.
7/
7/
Solicit advice from a colleague about a design problem you& #39;re facing, given that you& #39;ve thought about the problem for a lot longer than they have. 8/
Identify that progress will require a meeting, organize the meeting, run it, and capture the outcome. 9/
Propose, in writing, your favored solution to the technical problem. Solicit and address concerns from your colleagues. 10/
Communicate the status of your work-in-progress to your manager in a way that both reflects your uncertainty and is useful for your manager. 11/
Take part in quarterly planning of development work, prioritizing a set of proposed work. 12/
Advocate for reliability-related work, since it will never be driven by customer asks (although they will be upset if the service goes down). 13/
Analyze a system outage to understand how it happened (one of my personal favorites). 14/
Migrate your service from one platform to another without impacting customers. 15/
Convince a team that consumes a platform you provide to migrate from the old version to the new one, and then retire it. 16/
Figure out how to interface the system you are working on with another system, that is poorly documented. 17/
Make a change to a system that was implemented in a language/platform that you have little-to-no experience with. 18/
Debug a build that broke inexplicably. 19/
Review someone else& #39;s design proposal, and provide meaningful feedback. 19/
A technical decision needs to be made, and the stakeholders are sharply divided on the proposed approaches. 20/
Marshall support for your proposed technical approach through one-on-one conversations with potential supporters. 21/
Identify how your organization& #39;s power dynamics constrains the types of technical solutions that are actually possible, so you don& #39;t try to do something that has no practical chance of succeeding. 22/
Use the whiteboard to help bring your peers to a shared understanding of some technical issue that you are working on. 23/
Effectively coordinate with your peers when dealing with an ongoing outage or other incident. (Hit the tweet limit, so stopping for now). 24/24
I& #39;ll randomly do some more as the mood strikes me.
Instrument your code to make it easier to reason about its behavior when it& #39;s running (i.e., improve operability).
25/
Instrument your code to make it easier to reason about its behavior when it& #39;s running (i.e., improve operability).
25/
Describe, in writing, examples of the human activities that your software system is intended to support.
26/
26/
Develop a deeper understanding of a system that you now work on but didn& #39;t build. 27/
Look into the history of how an internal system came to be implemented the way it was. 28/
