When I was younger and dumber, I charged pretty hard. Sometimes I would upset people by pushing too hard for an end result. I didn't consider how my actions would affect people around me. Back then the damage I did was usually a small, though still unacceptable, as I was junior cog in the machine.

These days, I am in senior positions with responsibility for the output of junior developers. The team's collective output depends on everyone having high morale and the confidence to take risks, make mistakes, and learn continuously.

Young Hugh's hard-charging ways weren't acceptable then, and they would be devastating if applied from a senior position.

Of course, I often copped it as good as I gave it. I have painful memories of senior people shitting on my best efforts. It's an awful feeling to have tried hard to find a creative solution to a problem, only to be brutally shut down by someone in a position of power.

This effect is amplified by people's relative tolerance for feedback. Some people have high self-confidence, and are generally better able to recover from the morale hit of harsh feedback. Others are gentler souls, very sensitive to criticism and vulnerable to retreating from creative development in the face of harsh feedback.

You won't necessarily know who's who. Some of your developers might look like they can roll with the punches, but are quietly de-motivated to work with you. Personally I think I give off a confident persona: I will get up on stage to give a speech, post stupid videos, and put my hand up first to take on a big challenge. Yet I have cried openly in front of colleagues, on multiple occasions.

Conclusion: We should take great care in how we offer feedback to our colleagues. In particular, junior developers who are at a formative stage in their code-crushing adventure. I don't have an all-conquering strategy about how to best give feedback.

To provoke discussion, I present an email I sent earlier today. The content is esoteric to the particular project, so we'll have to ignore that and instead focus on the style of the feedback. How does this make the recipient feel?

Hi [Junior Colleague]!

I’ve made some adjustments to the FAQ page, and I’ve got some feedback on your code. This is not because you did anything wrong. You did great! Instead, it’s about me applying a consistent set of code rules to the [App] codebase, that allow me to keep the whole thing straight in my head.

What I’m doing here is not necessarily better or worse than what you did. Instead, it’s just my style. Because I need to maintain responsibility for the whole app, I need to enforce my style or I my mental map of the whole app can break down.

Moral of the story: Do what you need to do to get the job done. Sometimes I might come in with feedback like this, but it’s not because you did anything wrong. In fact, you did right because you got the required feature working! I will always be thrilled when you add functionality, regardless of whether or not it adheres to these rules.

CSS Namespacing

Good job creating accordion.css. I’ve plopped it in shared/accordian.css simply for organisational purposes. Inside, ensure all your classes are namespaced: .accordion-active instead of .active, .accordian-panel instead of .panel. Doing so means we never have to worry about conflicts between different stylesheets, we can mix and match them safely. You did this for almost all the classes, nice work!

Inline Javascript

Ensure all Javascript is added via the View superclass, rather than inline in an HTML template. I’ve moved things into a scripts/other/faq.js script and classes/shared/accordian.js class. The View superclass does a whole bunch of Javascript management, and it can’t work its magic if Javascript is inline in an HTML template.

Javascript Variables

Never use var - It puts the variable in global scope. Using let and const means that we can safely mix and match classes and scripts without them ever stepping on each others toes. Generally everything should be const unless there is an extremely compelling reason to use a let.

Javascript Objects

Err on the side of object-oriented code, rather than procedural code. Procedural code is generally identifiable as a series of steps manipulating low-level datatypes like DOM elements and strings. Object oriented code usually (if done well!) looks a little more like English, with phrases composed of high-level types like ‘Accordian’.

Generating object-oriented code might involve creating a mental map of the nouns you want in play, and the verbs that will act on those nouns. Nouns become classes and verbs become methods.

E.g. “I want to toggle the open state of a bunch of accordions”. Our key noun is “accordian”: That will become our class. It has an open state that it will stored as an internally/private property. The key verb is is “toggle”: That will become our class method. Because we want a “bunch” of them, we will create a static class method that allows us to build a collection of Accordians.

This means you can compose code that sounds more like English, e.g. “accordian.toggle();” or “const accordions = Accordian.fromElementsWithClassName(’accordian');". I find this easier to maintain when I inevitably come to look at it again months later.

Doesn’t make any sense? Don’t fret! I’m not necessarily a very good teacher! You can see how your accordian code was translated by looking at classes/shared/accordian.js. Please feel free to charge some time to [Client] while looking through this stuff. Learning is part of the job!

Conclusion

You did nothing wrong, and everything right. This is all about the personal style I’m enforcing so I can execute my responsibility to advance the entire application. Other developers will have other styles, you will have your own style. I will always be thrilled with you create new functionality, regardless of what style you use.

Cheers

Hugh

How was that? What would you change? I think this email follows a few feedback patterns:

• Acknowledge successes
• Encourage future experimentation
• Give reasoning behind desired changes
• Provide helpful hints for gaining knowledge

These patterns are self developed, and self identified. I wonder if you know of any great guides on how to give good feedback. Do you have any stories you can share about when giving or receiving feedback went well, or badly?

Hugh