Top 5 DEV Comments from the Past Week

#bestofdev

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):

Scott Hannen • Apr 17 '19

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:

John Papa • Apr 17 '19

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';

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$;
  }

This could be much more readable like this ...

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

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:

Dylan Anthony • Apr 21 '19

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:

Periklis Gkolias • Apr 20 '19

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:

Jacob Evans • Apr 18 '19

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 ✌