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.
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't understand. 2/
The system is "slow". Figure out why. 3/
Review a colleague's code and provide meaningful feedback. The code may be in a part of the codebase that you don'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're facing, given that you'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'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's power dynamics constrains the types of technical solutions that are actually possible, so you don'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'll randomly do some more as the mood strikes me.
Instrument your code to make it easier to reason about its behavior when it's running (i.e., improve operability).
25/
Instrument your code to make it easier to reason about its behavior when it'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't build. 27/
Look into the history of how an internal system came to be implemented the way it was. 28/
