ISBN: 9781101614273
Buy on Amazon[1] https://www.amazon.com/Thanks-Feedback-Science-Receiving-Wel...
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. https://jvns.ca/blog/good-questions/
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 https://otter.ai
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: https://www.youtube.com/watch?v=RsfNS9HSWQs and this book: https://www.amazon.co.uk/Thanks-Feedback-Science-Receiving-W...
> 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.
Disagree.
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. https://www.amazon.co.uk/Thanks-Feedback-Science-Receiving-W... is a good book on it.
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.
[1] https://www.amazon.co.uk/Thanks-Feedback-Science-Receiving-W...
I think it has made me a better teammate, mentor, and mentee.
If you'd like to know more before buying it, check out http://www.npr.org/2015/09/22/434597124/trying-to-change-or-...
https://www.amazon.com/Thanks-Feedback-Science-Receiving-Wel...
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 - http://www.amazon.com/Thanks-Feedback-Science-Receiving-Well...
Lots of discussions on where feedback might come from, what are the types of feedback (praise vs coaching vs evaluation), and how to incorporate (if needed)
I also want to echo the top comment here re:kudos on desire to improve