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.
Michael Lee 🍕 @michael
About: Maker of things, giver of high-fives 🖐
Location:
Cary, NC
Joined:
Apr 14, 2017
What I hate hearing most as a developer.
Publish Date: Aug 19 '19
7 23Comments 23 total
Pierre BouillonAug 19, 2019
Michel RenaudAug 20, 2019That'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 RenaudAug 20, 2019
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
Robin PalotaiAug 19, 2019The trick is, write documentation with honesty, but read documentation with a healthy bit of reservation. Code lies less often.
Daniel MochAug 19, 2019Just make it work. (The implication being to get it done as fast as possible without regard to intangibles like maintainability or architectural correctness.)
popcornthadAug 19, 2019looking at major changes in the code
Oh, it only takes a few minutes of your time.
Peter WithamAug 19, 2019The one that always gets me is
"Our priorities have changed"
That rarely means all the code you just wrote can still be used :)
Christopher LaiAug 19, 2019D) A Slack DM that starts with: "Quick question". It's never a quick question...
- Michel RenaudAug 20, 2019
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.
- Michel RenaudAug 20, 2019
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)
- Michel RenaudAug 20, 2019
No kidding. I wasn't too pleased myself. I've seen too much of that throughout my career...
- Michael Lee 🍕Aug 20, 2019
Neil, really appreciate your thoughtfulness around each prompt. I can definitely see opportunities of improvement.