A Little Help Can Go A Long Way!
A Little Help Can Go A Long Way!
This Dvar Torah was originally published in Torah && Tech, the weekly newsletter I publish together with my good friend Ben Greenberg. To get the weekly issue delivered straight to your inbox click here.
This week’s Torah portion discusses, among other things, how to help others who’ve come across hard times.
וְכִֽי־יָמ֣וּךְ אָחִ֔יךָ וּמָ֥טָה יָד֖וֹ עִמָּ֑ךְ וְהֶֽחֱזַ֣קְתָּ בּ֔וֹ
“If your brother becomes destitute and his hand falters beside you, you shall support him…”
(Vayikra 25:35)
At this point, the Torah doesn’t yet go into specifics regarding how you should support the person whose hand faltered, but Rashi fills in:
“ You shall support him: Do not allow him to fall down and collapse altogether, in which case it would be difficult to pick him up again [from his dire poverty]. Rather, “support him” while his hand is still faltering [for then it is easier to help him out of his trouble]. To what can this be compared? To a load on a donkey; while it is still on the donkey, one person can grasp it and hold it in place. Once it falls to the ground, however, [even] five people cannot pick it up.”
The lesson is a simple one; help keep people on their feet, it’s a lot easier — and cheaper — than lifting them once they fall, though as a Torah observant techie I think there are a few more lessons we can learn, relevant to the field.
The first is concerning our code. How many times do we come across old “legacy” code and it’s just a mess! Spaghetti code all over the place, nothing is documented, and every time you touch a line of code, something seemingly unrelated five files away seems to break.
How did it get that way? No one consciously decided to sit and write terrible code. It was the result of many small decisions. Maybe a tight deadline meant documentation was left “for next week.” Perhaps a rushed manager made the decision that writing tests was a waste of time better spent on churning out features. Whatever the case was, small decisions were made, and the compound interest on the technical debt grew from there.
How many times were we working on a small project and cut corners because we figured it was such a small codebase, who cares about best-practices? Only to find that by the time those mistakes came to bite us in the back fixing them would require a complete rewrite?
Spending just a few extra minutes writing a test, refactoring a function, and writing a README will save us hours of grief down the line!
The second lesson is in people skills, (and may not be limited to tech!).
Many times we find ourselves in a situation where a member of the team acts in a toxic way and is bringing the rest of the team down. At that point, the situation is very hard to deal with, and tough decisions often need to be made. But most times, those situations don’t develop overnight, it usually starts with a small comment here, a snide remark there, and people don’t want to say anything for fear of “overreacting.”
Most people don’t start off wanting to be toxic team-members. 99% of the time pulling someone to the side and mentioning that the joke they just made was a tad insensitive or that their comment during the meeting could have offended that intern can serve as the gentle nudge needed to make sure more significant problems don’t manifest down the line.
To conclude with a something Rabbi Yosef Yitzchak of Lubavitch was fond of saying: when you see someone lost in the middle of a forest, they never got there all at once, it always starts with taking one step off the straight path.
Let’s take care of our problems when they are small, before we find ourselves supporting the whole load with the donkey too!
Shabbat Shalom,
Yechiel
Comments