Found in 7 comments on Hacker News
iamsb · 2019-11-10 · Original thread
I used to be a boss like that. I thought people are always motivated to be better at their jobs. And that they are better at regulating their feelings. I was wildly wrong on both. Even though people learn that way, it is faster to impart learning by using slightly less confrontational approach. Specially if the relationship you are building is going to last more than a semester. I highly recommend reading to everyone. It helped me enormously to receive and give feedback in way which was conducive to build a feedback loop where people actively sought feedback on their work and received it with much more open mind.
vvanders · 2019-09-05 · Original thread
Thanks For The Feedback[1] is a pretty decent book on the subject. Highly recommended if you're interested both in the mechanisms and improving how you receive/give feedback.


afarrell · 2018-10-19 · Original thread
> I don’t know if this is impostor syndrome

It is a question worth asking. Our industry talks so much about impostor syndrome that people forget that there are other sources of lack-of-confidence.

I'm going to go through and try provide a clear vision of what challenges you are running into. Based on my interpretation, I'll then write out what are hopefully some clear actions to take or concrete questions to resolve. However, if you think Ive missed the mark in my interpretation, please let me know.

> joined...a month ago

Oh, so you're totally new then. Cool.

> all on the order of maybe a few hundred lines of code

Lines-of-code can be a proxy for the scope of a problem when you adjust for language expressiveness, but it is a very rough one. What I'm hearing here is that you're used to taking on projects for clients which are a fairly meaty bit of their business and require you to write whole features fairly quickly...but probably doing greenfield development. Modifying code that has been running for a while in an established organisation is a bit of a different beast.

> I’ve also spent maybe a week more than I should have on a fairly simple feature, just from fighting with my tools and trying to figure out where to put a few sparse calls in the codebase. It’s really embarrassing.

So I'm hearing a mix of frustration at your developer experience and disappointment in yourself for running into that frustration. I'm guessing that before you had a toolchain you were very fluent with and now you are...not. Okay, this is a problem to solve. Not as in "this is a problem with you", just "this is a problem you've got to deal with". Ideally, you deal with it by scoping out the pieces required to fix your development environment and tacking them as engineering challenges. This process will be significantly accelerated by asking well-framed questions of your coworkers who have the same sort of development environment. Julia Evans has a blog post on how to ask good questions which you should absolutely go read right now.

But some of your struggles with your development environment might apply to the lots of other folks and be the sort of thing that requires your team to do an investment project to solve that problem.

> Their thoughts are completely clear... I rarely hear them misunderstand anything

whoop whoop sampling bias alert! You cannot telepathically read anyone else's mind. However, you can read your own mind. But this perception of yours still comes from somewhere. Where then?

* I suspect your coworkers are probably reasonably concise and organised in their speech. This is a combination of a social skill, knowledge of the domain, and a willingness to wait to speak until you've organised your thoughts. The last one is a habit that depends somewhat on backbone. The former takes a combination of practice and

* I would be a very surprised if they never ask for clarification on anything. Indeed, the ability to notice that something is ambiguous and pin down reality is one of the most important communication skills for an engineer. However, there is a skill to expressing confusion confidently. You can pick up on it if you hear phrases like "could you clarify something for me...", "There is a point unresolved here..." or "so if I understand you correctly..." Are you sure that they aren't merely exercising the skill of projecting confidence while resolving confusion?

> In contrast my thoughts tend to be extremely muddled. I often take in information without making much sense of it at first

So when you check your intuition to see if you understand whats going on, it comes back saying "bwuhhhhh?"

Yup. Thats kinda how it goes when you're new somewhere.

When was the last time you had the experience of starting university or a bootcamp for the first time? If it was a while ago (or never happened), then you should keep in mind that it takes time to absorb information and it is normal for it to be overwhelmed a bit. I strongly advise spending two half-Saturdays watching all of the video lectures from the course Learning How To Learn. Don't be embarassed to use techniques from study bloggers like Thomas Frank -- Anki flashcards are in fact still super-useful for taking a mental model and cementing it. When you have a solid conceptual foundation, then the new info you take in will be "chunked" and will fit better in your working memory and won't be overwhelming. Also, for learning things and de-muddling your brain try going for a walk in a park, putting on some bluetooth headphones, and talking out loud explaining things to yourself. I find that I have a clearer grasp of things after I've dictated to

For now, work to be willing to re-read things or ask someone to repeat something that they just said.

> I’m riddled with anxiety every day. For one, I’m worried that my coworkers might think ...

The cure for this is clear feedback, received over time. There is a skill to getting it. The short explanation of how to do so is to be explicit that you are looking for feedback and to present specific questions in a [{situation} {action} {?effect?}] structure. For example: "When we were in the meeting to scope out the turtle-stacking API endpoint and I asked for clarification on tortoises, do you think that derailed the discussion?" Much like another question you ask, you might preface that with why you are asking. "I'm working to get better at concisely asking clarifying questions in technical discussions."

The key here is to give a voice to your concern, but in the tone you use to address a manageable question that you can rationally examine and then respond to -- because it is manageable. If you're doing something wrong but you concretely know what it is, you an solve it. If you're guessing at a problem, you won't have the certainty you need to commit to grow past it.

The longer explainations are found in this Lead Developer UK talk: and this book:

> I think I’m riddled with fear that I’m just not good enough to

The cure for this is to get an idea of the specific capabilities that your job expects of you. Ideally, your company has some sort of regular review process where you are asked to evaluate yourself against these specific capabilities. Ask your manager (whoever you do 1-on-1s with) what that process is and walk through those questions with them now rather than later. Then you can turn this vague fear that you are not 'good enough' into a specific fear that you can't do X well. Then you can get advise or resources on how to do X.

> I don’t really know how to reach out to people

There is a fairly large basket of skills here and I've got to rush off, so I'll just say that these skills are learnable and there are resources out there which I'm sure others are linking in this thread.

afarrell · 2018-05-08 · Original thread
> If what the OP said cannot be believed, even for the sake of argument, then there's no discussion to be had at all.


1) One can read a text with an eye toward the ways in which the narrator might be misinterpreting the situation and can hold in ones' head the possibility of that misinterpretation...while also making suggestions for how to grapple with the problem that the writer presents.

2) Taking as given the way OP presents their problem, you are correct that the co-founder is not acting in the best interests of the business. However, it is an unjustified leap to say that the co-founder does not care. There are a multitude of reasons why the co-founder could simultaneously care very deeply and be acting this way:

- The co-founder is mistaken on matters of fact about the problems.

- The co-founder is making a judgement call about maintaining product focus vs responding to customer requests...and making a mis-judgement

- The co-founder lacks skill at listening to and interpreting feedback[1].

- The co-founder is overcorrecting from making an opposite error previously in life/career.

- The co-founder is missing some other very important leadership skill.

Point is, it is possible for people to fail very badly and obnoxiously at something that they care a great deal about.


On second read, I think you might be using the phrase "does not care" in a way that isn't making sense to mean. Could you expand on what it means for someone to think they care about something but to not actually care about it?

[1] This is a skill. is a good book on it.

afarrell · 2018-04-04 · Original thread
> curt/cold/condescending

This is a rather broad and not very actionable criticism. Can you get more specific feedback? For example, something of the form "In situation X, you did/said Y, and that led me to think Z" is more actionable. Also, it is useful to pay attention to the classification problems that your engineer faces. There is a sometimes a balance between being condescending by giving someone info they already know and not providing enough context for an explanation.

The book "Thanks for the Feedback" [1] is a good read and Erika Carlson's talk[2] from Lead Developer UK is a good watch.



nmalaguti · 2016-09-02 · Original thread
Thanks for the Feedback: The Science and Art of Receiving Feedback Well by Douglas Stone and Sheila Heen.

I think it has made me a better teammate, mentor, and mentee.

If you'd like to know more before buying it, check out

zschuessler · 2016-01-03 · Original thread
The described sensitivity is easily related to by software engineers. It's often difficult to receive an annual review or feedback from code commits. It's a feeling of wanting feedback to continue growth, and fearing it due to sensitivity.

One book I've enjoyed which equips confidence is "Thanks for the Feedback." It's a book by Douglas Stone & Sheila Heen of the Harvard Negotiation Project.

Prepare to read one chapter every few days. It's a heavy read. Well written, it's an abundance of information: you may need to take time for brain rewiring as I did.

Amazon link:

Thanks for the Feedback -

Fresh book recommendations delivered straight to your inbox every Thursday.