Read on Twitter
Producing code changes is maybe 10% of the work of professional software development.
Actual things you'll be doing on the job, a thread
Actual things you'll be doing on the job, a thread
1/ Thinking hard about requirements. Asking a lot of questions, confirming assumptions, making proposals, listening to feedback, making counter proposals, and trying to figure out what the right thing is (and isn't) to build now. This can take a long time.
2/ Thinking hard about implementation. Looking at the existing system, reusable code, potential open source libraries, opportunities for reusability/extensibility/refactoring, "making the change easy then making the easy change", etc. Discussing all this with rest of the devs.
3/ Actually piecing together a plan for implementation. This can happen in your head if you're a pantser or you can write it down if you're a plotter, but doing the decision work up-front can take a lot of friction out of the programming work.
4/ Actually writing the code. Writing tests, writing code, and going back and forth until the system behaves how you thought you wanted it to in 1 and 2. Updating your requirements and implementation plan depending on how this goes.
5/ At this point it's probably a good idea to revisit the non-functional requirements. How readable is the code? Is their needless repitition? Obvious refactors? What about security, performance, accessibility, reusability, extensibilty etc? Look for some easy wins.
5/ Updating your product managers, dev managers and tech leads with your progress. You'll spend a lot of time fretting about these updates, feeling anxious, especially when the thoughts about the work have not coalesced into the right order in your head yet.
6/ Requesting reviews from other developers in PRs. The better you prepare for these the smoother they go. Writing good commit messages and writing a good PR description, then responding to feedback and either making required changes or making the feedback a new task.
7/ Reviewing other developers PRs. In order for these to be effective you need a good relationship with the developer whose code you're reviewing, the ability to make a coherent argument, and the good sense to pick your battles. Even then these require a lot of care and attention
8/ Deployment. Depending on how good your teams tooling is this can be as simple as the change being merged and auto-deploying. Making production data changes is still an unsolved problem on most teams (though schema-migrations are fairly standard now).
9/ QA. Checking that your changes got deployed and work as expected. Most teams don't have a separate QA function, and are therefore fundamentally unserious about robustness.
10/ Production support. Fixing production when it goes down or when there are errors reported. The worse your code gets, the more this takes up your development teams time.
11/ Infrastucture work. Making your tooling and deployment pipeline smoother. Can be difficult to convince a product manager to give you much time to work on this so you can only really expect it on teams with mature engineering cultures.
12/ Refactoring. Making improvements to your code that make it easier to understand, handle more of your edge cases, and make it easier to debug. Again, not many teams get dedicated time for this, so experienced developers just sneak this stuff in without making a big deal.
13/ Debugging. Similar to the above software development cycle, only you're fixing existing behaviour rather than changing it to something else. Also, can take an unbounded amount of time depending on the complexity of the bug.
14/ Writing documentation. Vanishingly few teams have any real time for this but much like working on infra, this can have a non-linear effect on the lifetime productivity level of your entire team.
These seem like they might be in order but they're not. Doing this job professionally you're usually going back and forth thinking about multiple changes and features.
Most software projects are a continuing push to move the ball forward in all the ways described above
Most software projects are a continuing push to move the ball forward in all the ways described above
