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:

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 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)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 hindsight1. 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:

Acknowledgements #

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

  1. Hat tip to Justin Yan for giving me this idea. ↩︎