A. Using Vim makes you more productive ⌨️
B. This should be low-hanging fruit 🍇
C. Looks good on my screen 👨💻
Or suggest your own answer.
For further actions, you may consider blocking this person and/or reporting abuse
The trick is, write documentation with honesty, but read documentation with a healthy bit of reservation. Code lies less often.
😤
That's why I'm careful about WHAT I document. I try to keep it general enough so that refactoring and such won't affect the documentation. Easier said than done, mind you!
Michel, if you've got some tips on how you do this, it'd be great!
I'm not saying I'm working any miracles here, but I've rarely had people come back to me after taking over code I've written:
In separate documentation (e.g. Word document, whatever):
High-level explanation of the system, maybe down to the module level (depends on the application...)
Doing anything really weird? Explain the madness without getting too much into the implementation details. For a recent project, I was getting input from a query builder and generating and executing C# code on the fly (using Roslyn). There were some tricky parts and it's not obvious from just looking at the code, so I explained the flow of things.
In the code, I used to be big on comments, and I still write them, but less. That's after realizing they often went out of sync. So, variable and method names as descriptive as possible. No Hungarian notation garbage, no dropping the vowels in identifiers, etc. If something is weird or a workaround (sometimes to address a bug or shortcoming in a library or framework), then I'll document that. I just did that this morning for a workaround I had to do so something would display properly in a specific browser. That will save future generations from wasting time trying to do that tiny part the same way the rest is done.
I'm sure there's more, but as you can see it's nothing out of the ordinary. Just experience built over 31+ years of frustration doing this kind of work, for the most part. :D
A coworker just had four months of work tossed away because the other two developers on the team didn't want to upgrade their skills...
"Oh, it's too hard!" I don't know how many times we've been held 10-15 years back because of people like that. I also see that as a management failure to some extent.
(Note: No, it's not)
Oh no! That must've been demoralizing for your coworker...
No kidding. I wasn't too pleased myself. I've seen too much of that throughout my career...
Psssh,I don't need to test/debug.
I remember a friend of mine working with Vim and barely being able to follow what he was doing. He was THAT fast with it. It's not for everyone. I've tried it a few times, but I'm too used to modern luxury nowadays. :D I do use it on occasion when using SSH on a server, stuff like that, but only for very basic editing.
I use to care. Now I'm more of the "use what works for you, I'll use what works for me" type. Note that that doesn't stop me from checking out something I haven't used previously if someone suggests it as an option.
D) A Slack DM that starts with: "Quick question". It's never a quick question...
Just make it work. (The implication being to get it done as fast as possible without regard to intangibles like maintainability or architectural correctness.)
I used to work for that guy. :D
Oh, you work on computer ... Can you fix mine ?
Every family holiday...😩
I think like, all of the above.
The one that always gets me is
"Our priorities have changed"
That rarely means all the code you just wrote can still be used :)
looking at major changes in the code
Oh, it only takes a few minutes of your time.
Neil, really appreciate your thoughtfulness around each prompt. I can definitely see opportunities of improvement.
It was due yesterday, can you escalate it now?!