Live data from Hacker News

Build Impossible Programs

jvns.ca

71–80 of 131 posts

Re: Build Impossible Programs

#71
post #11

I can't tell if she's nervous or awkward or excited but it reminds me of myself when giving talks, even to small groups. I get so flustered that my mind races and then the rest of my body tries to catch up so I'm now talking really fast and moving and jumping all over and being very fidgety with things. Anyway the difference is that she managed to get her points through while mine often gets lost. I still don't know…

Whenever I have to speak publicly, I try to channel Barack Obama. He talks so ... slowly. He pauses so ... ... long between sentences. It feels like agony when you’re doing it, but it works. In reality the pauses are never as long as you imagine, and it gives the audience time to absorb what you’re saying.

Obama uses a TelePrompTer and practices a lot. I tend to do better giving talks on the fly that are more organic, but each person has their own style.

Re: Build Impossible Programs

#72
post #31

Anyone know what Julia is using for those handwritten slides? I absolutely love everything Julia writes. She writes in a way that makes absolutely zero assumptions about your level of technical competence. You could be a junior, mid, senior and still get something from most of her articles. Anecdotally; Almost every female engineer I work with writes and communicates in this fashion and I really bloody wish more of m…

> zero assumptions

I think this means "the assumption of zero knowledge." I love when Scientific American or articles on the web try to give the reader an idea of a recent advance in physics, say, by starting to explain that "atoms are these tiny thingies which are so small that you cannot see them with a naked eye and which were first conceived of by the ancient Greeks." In certain contexts, you cannot make an assumption like that.

Re: Build Impossible Programs

#73
post #61

Earlier quoted context omitted.

> Anecdotally; Almost every female engineer I work with writes and communicates in this fashion and I really bloody wish more of my male counterparts would speak with less jargon/acronyms for the sake of new starts/non-engineers. It’s not a good idea to generalise and push gender stereotypes in this way. You’re saying that female engineers have better communication skills than male ones, setting the bar higher for fe…

Honestly couldn’t be further from the truth. I’m not trying to improve anything, I’m stating experience. The clues in the word anecdotally. It’s a shame HN always devolves into contrarian and counter-contrarian tit for tats like this

The problem is you chose to group your coworkers by gender in the first place, and then assign some trait to that group.

Your comments just end up reaffirming confirmation bias. It also reveals your own bias to automatically associate traits with a certain gender.

Why not group people by color of their eyes, handedness, tallness, and so on? I'm sure if you look at the coworkers with "good communication" you could find common traits that are not related to their gender. So why imply gender as the cause?

Anyways, I think it's something to be avoided and be aware of in your communication. I assume you didn't do it on purpose.

Re: Build Impossible Programs

#74
post #31

Anyone know what Julia is using for those handwritten slides? I absolutely love everything Julia writes. She writes in a way that makes absolutely zero assumptions about your level of technical competence. You could be a junior, mid, senior and still get something from most of her articles. Anecdotally; Almost every female engineer I work with writes and communicates in this fashion and I really bloody wish more of m…

Very controversial topic to wade into, but: I do think that our field suffers from poor explanation of technical topics. I heard this described at a place I used to work as a "macho culture" - where it was deliberate behaviour as display of aggression, rather than sheer incompetence. Arguably this does relate to traits that men exhibit more than women (on average).

I think it is also out of laziness or simply forgetting to step out of one's own shoes sometimes. It's sometimes hard to explain all the technical parts of a project well to a newcomer who has 0 experience with a particular project when its something you've been working on for months at an in-depth level. We're all guilty of skipping small parts of explanation simply because subconsciously we've done it so much, or it is such a 'trivial' component of a given process or system.

These poor explanation and documentation patterns I find most often in open source (though it does indeed occur in industry software as well). A huge number of GitHub READMEs reflect this notion (even in npm packages, for example, that are downloaded 1000+ a week!).

To the author of software, the README may be perfectly clear, but for first time users of the software, it can be totally lacking and/or just plain confusing. I always try to be explicit as possible in my instructions and documentation in hopes to battle the field's poor explanation reputation. It's definitely a skill I always try to work on and get better at.

Re: Build Impossible Programs

#75

Some of the best experiences I've had programming is when I thought of something I'd like to make, but it seemed impossible. Then I went and made it. You do that enough times and coding becomes like real-world magic. You know you can do it, you don't know how yet. Yes, there are places you can get stuck. Rules-processing, unstructured data, Markov Chains, ML, and so forth. But even that's a win. You start understandi…

> You do that enough times and coding becomes like real-world magic. You know you can do it, you don't know how yet.

Why I'm pretty sure I'll stay a software engineer for life.

Re: Build Impossible Programs

#76
post #73
post #61

Earlier quoted context omitted.

Honestly couldn’t be further from the truth. I’m not trying to improve anything, I’m stating experience. The clues in the word anecdotally. It’s a shame HN always devolves into contrarian and counter-contrarian tit for tats like this

The problem is you chose to group your coworkers by gender in the first place, and then assign some trait to that group. Your comments just end up reaffirming confirmation bias. It also reveals your own bias to automatically associate traits with a certain gender. Why not group people by color of their eyes, handedness, tallness, and so on? I'm sure if you look at the coworkers with "good communication" you could fin…

[deleted]

Re: Build Impossible Programs

#77
post #61

Earlier quoted context omitted.

> Anecdotally; Almost every female engineer I work with writes and communicates in this fashion and I really bloody wish more of my male counterparts would speak with less jargon/acronyms for the sake of new starts/non-engineers. It’s not a good idea to generalise and push gender stereotypes in this way. You’re saying that female engineers have better communication skills than male ones, setting the bar higher for fe…

Honestly couldn’t be further from the truth. I’m not trying to improve anything, I’m stating experience. The clues in the word anecdotally. It’s a shame HN always devolves into contrarian and counter-contrarian tit for tats like this

Ohh I was about to reply to your next comment, but it was deleted. I couldn't agree more. That comment was downvoted, but not the 2 replies preceding it containing bizarre and far-fetched accusations. Shameful. What kind of society is it where you can't say: [sorry for quoting at length]

I absolutely love everything Julia writes. She writes in a way that makes absolutely zero assumptions about your level of technical competence. You could be a junior, mid, senior and still get something from most of her articles.

Anecdotally; Almost every female engineer I work with writes and communicates in this fashion and I really bloody wish more of my male counterparts would speak with less jargon/acronyms for the sake of new starts/non-engineers.

- without that apparently not being allowed:

It’s not a good idea to generalise and push gender stereotypes in this way. You’re saying that female engineers have better communication skills than male ones, setting the bar higher for female engineers.

You might think you’re improving gender equality with statements like this but really you’re setting a different bar of basic competencies for males vs females.

The problem is you chose to group your coworkers by gender in the first place, and then assign some trait to that group.

Your comments just end up reaffirming confirmation bias. It also reveals your own bias to automatically associate traits with a certain gender.

Why not group people by color of their eyes, handedness, tallness, and so on? I'm sure if you look at the coworkers with "good communication" you could find common traits that are not related to their gender. So why imply gender as the cause?

Anyways, I think it's something to be avoided and be aware of in your communication.

it’s sexism

What an utter load of rubbish. Hard to know where to start with all the misguidedness in there. (It reminds me of hearing someone say once that to say that men have penises and women vaginas is sexist.) Your reality is clashing with their theory, so your reality must be the thing at fault. Insanity. Does appalling nonsense like this come from vaguely hearing some gender studies stuff at uni? It seems they think they're doing good by their ignorant, condescending attacks on what was enthusiasm + observation.

Re: Build Impossible Programs

#78
One thing that caught my attention is Julia’s value of work / life balance and the humanization (if that’s the right word) of programming. She very deliberately didn’t work on this in her spare time (underlining that coding isn’t the only important thing in her life) and when she did build the prototype she explicitly wanted to do it at a weekend coders retreat with other “wonderful” people around (as opposed to secluding oneself in a room and coming out of it with a solution).

Re: Build Impossible Programs

#79
I just wanted to share that everything jvns is saying here is true.

In 2014, for the Google Summer of Code program, I applied to build a JIT compiler for the MoarVM virtual machine. (It is actually more correct to speak of my work as a JIT backend than a full-fledged compiler - the 'frontend' of the compiler was already under development when I started). At the time, I knew just short of nothing about compilers, let alone JIT compilation. So what I did instead was learn, and make lots and lots of mistakes.

And it worked. The JIT backend I created has been in production since 2014, with a new backend since 2017, and a small (but thriving) community of contributors. It is far from the worlds most advanced JIT compiler, but it does provide a nice speedup on real-world perl 6 programs. All the while I've continued learning.

So... definitely try ambitious things :-)

Re: Build Impossible Programs

#80

If I'm reading that correctly, Segment was (is?) providing some people $8K per month for 3 months to work on open source projects. That's amazing! Here's a link to their 2017 application page: https://open.segment.com/fellowship

Wow, $8K per month is a crazy amount of money (for a developer in Europe), especially to work on a project of your choice.
Post reply on HN