Unsung Developer Thoughts
Welcome to my unsung developer thoughts! These are all the thoughts that cross my mind during the non-development phases of software engineering. It covers reviewing a feature request, reviewing a pull request, implementing tests and deploying software.
One of the challenges facing new programmers is taking the programming skill and figuring out how to produce value from it. The goal here is to provide programmers the questions to ask so that they can produce reliable and consistent applications, evolving them into software engineers.
Table of Contents
- Code Review
- Deployment
- Feature Request
- Testing
- How should this content be consumed?
- How was this written?
Code Review
Check yourself
- Should you have a talk with the developer before reviewing the code?
- Should you have a talk with the developer before submitting the review?
- Are you leaving too many nitpicky comments?
- Are you trying to make the other developer write your code?
Recheck the basics
- CI Passes - automated tests, linter, code coverage, etc
- Are the migrations/schema changes condensed?
- Are the code removals thorough?
- Are cross-cutting interface changes updated everywhere?
Review the tests
The tougher bits
- Are there changes that impact backwards compatibility?
- Are existing or current sessions impacted?
- Are hacks documented?
Deployment
Assess the risk
- What's the reasonable worst case scenario?
- Where will the most likely errors occur?
- Does the change impact customers?
Organization and preparation
- What customers should be involved in the deployment?
- What's the rollback process?
- Does the change require monitoring?
- Do you need to notify customers of the change
- Should the deployment occur after hours?
Consider the details
- Does any data need to change before or after deployment?
- Does the change require any manual actions before or after deployment?
- Do the frontend changes need to be deployed before or after the backend changes?
- Are there service interface changes?
- Do the SQL changes require locks?
- What SQL objects are being locked and for how long?
- What are the sizes of the impacted SQL objects?
- How frequently are the impacted SQL objects used?
- Does the application need to be scaled down during the deployment?
Feature Request
Understanding user impact
- What users would see this change?
- What is the user trying to do?
- Is it a reasonable user experience?
- How do users recover from errors?
- Do users need to be notified?
- Does the change include a deprecation?
Assess the risk
- Will this require changes across the project?
- How comfortable are you with the code?
- Does the code have tests?
- Is there a maintainer available for advice?
- Is there a power user available for advice?
Estimate the cost
- What does the maintenance look like?
- Does this impact other flows?
- What are the exception flows?
- What are the assumptions and what happens when those aren't true?
- What are the error states and their next steps?
- Does this require monitoring?
- Will this remove or add technical debt?
- Does this unlock future solutions?
Consider the data
Testing
Where to begin?
- Is the logic truly being tested?
- Can different datasets cause different results?
- Are exception flows reasonably covered?
- Do the changes require permission tests?
It's more than asserts!
How should this content be consumed?
For now, the best way is probably to review titles of the prompts first to get an understanding of how things are mapped out. Spend a few moments with each title and gauge how comfortable do you feel about the topic. After you've gone through each of them, come back to those that made zero sense or were extremely uncomfortable. Those are your areas of growth for the future. You should also come back to those that cover areas that are common to your role(s). These are areas of immediate impact. The remainder can be put off and consumed at a later time.
How was this written?
These prompts are intentionally vague and generalized. They are intended for you to explore in the context of your own life and work. That said, they are coming from my own perspective of life and work. They are a product of my value system as a person and as an engineer. You probably differ, so keep that in mind. My intention was that these prompts are things that an engineer should consider instinctively for every change. The more experienced you are the quicker you are to know which to consider based on the particular task at hand. Until you get to that point, you may need to force yourself review these prompts for changes until it becomes instinctual. For me, this skill was developed through pain. I want to see others succeed where I failed. I want to see you produce value! Not everything has to be learned by grinding and suffering.