What I hate hearing most as a developer.

twitter logo github logo ・1 min read

Dev cards (14 Part Series)

1) My favorite swag from tech conferences are ______ 2) Bane of my existence as a developer 3 ... 12 3) _____ does not Spark Joy, thank it and discard it. 4) Friends don’t let friends ____ on a Friday afternoon. 5) git commit -m "_____" 6) I got to the bottom of an infinitely scrolling website and found 7) A misunderstanding of ______ brought down all of the Internet 8) Trust me, I can build software because I learned how to code from ___ 9) What I hate hearing most as a developer. 10) ___ as a Service 11) Steve Jobs & Steve Wozniak is to Apple as ___ is to ___ 12) It's going to take ___ to finish that task. 13) Cool, just send me a copy of the code on ___ 14) The best thing about my job is ___

Alt Text

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.

twitter logo DISCUSS (23)
markdown guide
 

I don't need to write documentation, just look at the code

 

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

 

I wouldn't "hate" any of these, as they all represent opportunities for improvement:

Using Vim makes you more productive

I need to verify if this is valid and if not persuade them to use better tools.

This should be low-hanging fruit

I need to verify if this is true and if it is not persuade them to focus on higher-priority work.

Looks good on my screen

Assuming this is true, and assuming it does not look good on other screens, I need to persuade them to expand their perception of what they are responsible for.

 

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.

 

Neil, really appreciate your thoughtfulness around each prompt. I can definitely see opportunities of improvement.

 

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...

 
 
 

Just make it work. (The implication being to get it done as fast as possible without regard to intangibles like maintainability or architectural correctness.)

 
 
 

D) A Slack DM that starts with: "Quick question". It's never a quick question...

 
 

looking at major changes in the code

Oh, it only takes a few minutes of your time.

 

The one that always gets me is

"Our priorities have changed"

That rarely means all the code you just wrote can still be used :)

 
Classic DEV Post from Dec 22 '18

The 10 most popular dev.to posts of 2018

I took the 10 most popular posts in the year section of dev.to and added some t...

Michael Lee πŸ• profile image
Maker of things, giver of high-fives πŸ–

DEV is where senior developers are built

Sign up (for free)