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.

Replying to What's new in browser support?, @mjsarfatti talks about something that blew a few minds:

Manuele J Sarfatti • Dec 2 '19

It’s not properly new but I've recently found out about:

@media (pointer: coarse) {
  // touch device (finger)
}

@media (pointer: fine) {
  // touch device (stylus)
}

</div>

@evanplaice offered a great write-up in response to Explain full stack developer to me like I'm five:

Evan Plaice • Nov 27 '19 • Edited

Think of a restaurant. You have greeters (CDNs) and hostesses (reverse proxies) to direct customers (users) to their seats.

When they get there there are servers (FrontEnd Devs) who provide the customers a pleasurable experience (UX) as well as eserve them food (data).

In the back you have cooks (BackEnd Devs) doing prep work, dishwashers (SREs) making sure everything is clean and ready, as well as Kitchen Managers (DevOps) to ensure everything in the back is setup to run smoothly.

SPAs operate like a buffet in that they leave more work for the customers to do themselves and put more emphasis on the FrontEnd.

Where do FullStack devs fit in. They're the restaurant managers. They can fit into -- and accel at -- any role b/c they have likely worked in every role at one point or another.

It takes a lot of work to get good enough to be a FullStack dev. So much so that some other types of devs deny that they even exist.

The truth is, the hardest part about becoming a legit FullStack dev is pushing back against your employer so they don't keep you pigeonholed into a very narrow role.

Many devs are perfectly happy to get paid a lot to work a narrowly defined role. Pursuing FullStack is the hard path and the sacrifice in time/effort to get there may not be worth it.

Like every restaurant wants a badass restaurant manager like Gordon Ramsey, companies would really love to have badass FullStack devs on their team.

But! Very few companies will invest the time and resources to raise a dev to that level.

FullStack devs have a lot more freedom to migrate elsewhere if the work conditions are bad and they're very difficult and costly to replace.

FullStack devs have the capability to raise everybody up. But companies don't want to raise devs up to FullStack status.

@ahferroin7 hopped in to the New browser on the block! thread to share some thoughts on the potential impact of this new entrant:

Austin S. Hemmelgarn • Nov 29 '19

I think having another browser using SpiderMonkey that isn't Gecko-based (assuming they really did start from scratch on the rest of the browser) will be good for the JS ecosystem as it applies to the web (especially since Chakra is probably going away and almost everything except Firefox and Safari is using V8).

Whether having another HTML/CSS engine will be a good thing remains to be seen. They're going to have to get a lot of market share for it to even matter what they do that isn't copying WebKit, Blink, or Gecko (for example, pretty much nobody on the development side cares about Pale Moon even though they've diverged (a lot in some cases) from Gecko).

Either way, until we see actual code or even just a build, it's hard to say.

The Celebrating 10,000+ stars on GitHub together! ⭐ ❤️️ was a fun reflection thread on hitting a major milestone for any open-source project. @andrewbastin shares their experience as a contributor:

Comment Not Found

Finally, @jmfayard adds some additional thoughts to the Philosophy of a Good Developer:

Jean-Michel (jmfayard.dev) • Nov 28 '19 • Edited

you make a lot of good points
I especially agree with 1) no blame game 2) look at the bigger picture 3) thinking about others 4) write stuff down.

I have some caveats, but they probably only mean the we work in different contexts

when writing things down for yourself - as opposed to for the team-, I would recommend to use pen and paper instead of yet another app.
I treat comments as code smells. if my code does not speak for itself, I should make it simpler instead of adding soon to be obsolete comments. if something needs to be documented, then in the team wiki or issue tracker, not in the code
I don't agree with the no shortcut rule. I choose the simplest way to solve today the problems that I have today, and I'm a big fan of waiting for future problems to materialize instead of fixing them preemptively

See you next week for more great comments ✌