loading...

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

 

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

 

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.

 
 
 

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

 
 

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?!

Classic DEV Post from Jun 15 '17

Share Your Experiences with Impostor Syndrome

I'm currently prepping a talk called Overcoming Impostor Syndrome for a develop...

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