reforming-dev/meditations
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Transfer from previous git host

Browse Source
This commit is contained in:
reforming-dev 2026-02-27 15:50:41 +00:00
commit 4e0174e7e9
1 changed files with 219 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

219
README.md Normal file
View File

@ -0,0 +1,219 @@
# Reformed and Always Reforming
WIP
# Debating with Gentleness
> _And the Lord's servant must not be quarrelsome but kind to everyone, able to teach, patiently enduring evil, correcting his opponents with gentleness. God may perhaps grant them repentance leading to a knowledge of the truth, and they may come to their senses and escape from the snare of the devil, after being captured by him to do his will._
2 Timothy 2:24-26 (ESV)
In our discussions, we should have these characteristics:
- Not quarrelsome
- Kind to everyone
- Able to teach
- Patiently enduring evil (NASB 'Patient when wronged')
- Correcting with gentleness
In context, Paul has discussions with unbelievers/apostasizing Christians in view. Instead of a sinning brother, we have a faithful brother. Instead of matters of eternity, we'd discussing software. How much more should these characterize our speech.
# Honor Your Father and Mother
> _"Honor your father and your mother, that your days may be long in the land that the LORD your God is giving you."_
Exodus 20:12 (ESV)
WLC on the 5th Commandment
## Duties and Sins of Inferiors
- Duty
- [ ] Reverence in heart, word and behavior
- [ ] Prayer and thanksgiving
- [ ] Willing obedience
- [ ] Due submission
- [ ] Fidelity to their persons and authority
- [ ] Bearing with their infirmities
- [ ] Covering them in love
- Sin
- [ ] Shame/dishonor to their person or government
- [ ] Rebellion against their lawful counsels, commands and corrections
## Duties and Sins of Equals
## Duties and Sins of Superiors
# For God's Working All Things For Good
> _And we know that for those who love God all things work together for good, for those who are called according to his purpose._
Romans 8:28 (ESV)
God has placed us with our coworkers for their good. Be a willing instrument. Even when your coworkers don't deserve to be benefited, do it in loving service to your faithful Savior (bruised reed He will not break and smoking flax He will not quench). You are on your team for the good of your coworkers.
# The Curse and Code
God cursed the ground and that includes code
```
"Because you have listened to the voice of your wife
and have eaten of the tree
of which I commanded you,
'You shall not eat of it',
cursed is the ground because of you;
in pain you shall eat of it all the days of your life;
thorns and thistles it shall bring forth for you;
and you shall eat the plants of the field.
By the sweat of your face
you shall eat bread,
till you return to the ground,
for out of it you were taken;
for you are dust,
and to dust you shall return."
```
Genesis 3 (ESV)
## Sweat and Code
> _By the sweat of your face you shall eat bread_
Genesis 3:19 (ESV)
> Observe that our labor is our duty, which we must faithfully perform; we are bound to work, not as creatures only, but as criminals; it is part of our sentence, which idleness daringly defies. That uneasiness and weariness with labour are our just punishment, which we must patiently submit to, and not complain of, since they are less than our iniquity deserves. Let not us, by inordinate care and labour, make our punishment heavier than God has made it; but rather study to lighten our burden, and wipe off our sweat, by eyeing Providence in all and expecting rest shortly.
Matthew Henry on Gen 3:19
As a Software Engineer, there is often a task or story that is overwhelming in it's tedium or utterly boring in it's lack of novelty. How should we as Christians handle our work when it is repulsive to us?
1. Lighten our burden by our industry and ingenuity (as Henry says earlier)
- It is a godly endeavour, not to avoid our punishment (which is idleness), to diligently labor to make the work as easy as God's providence will allow
2. Embrace our burden without complaint as the just correction for our sin
- Eating bread will require sweat and effort and difficulty. Embrace that difficulty and provide bread for your family
- The difficulty and tedium come from the hands of our loving Father
3. Do your work to the glory of Christ (see [All in the name of Jesus](#all-in-the-name-of-jesus))
- Not in a rush to minimize our sweat and get it over with but with inordinate care to do our work well
## Blight, Mildew and Hail
Why is the work of our hands fruitless? "You looked for much, and behold, it came to little. And when you brought it home, I blew it away" (Haggai 1).
> _I struck you and all the products of your toil with blight and with mildew and with hail, yet you did not turn to me, declares the LORD._
Haggai 2:17 (ESV)
The Lord disciplines his people and fruitless labor is one of those disciplines. The purpose is to turn our hearts towards him. Put first the things the Lord tells us to prioritize and prayerfully petition God for fruitful labor ("Give us this day our daily bread").
# Welcoming Strangers
> _I was a stranger and you did not welcome me_
Matthew 25:43 (ESV)
We have an obligation to be welcoming and hospitable to our brothers and sisters, especially went we don't know them. When someone new joins our team or our department or the ministry, we should rejoice at the chance to welcome them as we would welcome Jesus. In a remote workplace, feeling welcomed is extra hard and so is being welcoming! I've found success in scheduling a one-on-one video call and asking questions and becoming friends. Also sincerely and earnestly insisting that they reach out if they run into any issues.
# All in the name of Jesus
> _Whatever you do in word or deed, do all in the name of the Lord Jesus, giving thanks through Him to God the Father._
Colossians 3:17
Not just the code that we write and the maintenance we provide, but even the words we say (and type) should be said in light of Jesus' adopting us and should show Christ to the world
# Do Not Grow Weary
> _Let the one who is taught the word share all good things with the one who teaches. Do not be deceived: God is not mocked, for whatever one sows, that will he also reap. For the one who sows to his own flesh will from the flesh reap corruption, but the one who sows to the Spirit will from the Spirit reap eternal life. And let us not grow weary of doing good, for in due season we will reap, if we do not give up. So then, as we have opportunity, let us do good to everyone, and especially to those who are of the household of faith._
Galatians 6:6-10 (ESV)
What an encouragement to do our best and do what is right despite external pressures (eg: stakeholders, coworkers, teammates, leadership). On top of that pray, ask for perseverance, strength and a bountiful harvest.
Being in a season of conflict and push back and lost progress is draining and difficult. Be gracious and be patient. Trust the Lord with the outcomes.
We are do to good not just to teachers or the people we like but _do good to everyone_ and our obligation to believers is even stronger than that _especially to those who are of the household of faith_. As developers, we are to do good to our stakeholders and user. Doubly so when our stakeholders and user are believers! It is so easy to be pressured into a mediocre job but we protect our user's data! We generate our stakeholders livelihood! Do good to everyone and especially our brothers and sisters.
# Stealing User Data
> _You shall not steal_
Exodus 20 (ESV)
This applies just as much to cars as to socks as to user data. We are obligated to protect our neighbors possessions (Deut 22:1-4), not sell and trade them for our profit (Prov 21:6). There are gray areas and different developers will draw the line in different places. I would draw the line like so:
- Any data that originates from the user, belongs to the user and is user data
- Data calculated from user data, is user data
- Any user data that is freely, directly, and explicitly handed over by the user is permissible to collect
- Freely: the user had a reasonable choice to withhold the data and consciously chose to give it
- Directly: the user understood who would be the recipients of their data
- Explicitly: the user explicitly chose to share the data (as appose to "he didn't say 'no'...")
- No user data should be collected
- All user data needs to be collected, should be immediately and permanently deleted
- All user data that can't be deleted, should be encrypted end-to-end allowing only the user to access it
- All user data that can't be encrypted, should be anonymized
- All user data that can't be anonymized, should be secured against unnecessary access (including government access)
- All user data that can't be secured, should be deleted
- Any time user data is leaked, either by a hacker or legal subpoena, the theft of data should be communicated to the user
- Canary clause is viable workaround to certain gag orders
# Root of Bitterness
> _See to it that no one fails to obtain the grace of God; that no "root of bitterness" springs up and causes trouble, and by it many become defiled_
Hebrews 12:15 (ESV)
>>>
When someone hurts you, it is as if that person dropped a seed of bitterness onto the soil of your heart. At that point, you can choose to respond in two ways. You can either reach down to pluck up the seed by forgiving your offender, or you can begin to cultivate the seed by reviewing the hurt over and over again in your mind. Bitterness is the result of dwelling too much on hurt. Again, it is indicative of the fact that one has not truly forgiven an offender (see Matt 18:34-35)
>>>
Lou Priolo, Resolving Conflict
# Saying 'No'
>>>
_If I bring the sword upon a land, and the people of the land take a man from among them, and make him their watchman, and if he sees the sword coming upon the land and blows the trumpet and warns the people, then if anyone who hears the sound of the trumpet does not take warning, and the sword comes and takes him away, his blood shall be upon his own head. He heard the sound of the trumpet and did not take warning; his blood shall be upon himself. But if he had taken warning, he would have saved his life. But if the watchman sees the sword coming and does not blow the trumpet, so that the people are not warned, and the sword comes and takes any one of them, that person is taken away in his iniquity, but his blood I will require at the watchman’s hand._
>>>
Ezekiel 33 (ESV)
Business decisions have multiple contributing (and sometimes contradictory) priorities and considerations backing them. Software and software engineering is often a piece or sliver of this decision, sometimes more in the background than other considerations. As an engineer, (as Robert Martin says) the business pays you to say 'No' when something is not possible. This is a professional standard. Don't pretend something is possible or will work when your professional knowledge and experience says it won't. Give honest feedback early.
That is well and great but what does it have to do with being a reforming developer? The requirement to say 'No' is twice as heavy on the shoulders of a Christian software engineer. If the business hires you as a watchman (of sorts) to tell them 'No' when something won't work, you're obligated by not just your profession but also your religion to give honest feedback early.
Once this feedback has been provided to those in authority, the obligation has been met. The watchman isn't responsible for what the hearer does when he blows the horn. They have been warned and their 'blood' shall be upon their own head. The business may not heed your advice because there are other priorities or considerations and that is normal. Your obligation as a professional and a Christian as been met by enabling them to make an _informed_ decision.
# Both Perspectives
> _A fool takes no pleasure in understanding, but only in expressing his opinion._
Proverbs 18:2 (ESV)
The goal is to understand. How do we measure understanding? My metric is 'neutral point of view' ([youtube](https://www.youtube.com/watch?v=TCrepTa3YcY)): Can you articulate both perspectives factually such that proponents of that perspective would affirm your articulation? If 'yes', then you understand. If 'no', then you don't understand their perspective. This isn't sufficient to prove understanding but I believe it is a necessary component of understanding.
The anti-goal is only expressing your own perspective. This is hard to avoid, especially if you are talkative or passionate. My rule of thumb here would be: Ask questions to understand first. A respectful interlockator will then ask questions to understand your perspective.
> _If one gives an answer before he hears, it is his folly and shame._
Proverbs 18:13 (ESV)
Don't interrupt, even in your head! It is tempting to form a counter argument before understanding the other perspective. Be quick to hear and slow to speak (James 1:19). To do otherwise is to your folly and shame.
> _The one who states his case first seems right, until the other comes and examines him._
Proverbs 18:17 (ESV)
It is easy to be convinced in your own mind that position X is the only correct way to view the situation. The Lord gives us a body of believes to give us counsel because we are easily lead astray (like sheep). Intentionally seek out the other side so that you can judge rightly. If you haven't hear the other perspective, withhold judgement.
# Bike Shedding and Gate Keeping
> _In all toil there is profit, but mere talk tends only to poverty_
Proverbs 14:23 (??)
Be wary of talking too much. There is a place for talking, but value is created by _doing_ and even doing it wrong has more profit (when we examine what went wrong and how to improve) than mere talk. Just do it! Software Engineers are expensive so mere talk tends to rapid poverty.
There are two common scenarios that come to mind where the danger of excessive talking is ever present and even likely. The solution from Solomon in both is the same: stop talking, toil and deliver value.
The first scenario is when planning what to do next. There are a lot of considerations and detail and nitty-gritty which will certainly be worked out. Lay out what is necessary for the engineers to be aware of so they can make wise decisions, answer questions and avoid rabbit trails. For example, 'What design pattern should be used?' Maybe a state machine could work but ultimately let the dev that pulls in the story figure it out. A bunch of talk from a large group is going to tend towards poverty, rather than profit. Put the necessary details in the story, let people comment on the story if they have some suggestions, if they are really passionate about it, they should pull in the story and get it done! (Also see [Bike Shedding](https://en.wikipedia.org/wiki/Law_of_triviality))
The second scenario is reviewing code changes (async pull requests especially). There are a multitude of worth and important aspects of a change that may need to be addressed on any particular patch. There are also a multitude of rabbit hole discussions that tend towards poverty (as Solomon says). Drawing the line between these very similar things is difficult. Here is my rule of thumb:
- If it is something that automation should have rejected, fix the automation (eg: compile, run tests, lint, format) so they have an objective standard to pass
- If the patch makes the codebase better overall, even though it isn't perfect, definitely throw out some helpful comments but don't prevent them from delivering value. (Offering to pair is a great way to level up less experienced engineers)
- Else the patch is overall neutral or bad for the codebase, in this case there are serious concerns. Address them gently, give some ideas on how to fix (eg: 'smaller patch without X' or 'checkout this example over here'), if time and patience allow offer to pair!