loading...
Cover image for Top 5 DEV Comments from the Past Week
The DEV Team

Top 5 DEV Comments from the Past Week

peter profile image Peter Kim Frank ・1 min read

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.

I'm a huge fan of these #meta conversations happening on DEV, instead of isolated in GitHub issues. In the What would your opinion be of a "reading position" indicator on DEV? @cjbrooks12 offers their thoughts:

I usually find them unnecessary at best, and distracting at worst. Having the "reading time" listed at the top of the article here is enough to give me a sense of how long the article is. But some people really like having them, so maybe there could be a setting for users to turn it on/off per their personal preferences?

I think the reason I don't care for a generic progress bar is that it doesn't really give me meaningful information about my reading progress. I might be halfway through the text of an article, but how much of the remaining article is code snippets, interactive examples, videos, prose, conclusion, etc? The actual progress of me getting through the article may be massively skewed by things that aren't raw text, and so it tends to feel quite arbitrary, generally-speaking.

A better measure of progress might be to enumerate the Headers in the article content, and highlight progress by which headers I've passed. A good example of this is the right-side menu of the Android docs. Seeing that I've got 2 content sections, an example, and a conclusion left until I finish the article is much more meaningful than some arbitrary measure of text. In addition, it allows me to skip directly to a specific section on the page.

Replying to You Probably Don't Need A Front End Framework, @mattwaler offers some nuanced opinions which sparked more productive conversation in the comments:

I understand the point of this article and agree, you should not simply choose a FE framework just because everybody else is.

However, I think you glossed over the fact that by replacing frontend frameworks with SSR you lose static hosting, preloading, perceived site speed to the end user, and many other possibilities.

Don't get me wrong, SSR is still great and has plenty of great use cases.

What you end up building seems like an SSR framework, like Ember, but without great developer tools, documentation, and community support that a framework provides.

I think frameworks can be overused or used for the wrong purposes, but it is always a great idea to use tried-and-true frameworks so you are not rebuilding the wheel.

Answering What is the hardest part of your job?, @molly_struve talks about the challenge and importance of leading a team:

I recently became a technical lead and now I have a team of 2 that I am responsible for. At first, I assumed that I, plus 2 more people meant that we would get 3x as much work done as before and it would be a piece of cake. Oh boy, how wrong I was! Leading a team is HARD WORK! Figuring out exactly how much support each member needs and how to best give it to them while also continuing to technically contribute myself is tough. I have had to accept that contributing less is OK because my time is better spent sharing my knowledge and helping others on my team grow.

TL;DR The hardest part of my job is learning how to effectively lead a team.

I believe this is the first comment from a #challenge thread to be a Top 5 Comment, but it was worth the wait. In Daily Challenge #43 - Boardgame Fight Resolver @alvaromontoro offers up a CSS-based solution that turned some heads:

CSS

Add the attributes data-piece1 and data-piece2 to any element, and it will announce the winner:

[data-piece1][data-piece2]::before {
  content: attr(data-piece1) ' vs ' attr(data-piece2) ': ';
}

/* By default, piece 1 will win */
[data-piece1][data-piece2]::after {
  content: attr(data-piece1) ' wins!';
}

/* Only in some particular cases, piece 2 will win */
[data-piece2="archers"i][data-piece1="swordsmen"i]::after,
[data-piece2="swordsmen"i][data-piece1="pikemen"i]::after,
[data-piece2="pikemen"i][data-piece1="cavalry"i]::after,
[data-piece2="cavalry"i][data-piece1="archers"i]::after { 
  content: attr(data-piece2) ' wins!'
}

In CSS Selectors Level 4, there is an option to make some selectors case-insensitive (adding an i at the end as displayed above). And it is fairly well supported (haven't tried on IE). So it doesn't matter if the user writes "archers" or "Archers" or "aRcHeRs", all of them will be matched.

Finally, chiming into the [Ask Dev] Is Slack disruptive at work? thread, @neilonsoftware talks disruption, synchronous v. async, and their tactics for staying focused and establishing team communication channels:

I think it is disruptive and hostile to doing deep, focused work.

It is by design: it is meant to interrupt you from whatever you are doing so that you can provide an immediate answer to any question no matter how inane. Being in constant contact over chat will simply prevent you from doing deep work, and ruin your productivity as a software developer. This is a well-understood phenomenon, but there seems to be no industry-wide consensus on what to do about it. We want to be able to jerk the leash of an employee anytime we want, but we also what high quality work produced quickly. I don't believe you can achieve both in a field where productivity is constrained by cognitive efficiency.

My personal strategy has been highly effective, and nowhere near as controversial as you might think it would be in practice. In the morning I answer any questions for me over chat, then I send out a group message that says, "I'm going offline. If you need me send a text message to my phone number and I'll hop back online." I always kept this promise with no exceptions, so I was always easily reachable. I suspect people regarded a text message to my personal phone number more intimate than a chat message, so they did it far less often. This strategy ended up being so effective, that management ended up endorsing this practice, as its value was highly visible: I produced a far higher than average amount of work at near-perfect quality.

FWIW, on my Developer Class Quiz Results, I am 100% Ghost.

See you next week for more great comments ✌

Posted on by:

peter profile

Peter Kim Frank

@peter

Doing a bit of everything at DEV.

The DEV Team

The team behind this very platform. 😄

Discussion

markdown guide
 
 

Thanks!
I hope it's just the first challenge comment of many more making the list :D