> Like a lot of soft skills, we’re rarely taught how to mentor
^ This is one of the first lines in the article. If I had to guess I'd say most people here spend a relatively small amount of time learning about how to do their job vs actually doing it.
For me this is a good reminder that actively/intentionally investing a couple hours per week in learning about how to do things - technical or not - and evaluating myself will probably have a higher ROI than spending those hours doing the thing
This reminds me of some of the ideas discussed in this post [0] from a few days ago.
Indeed. I've known many people that, if given 1000 hours to cut down a tree would spend 4 hours sharpening the axe, 500 hours watching YouTube tutorials on cutting down trees, 300 hours on axe reviews, and 195 hours arguing online about how to do it.
I can't get it done without numerous trips to Home Depot. At least one of those trips will be immediately after another, to buy what I was supposed to buy on the first trip, but where the first trip ended with me picking up a lot of other things.
Why spend 5 hours cutting down a tree with an axe when I can spend weeks buying and learning to use a feller buncher incase I need to cutdown lots of trees in the future.
i really enjoy this motto, personally; especially since i have taken up the hobby of handtool woodworking for the last few years. i decided that i would invest time in learning to sharpen and maintain tools before i did much work with wood and for me that has paid huge dividends. working with keen tools vs. dull ones is night and day. but i was working on my own time : )
all that said, i completely agree with you that this is not a good motto for a novice at work -- if you are capable at handling an axe, having it razor sharp is going to markedly improve your results, but if it's your first go at swinging an axe, i really hope you don't spend 80% of your time fiddling with a sharpening stone…
That's where the metaphor breaks down (while the intended idea stands perfectly fine), the reason you don't want to waste time making your axe perfectly sharp is that you must learn how to use it first, not because you should just forget about it and go chopping trees.
It has some parallels to most skills, as most times you will only discover your deficiencies by doing it. But it doesn't mean you shouldn't train, it only means that training without ever practicing won't lead you anywhere.
Well, taking a regular break to sharpen your axe, every half hour or after every tree, then you only spend a minute to save five minutes.[1] This is like running tests, or asking questions about what you have done recently to maintain focus on the bigger picture. Or to prevent a commit from getting too big. Or refactoring.
And sharpening a dull axe can take an hour to half a day. [2]
Sorry for the off-topic comment here but I cant help but tell you that your username reminds me of a user who posted on a couple gaming forums I used to frequent in the early 2000s.
This desire might be higher for me because I've been working independently for a few years, but I would pay gladly pay many dollars in dues to a community built around technical skills development where members are expected to both learn and mentor.
exercism.org (formerly .io) is a community encouraged to both learn and mentor. I'm not affiliated, just a user who has drifted into and out of the community in both roles over the years.
There should be another article on how to find a mentor. Half the time I’m aping things that were done for me ten+ years prior, from a mix of agreement, lack of better ideas, or finally figuring out what they were trying to tell me/didn’t tell me.
Spend as much time as you can working around really good programmers. You'll unconsciously pick up their patterns of thinking and coding. It's almost like a telepathic transfer that takes place even if they aren't actively teaching or mentoring you.
In some fewer words I would say that the force of mentorship should not exceed the strength of pushing a canoe into a river.
You're not there to set hurdles. You're there to recognize when someone is fighting the upstream flow or have embanked themselves in temporary enlightenment.
I disagree with the definition of the mentoring and coaching from the article.
Maybe the author definition is from sports, but outside it here is how I see (and how many of people that I encountered so far see) the difference between coach and mentor:
In a coaching relationship the coache sets the agenda not the coach. The coach is more backseat than a mentor. The coach is there to walk along the coachee on the coachee path while providing guidance when asked, usually in the form of guiding questions or helping navigate various points of views or helping go through decision frameworks.
In a mentor relationship the mentor sets the agenda together with the mentee. A mentor has a more active role in the agenda providing active guidance and feedforward. The mentor and the mentee walk together on a path they both agreed on.
As an example:
If I would go to a coach and say ask about should I learn Elixir or not taking into consideration my Ruby background, then the coach will not answer yes or not. But should help me discover for myself the answer. It will usually help me look at this question from various points of view or can provide a decision framework, but the answers (or the content of my answers) will always be mine or my own discovery. So they will not state "Elixir is like Ruby" or "Elixir is not like Ruby" but they might ask "How can you assess if Elixir is like Ruby?" or "What is the smallest project that you can create to see if you like Elixir".
If I would go to a mentor and ask about should I learn Elixir I expect them to tell me pro and cons of Elixir and also have an opinion about if Elixir is really similar with Ruby or not and even express their preference for this programming language or the other.
So I choose to go to a mentor or coach depending on what outcome I want to have and what experience they have.
PS: Please take the Elixir and Ruby just as an example of a technical matter to be discussed with a coach or mentor.
The terms are used so interchangeably by people that I'm not surprised you might disagree. I looked at a bunch of definitions and tried to distill a useful distinction.
Given that people hire coaches, but usually not mentors, the distinction for me is that a coach is engaged towards a goal and therefore is more directive of what you need to do to get there.
I don't think your example question is a great one for exploring the distinction because it's a single, binary question. But even in your example, despite the coach responding with questions, you describe the coach as pushing you to go do some work: figure out the differences yourself, or come up with a project to explore the question.
In that sense, I see the coach as "setting the agenda" whereas the mentor is having a more open-ended conversation about it.
Hmm maybe you are right and the example is not very good.
Let me try to rephrase it in a way:
I think the main difference for me is that I go to the coach to support me to solve problems/matters by myself and they are there supporting my process but I expect them to have less influence on the actual content/solution itself.
To summarize the coach does not give advices nor they should impose best practices.
While I go to the mentor expecting them to offer me advice and guidance/best practices.
In this I choose (very rarely) a coach to explore problems that I think don't have a universal solution or the solution is subjective like “Should I move to management or continue on the technical path” or “What is best for me: freelancer or employee?”
And I go to mentor to get concrete advice/guidance on specific matters like “How to increase my income as freelancer” or “How to start a new career in X”.
As I write this it seems that for me I see coach as a person that can help me discover the why and the mentor is someone that can help me discover the how.
I've worked with some psychologists giving business consulting, and they would use the definition from the International Coaching Federation (ICF), which is that coaching is "partnering with clients in a thought-provoking and creative process that inspires them to maximize their personal and professional potential".
So in that sense a coach would not set the agenda at all, nor be directive of what you need to do to get there, quite the opposite in fact. They keep asking questions and pushing you to figure out what you need to do to get there, which means that a coach can theoritically help you even if not in the same field as you.
I've also worked in consulting in a past career, and I've had a hired coach, and the line you quote with words like "partnering" I would describe as part of marketing the product. They're not exactly going to say "hire us to push you out of your comfort zone", but that is the role.
You said: "they keep asking questions and pushing" -- that's what I mean by setting the agenda. As I mentor, I don't see my role as "pushing". Questioning, sure. Providing perspective, sharing my stores, yes. Actionable feedback on skills is the closest I'd come to "pushing" and even then, they can take it or leave it.
When I see people talking about coaching, I often see -- directly or indirectly -- some aspect of the role of the coach to be to "bring out their best". I rarely see words like that used to describe mentoring relationships.
You made me think more about this subject with this comment. In a way - due to different incentives - I think you are right about the outcome.
As the coach is mostly hired and the mentor internal it might be that the coach has more incentive to push someone to bring their best while the mentor - having as main focus another job and doing mentorship as a side task - will offer advice/guidance but will not have the same incentive to follow through.
Anyhow I agree there is not a standard definition of what a coach or mentor is and what they should do.
When there's some doubt about meaning, I find it useful to wonder how other people might interpret the words I say, and I have found that a dictionary is a good way for communities and societies to agree on what those words mean. I do not say this to be snarky. I used to be surprised to learn that some words I thought I knew had a different, if related, meaning. Now, if say I was presented with an article that I wanted to comment on its use of words, I will look up those words first to see if perhaps I am the one that is out of touch with my peers.
I am a mentor, a mentee, and have had life coaches and sports coaches. While I have paid life coaches, i.e I am setting goals, that's very different than a coach within a corporation: perhaps the distinction for coach is "Who is paying the coach?" A mentor, however, is very much a counselor / guide, even though they are paid by the company. Another distinction is that coaches are, to some extent, accountable. They are paid to achieve a result. Mentors just don't have the responsibility.
Honestly, the relationship between a word and the concept that it symbolizes is man-made and arbitrary, even among individuals. I don’t think that arguing vs the article on the basis of definition alone is going to lead to a fruitful discussion, because there will always be something that can be said of how one activity seems to fit with either of the two (for example, your attribution of the definitions to sports may be from your subjective experience of sports, but maybe coach and coached relationships with others are different), so it might do us all better to just really focus on what the author is trying to say. Coaching is passive, mentoring is so much more actively involved (though I personally find rather odd where the delineation was drawn, and I’m just creeped out by the idea of a mentorship setup now).
I get it in your other comment that it helps you set your expectations—but it’s not like these two words are technical jargon with clear meanings in some field of science, so you can’t just take them without nuance.
hmmmm in my mind I had the exact inverse definition of what you said. For me “mentor” is exactly what you defined as “coach” and for me “coach” is exactly what you defined as “mentor”.
I never was or had any formal mentor or coach, so there is that.
This articulated for me one of my biggest frustrations with traditional 1:1s with managers I've had throughout my career: by these people I want to be coached, not mentored.
Most 1:1s have been driven by me, at the explicit behest of the manager. "I'm here for you" and "this is your time" are/were common phrases. I found this particularly annoying as a new grad when I really didn't know what I didn't know and just wasn't getting a lot of mileage out of those conversations.
Against the common sense, I started talking a little bit more when the 1-1 mentee is at a unknown unknown situation. I tell them they should look fwd to a,b and c if they are to look for a direction and I invite them to setup a further specific 1-1 to discuss this, if that catches their eye. If not, again will let them explore and then comeback with other options and so on.
The biggest thing I've learned when being in (loose) teacher or mentor relationships is NOT to push someone to do what I think makes the most sense or that I think strongly is the easiest way to go. Instead the best thing to truly help someone out is to encourage them to do what they WANT to do.
The reason is because even if there truly is a simpler way, it isn't always simpler for someone in their current position based on their current biases/experience/knowledge/etc. But what you WANT to do is a really powerful motivator and the most important thing is that you keep trying things and get better eventually.
I disagree, in that you sometimes you do need to get the person to see things your way. As a mentor you should provide / present options. Failure is a powerful lesson, but being able to learn without failure is just is the same outcome.
Yeah this is what I don't agree with. As a leader, you act as a shield to the people that report to you. You may be privy to information or have a better view of the overall big picture. Sometimes there are burdens you don't want to put on the people that report to you. We can only be so transparent a lot of times.
Theres going to be times where you'll need to have them align with overall company goals etc.
Some "mentorship" relationships are distinctly separate from other work concerns. A mentorship program where I work explicitly pairs up people who are distant in the org chart. The mentee can share openly, and be confident the feedback has their interests at heart.
If this sort of mentor needs something from a mentee, that's a conflict of interest. (People use "mentor" to describe different relationships though!)
In my personal experience a good mentor will never patronize but will still manage to convey their, usually higher, expectations for kind and quality of your work.
The best mentors I've had were also extremely good at receiving and processing feedback themselves because they honestly loved learning and wanted to be better as much as I did.
I'd had number of mentors, and myself almost a decade of experience teaching technical classes and 1:1 private lessons before I got into mentoring other SDEs at work and was amazed by how much I learned even just from first few relationships.
Coaching and mentoring really are so different.
I have definitely seen organizations where either the culture or the "climate" all but prevented effective mentor / mentee relationships no matter the effort. Really don't miss working at those places, probably the most burned out I had ever been in my career.
Unrelated rant, and not saying this is the case here I'm sure it is not from reading the authors blog.
However, anyone notice how 4/5 developers describe themselves as mentors? I've intereviwed so many people who describe themselves as mentors yet could not answer fizzbuzz
4/5 developers could (and maybe should be mentors) - assuming they are all competent and all have different skill levels, you could have
L5 mentors L4 who mentors L3 and so on.
Related, more cynical take - being a mentor is often a factor in promotion & hiring, and being viewed as a mentor will make you more likely to be promoted or hired.
It is known (and proven) that most people grossly overestimate their experience and abilities.
In software development it is even more egregious because, due to exponential growth of number of developers, most developers haven't had a chance to work with a real, good, expert developer.
You need probably at least 10-15 years and more realistically about 20 years to grow to be expert at your field. And even then only small percentage grow to be truly experts, the rest become stuck somewhere along the way.
How do you asses whether you are mentor material if you've never seen a real deal?
You don't hear people who decided they are not mentor material yet -- you only hear from people who did.
So this is the false positive problem -- given even small chance of false positive on deciding you are mentor material, given huge population of developers and very small population of actual good mentors, you are bound to have a lot of false positives.
Exponential growth also pushes down the time when you need to become a mentor.
If the field was totally stable (retirement rate = graduation rate, and everyone retires after 40 years in the field, greatly simplified model), then each new joiner could be paired with a mentor of 20 years experience, and only needs to become a mentor after 20 years. But if the field is growing exponentially, the age drops significantly. I'm sure someone could calculate this; it's almost like the inverse of the retirement age, population change, and social security question
The term has simply gotten diluted, just like the phrases "good at math" or "being good with computers" can mean I can do basic addition mentally and I can setup your email software. It's not a fight worth fighting as people will tend to find the path of least resistance that gives them the most gains. Its the opposite of the imposter syndrome, also the 'fake it till you make it' mantra. IMO, its not really that bad in s/w dev because "Talk is cheap, show me the code".
- have the experience to have had enough time to observe things in reality (vs theory) and have had the time to internalise and digest all of this
- be mature
While it is easy to get the knowledge, the rest usually cannot be skipped so easily.
As to math, that is not a good example. Math is almost pure knowledge and intelligence and so a bright kid can acquire that knowledge and quickly pass to his peers assuming they are intelligent enough.
Unless you really mean Mathematics. Like how to advance the field. Then it is not as easily transferable knowledge. I know, I studied theoretical mathematics.
Software development is only in small part driven by knowledge. If you think software development is knowing programming languages and frameworks and AWS and certifications you are waaaay off the target.
I think your advice holds for people who are well on their way into their careers, but even with someone with half the years of experience (i.e. 7-10 years) can be invaluable to someone starting out in the field.
I don't think I would've been able to right my career had I not had a dev with about ten years experience mentor me for a year. Granted, he might be an edge case since he learned teaching before becoming a programmer, but nonetheless his empathy and encouragement on top of some lived experiences was invaluable to me.
I have this model where you can get regular help with what you want and mentor help with what you need.
Mentor will be mature and experienced enough to be able to recognise your particular needs and be able to adjust to you. Mentor will be able to understand their own limitations and adjust for it, too.
On one hand I agree with you that experience matters a lot, and is often undervalued by SV/VC youth-worshipping culture. There's no substitute for having seen many different ways of doing things, the effect of decisions as technology ecosystems evolve over time, and the underlying human dynamics that drive outcomes in any large-scale human endeavor.
On the other hand, experience is mostly orthogonal to technical and pedagogical skills. After decades of experience I've seen mentorship come in many forms, and I would never put some kind of litmus test on who is qualified to be a mentor. Ultimately it's about individual strengths, weaknesses and chemistry.
Perhaps this is because for some programmers, their career path takes them from writing code to a broader leadership path (mentoring, management, tracking problems, organizing consensus between groups, etc), and they may have stopped actually being a programmer years ago without necessarily even noticing. Unused skills atrophy, so it wouldn't surprise me to see candidates who are experienced mentors and leaders but can no longer write code on a whiteboard (although failing to fizzbuzz is a bit extreme).
Of course, maybe I'm rationalizing and it's just that candidates who aren't fresh out of college need to claim some leadership credentials, and they don't want to lie and say they've formally led or managed anybody, so they just make vague statements about mentoring in the hopes that you check the right box on the hiring rubric.
The failure here, is engineering leaders are rarely chosen for their soft skills and ability to mentor vs their technical expertise. Sounds like you only care about the latter, adding to the current system
I would argue that you have to have competence and ability in the area you seek to mentor in, otherwise you are simply spreading bad advice around. If you can't complete FizzBuzz you probably shouldn't be mentoring others in software engineering. That doesn't mean you have to be a savant at your occupation but there is an expected level of capability.
Disagree, you can find mentors in many areas. Outside of core competencies. It really depends on what level you're at in your career. Yes a Sr engineer mentoring a Jr engineer, absolutely. A director of engineering mentoring a engineering manager, not so much.
One thing people forget: let your mentee fail. Don’t bring the business down, of course. But do let them fail — there are good lessons to be learned and failure is a great way to do so with an emotional impact that lasts much longer than an intellectual one.
> In mentoring relationships, usually the mentee sets the agenda. In a coaching relationship, usually the coach sets the agenda... Code review is a pervasive example of coaching being confused with mentoring.
Maybe this is a useful way to think about it: I'd argue that doing code review for everyone on a team doesn't mean I'm a mentor to everyone on the team. I'm doing a task that is part of my job -- to coach the team on coding -- and they have to consider my comments whether they want to or not.
But if an engineer approaches me and says "in my last performance review, I was told my code isn't very well structured; can you help me?" and I walk through their code with them, then I'm mentoring. It's skill mentoring, in this case, which, as I said, has the most overlap with coaching. Same activity, but different context.
But as someone else said, this distinction isn't really the important part of what I wrote. So if people disagree on the terminology, that's just fine.
The way I think about it is that it’s coaching if you are making decisions for them about the path they should take. It works here because writing code is a fairly general skillset.
With mentoring, the crux of the problem is that you’re trying to help them navigate their specific situation. And in my experience both as a mentor and a mentee, “where are they trying to go and what do they really want?” is actually the hardest part, and it’s not something you can consistently answer because it’s their experience and you’ll never fully understand the nuances of it. You can’t lay out the path for them, you can only (try to) help them see further down the path they’re already on.
If the developer is young/new and you are reviewing their code expecting various mistakes that you can then "coach" them about, it could be part of coaching. However at other times, code review is just what you do as a second pair of eyes, you are not expecting to give coaching as a result of something you might spot, just feedback.
I wouldn't worry too much about specifying things too specifically though!
To indulge in a bit of naked self-interest here: a few people have mentioned paying for coaching or mentoring. How does that work, did you personally pay or did your company pay, and what was the hourly rate if I can ask? I'm wondering if it is a reasonable angle for some of us old-timers to get into. I'd have to charge an amount comparable to software consulting, and I'd expect most people to not be willing to pay that out of pocket, but maybe I misunderestimate (sic) this crowd.
Weirdly, in one job interview they asked if I was willing to mentor junior devs. I said yes, they hired me, but the subject never came up after that. In another, the topic never came up at all, nobody approached me for mentoring at the job, but my management later hassled me about missing their expectations about it.
I'm not sure that the article's distinction between "mentoring" and "coaching" matches my experience, or how I'd use the words. When I think of who has mentored me the most, it's usually the lead engineers on the teams I've worked on. In a sense they're just doing the job they're paid for, but I still consider them mentors.
To me, asking a prospective senior engineer if they're willing to mentor juniors is equivalent to asking "are you willing to put in time and effort to help juniors learn how to be better engineers?"
Yeah, I saw the terms mentor and coach being used in different and confusing ways in this thread. I figured they don't have clear meanings and that is fine. We can approximate well enough.
I imagined in-office mentoring as being something like meeting with the person for an hour or two a week, looking at the current state of their project and making comments, doing some pair programming, that sort of thing. I've received lots of informal mentoring myself in that way, so I was looking forward to doing it. But it never came up.
After being an independent contractor (software engineer) for a decade I am now a full time employee and in my first formal mentor-mentee relationship. I would love to hear about positive experiences people have had from mentoring as I’m still feeling out the relationship and wondering where it can go.
Good mentors nudge and maybe push; they never shove.
The best mentor I ever had helped me orient myself when I had no idea what I wanted to do. My answers were always, "I'm not sure. As long as I'm actively developing, I'll likely be fine." This wasn't quite true. Working on feature sets that didn't make sense with the code's architecture only to be thrown out 3 months later was rough.
She was the one that encouraged me to work on skills during work hours. No employer is going to miss 1/40 hours when it's used for professional development that directly benefits them. She encouraged me to stick with learning new things when I was ready to phone it in. AWS certs aren't hard to pass, but I probably wouldn't have taken the test without her push. I would have never dipped my toe into management. I found that management wasn't for me, but it was a better experience than resting on my laurels for a year.
A good mentor is like a good friend checking in on you from time to time, but the relationship is professional. Everything pertains to your professional goals (or in support of) from a place of wanting the mentee to succeed.
Mentoring and coaching terms are a bit too one-way for my liking. So I’ve always avoided that terminology in favour of more peer to peer metaphors.
While I may have more flying hours in some topics of life or work, even a younger and/or less experienced person in some ways, can teach me something in other ways.
Building each other up makes for very rewarding bilateral relationship.
One thing I sometimes point out to software engineers Im tasked with mentoring at work is the importance of showing other engineers that you care about the code and the questions you're asking via slack etc by proof reading what you write and reviewing your own code before reaching out to others for help. The frustration of reading ia garbled slack message or pulling over to look at a code snippet and realizing the person didn't even look over it themselves is real and has real negative consequences in terms of professional perception.
Like when someone misspells radical candor in the second sentence of a blog post about mentoring.
Seriously though, everybody makes mistakes but when I do slip up like this I don't expect people to engage with what I'm writing. And I do think proof reading is an incredibly important skill for new and experienced software engineers.
[edit] I just noticed the author is a staff engineer at MongoDB. He can misspell whatever he wants. I recant my sassiness.
And now I've discovered that vim spell check skips words with leading markdown symbols like `*randical`. I'll have to dig into that more.
Update: pasting the web page to Google Docs found a few more typos. I fixed those, too. Usually I print and read to find typos, maybe I skipped that this time. Good reminder to do that and the Gdocs review. Really: thanks for the reminder, regardless of the sassiness. :-)
I really am sorry for being a troll and writing the kind of comment that bums me out on a regular basis. This seems like a good post and a good discussion.
It can just be frustrating for those of us that have a hard time getting traction when we post projects etc on sites like HN. It can manifest into petty toxic behavior especially in comment sections.
In the words of Paul Doherty... "I'll do better next time."
> And now I've discovered that vim spell check skips words with leading markdown symbols like `*randical`. I'll have to dig into that more.
Taking a quick look, for me it seems that (Neo)Vim spell check skips anything in italics or bold. No highlights whatsoever anywhere in that region. Definitely not something you want to realize _after_ publishing articles!
Edit: Considering the comment about using :syn off, seems like this is probably a conflict of some kind with the way Vim actually italicizes/bolds things in terminals that support it, now.
Anything longer than a few sentences I'll write in vim and am always horrified when I copy to Gmail or Google docs and find spelling mistakes, duplicated words, and incomplete sentences everywhere.
I agree, but you can generally differentiate these cases and handle them appropriately.
If someone is burnt out, the attitude is typically the tell regardless of care. It's deliberately sloppy.
One of the best engineers I ever worked with had dyslexia and by God if his class names weren't the funniest things I've ever seen, but they were consistent and the structure and documentation was thoughtful.
Ironic that you pointed out an error in blog post's 2nd sentence when you also have one in your 2nd sentence. Either that or a nag trap. Or an unconscious parallel humility.
I usually have a knee-jerk reaction when I see grammar and spelling errors in blogs, but I try to remind myself that these posts aren't published works that made it through an editorial staff. Mistakes happen, especially when the author isn't a professional writer.
This is all true of course, but is it really so much to expect someone to proof-read something they're publishing? All things being equal, more of these types of simple-to-catch errors will make people think less of your [skill, dedication, attention to detail, etc.], whether right or wrong.
I ran a very popular site for a decade and won multiple writing awards. There are many elements that make a well written piece, and of course, spelling and grammar are two important ones.
Unfortunately, over 12 years, I had two spelling mistakes slip through my hours of editing and proofreading. Some people absolutely eviscerated me for it. I mean, how could I not know how to spell X word? I must be a moron! In my opinion, these "simple-to-catch" errors are not always simple-to-catch when the writer knows what it is supposed to say and they are trying to proofread their own work.
That said, it proves you're right -- people do think less of you when you make such a mistake. I think we should all strive to cut people a little more slack, at least on Slack.
I don't think adding a jerk-ish edit helps you sounding a engaging and/or caring mentor although I admit that I was almost bursting out. Being consistent is hard, but let's try within the same <textarea>.
^ This is one of the first lines in the article. If I had to guess I'd say most people here spend a relatively small amount of time learning about how to do their job vs actually doing it.
For me this is a good reminder that actively/intentionally investing a couple hours per week in learning about how to do things - technical or not - and evaluating myself will probably have a higher ROI than spending those hours doing the thing
This reminds me of some of the ideas discussed in this post [0] from a few days ago.
[0] https://news.ycombinator.com/item?id=29692029