|
|
|
|
|
by JohnMakin
514 days ago
|
|
His strategy for Russian language was sort of how I approached math in college when it started getting difficult and more abstract - I found that when I wrote in pencil, I would frequently make mistakes because of all the erasing and scratching out and going too quickly. So I started showing up to exams with only a pen - forcing me to sit and think very carefully about whatever I was about to write, and if I couldn't manage to do that, would force me to keep an 'extra' scratch piece of paper where I could be sloppier. My grades transformed instantly. I don't really approach code this way, but I do prefer to fully think through a problem before I begin banging it out. This has upsides and downsides. Honestly though, I am very wary of anyone in tech that says something "absolutely" has to be done a certain way. An example - I have a convention with executable convenience scripts where I will label them per environment, in the naming of the file, and separate them by directory that way. It often gets pointed or yelled at me about "DRY" being violated, and now I have to maintain 3 separate sources of these, etc., when I could simply have a parameter I pass in to do the same thing. That would make it "productionalized", why all this repeat code everywhere??? Well, yea, I could. But, knowing me and how long I've done certain things, it's stupid easy to forget in the moment when you're tired or distracted what you are doing and where and do the wrong thing in the wrong place - which can be a total disaster that far outweighs whatever I am gaining from DRY principles. I find the better engineers I work with aren't so strictly rigid with their thinking and tend to do the same types of cost/benefit/risk analysis to whatever approach they choose. |
|