As a software developer

by Lohn "Human Terror" Hochstein @norootcause

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. 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. 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.
20. A technical decision needs to be made, and the stakeholders are
    sharply divided on the proposed approaches.
21. Marshall support for your proposed technical approach through
    one-on-one conversations with potential supporters.
22. 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.
23. Use the whiteboard to help bring your peers to a shared
    understanding of some technical issue that you are working on.
24. Effectively coordinate with your peers when dealing with an ongoing
    outage or other incident. (Hit the tweet limit, so stopping for
    now).

...(I'll randomly do some more as it strikes me)...

1. Instrument your code to make it easier to reason about its behavior
   when it's running (i.e., improve operability).
2. Describe, in writing, examples of the human activities that your
   software system is intended to support.

3. Develop a deeper understanding of a system that you now work on but
   ^W didn't build.

4. Look into the history of how an internal system came to be
   implemented the way it was.