A personal post-mortem on almost giving very misleading advice

I recently had someone ask me what I felt helped me grow the most in my first few years working as a software engineer. Upon them asking me this, I initially drafted an answer that looked something like the following:

A combination of building systems and seeing how they failed and then reading lots of code and books including: (list of programming books I’ve read).

However, upon writing this – and before sending it thankfully – I realized I was almost entirely misrepresenting the things that actually helped me grow. Building things and seeing how they broke was genuinely a huge factor, but, despite reading lots of programming books during my first few years as a software engineer, I think they played a relatively minor role in my growth (because books don’t work). Also, I (along with Kartik) wrote an entire post about how nobody actually reads code like a book, so clearly I wasn’t doing that much. Instead, I ended up writing a longer message which, in addition to building things, pointed to the following factors as encouraging my growth:

• Getting really lucky that a few senior people with high standards and different ways of thinking invested in my growth. I emphasized how being able to ask these people tons of questions, pairing with them on coding, and listening to them digress and complain about random programming things all helped me a ton.
• Procrastinating on real work by refactoring lots of stuff, sometimes unnecessarily.
• Making silly mistakes and seeing how they later came back to bite us.
• Being a person who likes to complain but then getting called on my tendency to BS and having to justify the things I was complaining about.
• Having rabbit hole-y debates in person and on code reviews with super detail oriented people who you’d have to spend a long time convincing of things.
• Practicing for coding interviews a lot so I’d be prepared when I went job searching (this is after all what helped me get a second job).
• Having the type of personality that gets really obsessed with theories of everything but then becoming disillusioned with each theory I’d temporarily adopt. (I went through phases of “OO is the best”, “make all the things functional style”, “microservices, yay!”, etc.)

Why’d I almost give bad advice? #

Realizing how I’d almost just given incredibly misleading advice led me to reflect on how, even though I’m aware of most advice being bad, I’d still come close to horribly misrepresenting my career growth.

Reflecting on this further, I’ve identified a few factors which I think contributed to me almost misrepresenting my career growth history:

• Social desirability bias
• Formal, legible activities being easier to remember
• My own insecurities influencing the advice I was willing to share
• Desire to self-validate
• Jumping to the first answer that came to mind (1) (1)An additional idea suggested by Matt Ritter is that I just have no idea what factors contributed to my growth and therefore that giving advice is hopeless in the first place. I’m skeptical or at least hopeful that this isn’t the case but it seemed worth mentioning as an additional hypothesis.

Social desirability bias is “the tendency of respondents to answer questions in a manner that will be viewed favorably by others.” In this case, I know that reading books and reading code are viewed as virtuous whereas getting lucky with mentors, procrastinating on work, and making silly mistakes are not, so I was tempted to emphasize the former even though they played a relatively minor role. What frightens me about this is that I felt such a strong temptation even though I was giving private advice to a single person! To give another example, having digressing discussions with mentors about the nuances of blub study topics like when one should use streams in Java sounds much lamer than saying I took a coursera course on functional programming in Scala, even though I forgot everything from the Scala course but have heavily benefited from Java streams. Like in many arenas, when giving advice, social desirability bias pushes us to say what we think will make us sound good rather than the truth.

When I use the term legibility in this context, I’m drawing a distinction between activities which can provide clear measures of progress vs. not having an easy progression one can track. Reading books is legible under this definition because it’s easy to track how many books one’s read and log them in Goodreads. (2) (2)Ignore that, for someone like me who likes seeing numbers go up, doing this leads to Goodhart-ing against the metric. On the other hand, amount learned from code review and debates in meetings is very illegible. These discussions and threads are often adhoc and vary widely in their usefulness, making tracking of them silly. As a result, when remembering “what things helped me learn” it’s much easier to tally up books read rather than reflect on how replying to John Smith on a random code review ended up forcing me to really understand how Python’s global interpreter lock makes it so that the threading implementation I wrote to parallelize a CPU-heavy operation makes no sense or how really wanting to own Joe Schmoe in a design discussion forced me to spend hours really figuring out why I wanted us to use DynamoDB. Overall, a focus on legible things led me to initially emphasize easy to categorize and measure factors at the cost of the fuzzier factors that actually played a larger role.

As evidenced by previous writing, I have some insecurity about whether I’m a good doer but an average thinker. In the advice-giving context, this combined with my insecurity about not finishing things seemingly pushed me to want to emphasize books I’d read (and completed) rather than things I’d actually done or mistakes I’d made due to initially (perhaps) rushing and then coming back to things. In fact, while writing this paragraph, I noticed that, even after revising the advice I gave, I failed to include how learning to do things quickly sped up my growth by enabling me to be exposed to more things.

While I don’t think this played a massive role in my near miss, the desire to self-validate is a common enough advice corrupter that I wanted to mention it. In my case, a desire to self-validate might push me to want to validate my decision to spend a lot of time reading books by viewing at as helpful in hindsight even if in reality the reading really didn’t help me improve very much. Another very common example of self-validation which I didn’t include here but feel obligated to include because it’s so pervasive is telling someone they have to go through some long, difficult hazing ritualexperience because you did and want to make yourself feel better about the toll it took on your (generating examples left as an exercise for the reader).

As has been written about extensively, our first thoughts are often not our best thoughts, yet advice is often given in off-the-cuff settings with limited preparation. In this case, although the conversation was all via text, my initial answer was basically the first thing that came to mind, leading to it being influenced more strongly by the above factors.

How to improve… #

In which I go super meta and give advice about giving & taking advice despite just telling you about how I almost gave terrible advice.

Unsurprisingly given the last post I contributed to, I’m a big believer that one’s choices and decisions in life matter. While luck plays a role and the future is not entirely predictable, I am ultimately a definite optimist in my outlook on careers. For this reason, I’m frightened by the fact that I almost contributed to the epidemic of bad advice and am determined to avoid this in the future.

While I haven’t totally figured concrete steps I can take to avoid giving bad advice, I do have a few ideas (meta-idea: actually use this checklist):

1. Whenever possible, follow a policy of insisting on spending time thinking before responding to requests for advice. Related to this, force myself to generate lots of ideas before whittling them down. Although I don’t have strong evidence of this, I suspect that not giving kneejerk answers is a key meta-strategy for improving advice quality because knee jerk answers tend to be cached thoughts, which in the realm of advice giving, will be the least novel, most socially desirable, legible answers.
2. Make being willing to give honest but low status advice (when applicable) part of my identity. I already have “be willing to argue for low status or contrarian opinions” as part of my identity so expanding this to advice will hopefully be relatively easy for me.
3. Keep a career journal and actually revisit it before giving advice based on periods of one’s career. Note that in order to be maximally useful, this journal should focus on documenting what I did and my view on it at the time rather than letting myself develop warped views in hindsight¹. Even better, blog about it!
4. Be willing to not give advice if I don’t feel like I know what I’m talking about! (I am proud to report I kind of did this recently.)

Given how important this is to me, I’ll be very appreciative if anyone is willing to share (either privately or in the comments) either:

• ideas they have for dealing with these challenges, or
• experiences they’ve had giving (good or bad) advice and the challenges they faced in keeping theirself honest.

Acknowledgements #

Leopold Aschenbrenner, Matt Ritter, Alexey Guzey, and Jennifer Dalecki for reviewing this post and suggesting improvements.