sdiupIGPWEfh

How many species are basically the same if you completely ignore differences in size, texture, color, and behavior? If you squint right, we're just apes in suits. It's almost like all those small differences add up to an outsize impact.

I wonder if there could be a corollary to this. I'm quite introverted and for some reason people seem to think I'm an excellent listener, when actually I'm actively ignoring them and wishing they'd just stop talking already. Come to think of it, I feel like I've seen a webcomic somewhere making this same observation.

Hear hear.

Dodging an issue tracker is, IMO, one of the clear benefits of TODOs (or FIXME, HACK, BUG, and family). Especially in low-trust teams or whenever there's a need to avoid the sorts of politics that can arise between roles.

Refactoring tickets are terrible for all the reasons you point out. PMs will essentially never prioritize refactor work over new features unless pressured to, and if so, the work more often than not gets assigned to newer hires and junior devs, whereas a TODO is actually more likely to get picked up by a curious and intrepid newcomer when they're actually ready for it. Should said newcomer stumble across it before they are ready, it can also be a signal that they ought to reach out to a more experienced developer to ask some questions. For devs, refactor tickets may be useless overhead: in time spent writing, time spent defending, time spent estimating, etc. And in return, there's little glory or praise achieved in working on them; tracking too much time on refactor tickets may even attract negative attention from management. Then good luck if your QAs and agile leads are suspicious of any unit of work that a new test plan can't be written for.

A good TODO is sometimes just how the sausage is made.

Fascinating. Are you comfortable sharing anything further about the condition? Any particular blood thinner?

A couple years ago, I could manage reading and writing ROT13 somewhat decently. I can still do it after some warm ups first. I can also do arbitrary Caesar cyphers in my head, but not fast enough to impress anyone. Memorizing the alphabet backwards helps, as does being able to visualize the numeric value of each letter. Embarrassingly, I'm actually rather slow at the simple mental arithmetic part.

I'm sorry, but you keep rephrasing this question, I've answered, and I still don't see how the question is relevant.

I personally do not enjoy pair programming as a regular practice, but the focus here on performance is misplaced while the pedagogical benefits are swept under the rug. In exchange for some performance, I'd expect gains in team robustness. There are things you learn while participating in solving the problem that you'd never encounter during a design meeting or while doing code review. Subtler design problems and technical dead ends can be caught earlier and save substantial time over the typically async rejection process, leading to more productivity over a longer measure of time.

> This thread is specifically about Netflix work culture, as reflected in the old slide deck.

This isn't just about Netflix. The over-arching topic is company anti-values. The context has narrowed since then, first to Netflix, then to a specific slide about not measuring people by hours worked, and so on. But for the heck of it, some other quotes from said slide deck:

> We don't measure people by how many hours they work or how much they are in the office

> Actual company values are the behaviors and skills that are valued in fellow employees.

> Honesty Always

> Pro Sports Team Metaphor is Good, but Imperfect

> Internal "cutthroat" or "sink or swim" behavior is rare and not tolerated.

Again, if the expectation for a workplace like that were 60-80 hours a week, and that fact is clearly and openly communicated, fine.

But if you're making those claims while your top performers are the ones putting in undocumented additional hours and pressuring others to do the same, then I insist that is toxic behavior. Yes, even if they don't brag about work/life balance, though I'll consider it even worse if they do.

> So yeah, it seems like we are in agreement :)

All sarcasm aside, no, we're definitely not!

Remember, this is in the context of companies stating they value impact over effort, the sort of places that brag about their work/life balance. If I'm accepting an offer from such an employer and taking this into account during salary negotiations, I will be rightly pissed off to find out the standard is secretly 60-80 hours a week.

If they're open about expectations, assuming I'm at a point in my life where the trade-off makes sense, then if the compensation is good, that's fantastic. Nothing toxic about that. Not that different from some US manufacturing workers getting paid hourly wages, who make the same kind of trade-off all the time, making damn good money for 60 hours of peak performance a week. Sure, they might end up paying for it by ruining their bodies and drop dead from a heart attack or stroke within a year of retirement if they make it that long, but the risks are no secret.

> This situation is normal and expected in professional sports.

Let's google. The NFL seems topical around this time of year.

https://www.cnbc.com/2019/02/01/heres-what-the-average-nfl-p...

> The minimum annual salary for a rookie active roster player with a one-year contract is $480,000 . . . A player with three years’ experience would command a salary equal to at least $705,000, while players with seven to nine years on the field must be paid at least $915,000 . . . the average NFL salary was only about $2.7 million in 2017 . . . That’s less than three-quarters of the average $4 million earnings of a major league baseball player and less than half the typical wage of NBA players, who earn about $7.1 million on average.

I take everything back! Let's not treat SWEs any differently. For that kind of money, I will gladly put in 80 hours a week.

If your colleagues are leveraging substantial undocumented overtime, you're going to find out eventually. If you know someone is in the office 40 hours a week and they submit massive pull requests first thing in the morning, even Monday mornings, for problems you know they hadn't solved or started the night or week before, you should suspect something's up. Sooner or later, if someone's breaking their neck, they will resent team members who aren't putting in the same effort, and they'll slip and admit to the amount of time they're putting in, directly or indirectly.

Granted, it's easier to hide this now when everyone's working from home.

> I’ve worked with people who could accomplish as much in two hours as I did in two days. Would it be “toxic” to work in such an environment?

No, why would that be toxic?

What I've seen happen at other companies that state they value impact over effort, openly discouraging overtime, is that eventually certain individuals will attain higher impact by not recording their overtime, who then pressure others to do the same. No, no one is directly rewarded for overtime, but effectively, yes, undocumented overtime becomes the expectation from your peers. That is toxic.

I am ashamed that this has never occurred to me and shocked that I have never heard it elsewhere. Brilliant.

Apparently, the "Nintendo WiFi Network Adapter" was once a thing in Japan, and it did have a router mode.

https://www.wired.com/2008/09/nintendo-announ-2/

https://www.famitsu.com/game/news/1217892_1124.html

https://kotaku.com/nintendo-announces-wii-ds-wifi-router-bwa...

> It got to the point, where even my rough sketches would be as good as finished works.

Hah, I feel like I understand more where you're coming from with that. I was the opposite, seeking to get my finished works to feel more like my rough sketches.

> I never really warmed to Boris Valleho's work (he used to hang in a gallery that I had work in, and I met him), but I have to admit, that guy can draw.

That he can draw is undeniable indeed. There are a few artists whose sketch work reaches that level of refinement almost immediately. Others get there after years of study and practice. Still others don't see that at as a goal at all for that stage of their process, and others still would see it as an antithesis to what they're after. Looking at Valleho's finished work, I can at least understand how his sketches are in service to that sort of end state.

Compare, perhaps, to some Rennaisance-era sketches. Typically far rougher compared to the finished works, but hardly less impressive. I'd suggest there's a great difference in what they were interested in: matters of anatomy, gesture, and composition. Of course, they were also inventing and rediscovering knowledge that modern artists have far easier access to. There's an interesting dichotomy in that some destroyed their sketch work, while others had far less interest in actually finishing anything.

I've forgotten an appalling degree of art history, so I can't readily name names, but as far as finished works go, I had a fondness for painters using relatively minimalist brush strokes, with each application of paint exactly the right color in exactly the right place.

If that's what you want to do and what you have the personal time for, that's fantastic. For others, being obligated to reach that level of polish means a ton of code will simply never happen.

I'd liken it to an artist's sketchbook. If every piece is required to have the appearance of a master work, lest you be judged by it, then the sketches must remain private or else be destroyed (which they often were). But the masterpieces don't jump to the canvas without sketches. Forgo one, forgo the other. And an artist's sketches often have an elegance that's lost in the translation to a finished piece. I see similar parallels in the rough line art for animation, and certainly in an architect's studies. Not all of it is destined to be finished, either, but such work is often prized regardless.

So why (aside from fearing for our careers) should we be afraid to share?

Some code is inherently low-stakes. Some code will only ever be useful, even to the public, for a few months. Sometimes I just want to express an idea, where the proof of concept matters far more than making something shippable, which might imply strapping it down to a particular platform or ecosystem where no one outside those walls is likely to see it.

Even on the job, there's a time and place for the quick & dirty script, where anything more would be an over-engineered waste of time.

Back to the artist analogy, the best advice for maintaining a good portfolio is edit, edit, edit. Constantly be looking to remove work, leaving only your best, as you'll be judged by the worst. Does that model really work for GitHub? If everyone started withdrawing work they were no longer satisfied with, we'd all be worse off, if not actively harmed. So that's where I believe my artist analogy ought to end.

Huh, I like that idea. Thank you. Possibly a good excuse to get in touch with some former colleagues as well, which I suppose couldn't hurt either.

Mercifully, I'm not quite yet desperate about leave my current role. But I do feel like my career (and salary) progression is stagnant; not seeing much opportunity where I'm at. I'm thankful for what I've got, but I think it's smart to be looking. Just found it weird to face rejection so much from people reaching out to me in the first place, in a supposedly hot market.

> Coderpad must work for some people since companies are able to hire a nonzero number of engineers, but it is definitely not a good fit for me.

Seems everywhere I've applied recently has been using Coderpad.

Lately I've been accepting interview requests for principle roles from on-site recruiters, and I've been consistently rejected after these Coderpad tech screens. What's bugging me, however, is the "challenges" have all been softball questions. Reverse a string. Demonstrate an understanding of closures. Write a function that tests if two strings are anagrams. Write some basic React. Create an interactive form. I breeze through well enough, then it's either an immediate rejection or else they ghost me. Not once do I get farther than that. I'm not even mad, just confused as hell.

This is coming from the perspective of someone who was getting used to offers from the first job they applied to. If there's something off-putting about me lately, I wish I knew.

Isn't interviewing in pairs fairly common? When being interviewed, there's always been two people across from me for the technical rounds; anything 1-on-1 is limited to initial phone screens and final rounds with the bigwigs. When conducting interviews, I've always been one of two, with the exception of one time when no one else was available to join me, which I'd prefer not to repeat.

I would go so far as to say a random passive observer is still a great idea in addition to two active interviewers.

All too often, code review amounts to no more than making sure there are no grievous mistakes. Management only cares about you completing your own work, and if reviewing the work of others slows you down, that's your problem. Time spent on code reviews have never counted toward mine or anyone else's performance. A bad PR making it to production certainly gets negative attention, so that's the aspect given priority. The incentives do not align to make code review a place for knowledge transfer.

That sort of problem is about the right level of complexity for a candidate to show they can think about a problem, provide an implementation, and discuss alternatives. Something they should be able to do without ever studying or grinding LeetCode.

However, there's always room for the interviewer to muck things up.

For the anagram problem, there are a range of solutions, including elegant & inefficient, clever & efficient, and robust & efficient. Do you dock someone depending on which they reach for first?

There's limited time, and a candidate may assume you're mostly interested in "how they think" and thus focus on the algorithm alone. After the interview, do you run the candidate's solution against test cases that you never mentioned, docking them for "missing" matters of casing or non-alphabetic characters? If the candidate themselves wrote unit tests, do you dock them for missing test cases you felt should have been included?

Do you dock them for not checking for invalid inputs, even though the candidate might normally work in a type checked variant of the language that wouldn't have permitted that anyway?

So many possible hidden assumptions. I know I've been rejected for similar unstated expectations in the past, and in retrospect, I know I've been guilty of doing the same to others.

Had an experience like this recently with a certain media streaming hardware company that starts with an "R". Their process had six points of contact, starting with an initial technical phone screen (with a language feature quiz), an hour long algorithm session (actually surprisingly fair), and then four more 45 minute interviews after that. They'd made a point of saying how good they were at getting back to people in 24 hours, and then they ghosted me. As far as I could tell, it was going alright, too.

Weird. If asked to visualize a triangle, I see the "glowing lines in a black space." If I try to visualize a red/green/blue triangle, I can only briefly maintain the image before it fades away into the default white outline in the void.

However, when asked to think of Tony the Tiger and his stripes, not only do I perceive orange fur and red bandana, but I'm struck by just how freaking blue his nose is and it is uncomfortably persistent.

> Besides migration, some theories of the time held that they turned into other kinds of birds...

Makes me think of loons, which completely change their plumage for the winter in addition to migrating from fresh water lakes to oceanic waters. Without close study, you might not realize they're the same birds.

We could make individuals pay for it. Heck, we could tax it, make them pay through the nose for it, and reinvest it back into vaccinations. Up the costs even more if they want to be retested. Since it's not medically necessary, their insurance shouldn't have to cover it, meaning the costs won't have to be borne by everyone else.

How often do they, in your experience? From my perspective, the only ones discovering and calling out dependencies are senior engineers (or higher) either during planning or during active development, as the PMs are blissfully unaware of how anything's actually connected, even if they've been handed architectural diagrams on a silver platter.

I would presume the actual scientists involved either (a) know that these blobs of cells are as incapable of subjective experience as my appendix or else (b) know there is no scientific basis for claiming one way or the other, though they may well share my belief that it is unlikely.

Now, I would be quite pleased if science journalism would do away with making such claims in either direction without further elaboration.

> In this case, these stem cells are coaxed to grow into blobs of brain tissue, without anything resembling thoughts, emotions, or consciousness.

Sure, I'm skeptical that organoids are anywhere near being capable of thought or emotion, but I don't see how it's acceptable that TFA can just assert so as fact with no further elaboration. Are the organoids developed enough to produce connections between neurons and show electrical activity by the stage they develop eye-like structures? If there's nothing like that, cool, no problem. However, if they do have that level of development, how exactly do you prove they have no subjective experience?

If the two year old in question knows their alphabet, upper & lower case, knows most of the sounds the letters make, and can sound out unfamiliar words and sight read the rest, I don't really see what's controversial about calling that "reading". It's not a stupid toddler trick or a mark of genius, either.

If we're going to add comprehension requirements on top of that, then what passes as reading is pretty abysmal even for some adults.

Echoing others, hyperlexia is a thing, and reading by age 2 isn't really all that special. I was reading by age two and a half, and my own kid was reading just before turning two. I'm no genius, while she's definitely sharp but not gifted.

I'd love to know how this guy's employees feel. Tempting to give snark for snark.

> Most problems in business will not fit in your well-scoped JIRA ticket. That doesn't mean you get to ignore them until they do.

But you're still chaining me to Jira, aren't you? I'm still being judged by how many points of Jira tickets I close per sprint, aren't I? And I bet you're still trying to insulate me so I "don't get distracted" from my tickets.

> People get paid the big bucks because they handle that uncertainty well and bring those vague, ill-defined problems to a good resolution.

So I can expect to receive the autonomy needed to take on those problems after all, and also get the compensation commensurate with that responsibility?

> "I'm pretty good with React" doesn't quite cut it.

Is that the bar we're using for hiring engineers around here? Damn, I did _not_ interview your company well enough before accepting this job!

> Yes, because of the implication: you want ownership? Great. Here's your KPIs. You didn't meet those KPIs? Here's your severance, best of luck at your next job.

Hold up. I already have KPIs / OKRs / MBOs or whatever flavor of the year HR is pushing on top of the sprint metrics you're tracking, and as a senior engineer or higher, I'm already in trouble if the product fails, which is another reason I want the autonomy to make sure failure is avoided!

> I made a comment to an advisor a while back about "a VP on a PIP" and they laughed. "Mike, a VP is always on a PIP. That's the role. You hit your KPIs or you're out."

Why are we bringing up comparisons with VPs? Is it VP-level autonomy or nothing here?

> Like, lemme get this straight: you expect a six figure salary, full autonomy to solve problems as you see fit, and _also_ bite-sized, well-scoped bug reports/features.

I take some offense at this straw man.

Either give me the autonomy to solve the high-level business problems you want to make me accountable for, _or else_ I will default to expecting bite-sized, well-scoped tickets.

In exchange for six figures and autonomy, I'm capable of writing my own well-scoped tickets if you think that's a good use of my time, and I might do so happily if I need to be coordinating with other talented individuals in a team built on mutual trust and respect. But if I'm stuck with minimal autonomy, pulling some tickets written by a project manager off the backlog, then hell yes I expect them to be bite-sized and well-scoped so I can do my job and not waste an entire week figuring out what the problem really is, determine who the real stakeholders are, secretly talk to the end users, pick the brains of developers on other teams, implement a few thousand lines of missing back end services, coordinate with ops to get those deployed, and finally just add that button to the UI that the product owner, half a year ago, persuaded the team would only take a day, all why being grilled every morning about why such a simple task is taking so long. Don't deny me autonomy, let me be fed me crap, and have me do someone else's job without credit while listening to them complain. Let me do my job without wasting my time; is that too much to ask?