DEV Community

Cover image for Top 5 DEV Comments from the Past Week
Peter Kim Frank for The DEV Team

Posted on

Top 5 DEV Comments from the Past Week

This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.

The I’m sorry, but this “Full Stack” meme makes me really mad/sad post and discussion is worth checking out in its entirety. @scotthannen offered the top comment in the thread (oh, and Chris Coyier just chimed in):

You didn't explain why you take it personally. I was looking for the part where you say that you or one of your friends is a full stack developer, but didn't see it. In other words, if there is an offense, who is the offended party?

What I instantly saw is that someone knows how to draw an entire horse, but they're much better at drawing one part of it than at drawing the other.

I see it more as making fun of what happens when the industry invents a useless, meaningless label and then pressures developers to identify with it.

The most fun I had was on a team where I would develop everything from the backend database and services to the front-end rendering and JavaScript. Then, right at the point where it came time to apply CSS I'd hand it off to people who were really good at it. We'd collaborate a lot on the front end, tweaking the HTML and behavior.

Pushing more on the front end improved my skills. I didn't become a JavaScript rock star but I wrote good, maintainable code. But if I did the whole thing myself it would look like the front of that horse.

In Thoughts on migrating to TypeScript and improving the overall quality of the frontend DEV codebase, @john_papa outlines a great approach:

I find one of the easiest and most comfortable ways to slide into TypeScript are to leave the current code base as-is and first add // @ts-check to the top of your JavaScript files inside of VS Code. This helps the editor treat your javascript with the typescript compiler. It will raise issues you may not known you had. This will not change the way your app runs, so it is a very low risk (no risk) way to start.

Second ... once comfortable ... I recommend adding new files as TypeScript. You'd likely want to create a tsconfig.json file and a tsc npm script to compile the typescript. But the code itself ... I like to start with the same coding styles I use in JavaScript. In other words, if you are using functions and constants and let/var ... continue doing so. Just add a little bit of typing and interfaces as you go.

What's the biggest hangup in typescript I see? One of the big ones I try to help folks with is avoiding the feeling that everything must be typed. any is ok. Embrace it when you start out. You can always get more specific later if it helps. Also, if the type can be implicitly determined, then don't explicitly type it. Here is an example ...

let name1: string  = 'john papa';

let name2 = 'john papa';
Enter fullscreen mode Exit fullscreen mode

Notice that the second one is still a string. We defined it as such. Why bother adding more code? More code is more to maintain and it can make code harder to read. Not buying it yet ... try this one ...

getSpeakers(): Observable<Speaker[]> {
    let speakers$: Observable<Speaker[]>;
    speakers$ = <Observable<Speaker[]>>this.http.get<Speaker[]>(speakersUrl);
    return speakers$;
Enter fullscreen mode Exit fullscreen mode

This could be much more readable like this ...

getSpeakers(): Observable<Speaker[]> {
    const speakers$ = this.http.get<Speaker[]>(speakersUrl);
    return speakers$;
Enter fullscreen mode Exit fullscreen mode

Thanks for indulging my stray thoughts :)

To comment or not to comment?, [that is the question]. @dbanty provides an answer by talking about the why vs. the how or what:

I find that comments are more useful for explaining why rather than how or what. Your code should be readable enough for people to know what it’s doing, but sometimes the reason isn’t obvious.

Like if you’re working around a limitation of a library you’re using. Or you’re working around some old code (technical debt) that you can’t refactor now. Yes I know ideally you’ll immediately fix all the problems in a codebase instead of working around them, but that’s not always realistic. So sometimes you need comments to make the code make sense.

Replying to Can I put small projects on github?, @perigk offers the perspective of an interviewer considering a candidate:

Absolutely do.

As a guy who has been on both sides of the table, in terms of interviewing, I would have positive feelings for someone who is doing small hacks during his free time.

Not that I dont like seeing big and impactful projects, but the passion and care for your job is irrelevant to size. I would care more about frequency (even though it is not the best metric per se).

Of course those are subjective...dont take things personally if someone doesnt like it.

The awesome Refactoring the Worst Code I’ve Ever Written article gave @jacobmgevans the opportunity to jump in with some encouragement and a clear reminder that we all have room to continue learning and improving:

I remember when you posted this code on Twitter unabashedly, which I SUPER respected. It showed people especially new up and comers that EVERYONE starts somewhere.

This is doubly awesome because it can show people YOU will IMPROVE 🙂🙂🙂

See you next week for more great comments ✌

Top comments (6)

peter profile image
Peter Kim Frank

Congrats to @scotthannen , @john_papa , @dbanty , @perigk , and @jacobmgevans for making the list this week!

john_papa profile image
John Papa

Thanks :)

dbanty profile image
Dylan Anthony • Edited

Thank you! I’ve received quite a warm welcome to this site since joining last week. I’m glad the Coding Blocks podcast led me here.

jacobmgevans profile image
Jacob Evans

I feel the same way. Loving the community here.

jacobmgevans profile image
Jacob Evans

Oh wow! Thanks! 😆😆

perigk profile image
Periklis Gkolias

Thank you 😁