January 05, 2016
From nczonline.net, with love.

Subscribe now

Bad vs. Different

Hi everyone,

It's hard for me to believe, but I've been working on web applications for over 15 years. Needless to say, I've seen and done a lot in my career, and as a result, I've developed approaches for how to solve and prevent different types of problems. If you've been working for more than a couple years, chances are that you too have started to form ideas about the best ways to do certain types of things. This is a natural part of the learning process and parts of why teams, rather than individuals, tend to make better software.

Eventually, your experience will lead you into more of a leadership position. That can take many forms, whether it be simply mentoring a junior engineer one-on-one, being the tech lead for a team, becoming a manager, or even becoming part of company leadership. In all of these cases, you'll start to run into people who have different ideas about the best approach. How you respond to these differences will affect how your career progresses from that point. I've seen many senior technical people stumble at this point, and it usually comes down to their need to be right.

I'm a big believer that a technical leader's role is to prevent the most egregious mistakes and otherwise let people do what they feel is right. Implicit in this statement is that people learn more by making their own mistakes so long as these mistakes are recoverable. And to make that determination, you need to ask yourself one question: is what they are suggesting bad or just different?

If something is "bad" that means it will be a big problem for an individual or a group. Attempting to rewrite all JavaScript code in your application by yourself is probably a bad idea; choosing to use ECMAScript 6 over ECMAScript 5 is different but not objectively bad. If something is subjectively bad, meaning you say, "ew gross" to yourself, then you should learn to label it as "different" rather than "bad" in your mind.

As I mentioned in my post on mentoring, as a leader, you don't want to create a bunch of you-clones who think and decide in the exact same way that you do. Instead, you want to encourage different ideas and experimentation, both because it is good for people to make their own mistakes and also because you are still capable of learning. Even after 15 years of web application development, I'm still learning new things, both from people with more experience than me and from people with less. The key is to be the mature person in a disagreement, decide if the other person is offering something bad or just different, and defer to the different whenever possible.

Be well.

-N

P.S. In case you weren't aware, I'm writing a new book on ECMAScript 6. You can read it for free as I'm writing it on Leanpub.
JavaScript WeeklySponsor: TrackJS
Fix Your JavaScript with Error Monitoring from TrackJS.

Recommended Links

JavaScript Fatigue (article)
As JavaScript frameworks have moved from walled gardens to microframeworks, are we losing some of what made JavaScript approachable to beginners? This article discusses the significant bootstrapping hurdle of React for new developers and shows how we may be leaving some developers behind. The more we rely on tooling and people understanding how things are supposed to work together, the more opportunity for developers to do the wrong thing.

express-service (project)
Not too long ago, I talked about how service workers would be a paradigm-changing addition to the web platform. This project implements the popular Node.js framework Express inside of a service worker. It's just an experiment, but it shows some more of the potential of service workers: what if you could deploy your server-side Node.js application to the browser? Really interesting.

Developers are the new superpower: Matter (article)
This article is really two in one. First, it's a nice overview of the web standards process and how things like HTML won over more-established standards. Second, it discusses the W3C TAG and its importance to the development of new standards as a group of developers who remain in-tune with the development community and help guide standards discussions (there's also a shout-out for the author's favorite candidate to join the TAG).

Recommended Book

Social skills are important even for software engineers, and How to Talk to Anyone is one of the books I recommend most often on this topic. The title is a bit misleading, because it's much more about all kinds of interactions (including talking). I first read this book several years ago and I still find myself echoing back some of the lessons. My favorite is how asking yourself, "what would a big shot do in this situation?" can lead to better decision making in all kinds of situations. If you're interested in learning more about social interaction and how to get interact more effectively with people, this is a book that should be on your reading list.

Recently on NCZOnline

Why I'm not using your open source project
When you think of open source software, you might think of a few specific projects depending on your area of interest. If you work on web applications, the term "open source" might conjure up visions of Apache or Node.js; if you're into big data, then perhaps Hadoop comes to mind; if you care a lot...

Hidden performance implications of Object.defineProperty()
I've recently been working on a project to port Espree[1], the parser that powers ESLint[2], to use Acorn[3]. In so doing, I ran into an interesting performance problem related Object.defineProperty(). It seems that any call to Object.defineProperty() has a nontrivial negative affect on performance in V8 (both Node.js and Chrome). An investigation led to some...

ECMAScript 6 destructuring gotcha
With all of the new syntax in ECMAScript 6, you're bound to periodically find something that is confusing (likely as you're hunting down an error). Recently, I've seen an uptick in the reporting of a specific type of error as it relates to destructuring assignment[1] using object patterns. Destructuring basics Before you can understand the...

Feedback

Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.
Copyright © 2016 Nicholas C. Zakas, All rights reserved.


unsubscribe from this list    update subscription preferences