-
michaelochurch
edited
6 months ago
|
link
| on:
Writing performance reviews with positive constructive feedback
Ugh. I hate performance reviews, whether writing or receiving. There is literally no upside. You’re giving HR words that may be used against someone– or against you.
Feedback should be verbal and direct. You should be able to get a sense of who can handle tough feedback and who might respond better to gentler language. There’s no formula for it.
As for written feedback and the futility thereof, management knows (or should know) who the high performers are and will reward and promote them. If they get it wrong, there’s nothing you can do as a grunt to change their minds. The only thing that comes from putting stuff in writing and handing it over to management is risk.
Of course, if you’re a manager, you have to use performance reviews to protect your people so they can focus on their work rather than politics. It’s part of your job. You can’t not write reviews because you don’t like doing it. But reviewing peers is, in my view, inadvisable. If you have something to say, deliver it privately.
-
this is an interesting comment! At my job “just don’t write peer reviews” isn’t really something I can do, which is why I wrote this post – this is a small but mandatory part of my job, so how do I handle it when it comes up?
The only thing that comes from putting stuff in writing and handing it over to management is risk.
Part of the reason I wrote this post is that I feel like putting negative feedback in writing where I have no idea who will see it is a bit risky! But I feel like writing down positive feedback is a lot less risky, and so my hope is that if I mostly stick to that then the outcomes will be okay, and maybe I’ll even say something useful by accident.
-
I’m late to come around to this; I’ve been in Mexico for the past week.
I agree. Ratting someone out to management is bad form and a way to make a permanent enemy, but putting positive feedback (or even having a conversation with the person about what you should be saying) is not a bad idea. What this ought to be, instead of a way for workers to slag each other (to executives’ benefit), is a way for them to help each other out and build up each other’s stories. If used properly, these tools can be used for good (i.e., in workers’ favor instead of executives’).
-
-
-
[Comment from banned user removed]
-
The last two comments I’ve seen from this user seem like the inverse of the friendlysock experiment. If this isn’t intentional, I’d highly recommend reading the blog post and reconsidering your posting style.
-
-
I’m sort of used to people making fun of my writing style (people complain about my use of exclamation marks on the internet every month or so, complaining about question marks is a new one :) ) but in general I find technical comments on my posts much more interesting.
I’m honestly a bit disappointed by this comment – i tend to think of lobste.rs as a place where people try to have more substantive technical discussions about posts, as opposed to hacker news where comment threads frequently get derailed by conversations about irrelevant things and I end up not learning anything by reading the comments. To me the point of tech discussion sites like this is to discuss the technology! (for example: how could a kernel bug like this happen? have you run into other similar bugs on Mac/Linux? How did you debug them? Can you use dtrace to discover more about what’s going on inside the kernel?).
There are so many interesting questions to talk about, and I think it’s kind of a shame to waste time making nitpicky comments about the use of a question mark in the title :)
-
As a linguist who’s read enough language written without punctuation (Latin and Greek), I’d like to thank you for your use of punctuation, and to encourage it.
Latin, fun fact, has two words to introduce questions, one that introduces questions where you expect an affirmative answer (“nonne”), and one that introduces questions where you expect a negative answer (“num”), and the interrobang was only invented millennia later. It’s always useful to have a metachannel conveying subtext, and punctuation is compact.
“I think I found a Mac kernel bug.” sounds definitive, and immediately puts a team of kernel hackers on the defensive. “I think I found a Mac kernel bug?” sounds rather surprised at oneself, and emphasizes the incredulity that you’d posted on Twitter, that it was 4 days from kernel hacking to finding a bug, that you’d expected that people would have found it, and generally is the spirit of humility and exploration that has made your writings so interesting to read!
Thank you for exploring syscalls :)
-
So, however insignificant, this issue has, believe it or not, been (low-key) bugging me since this (sub)thread happened. I’m purely concerned with the linguistic question taken at face value, since I vaguely concur with the annoyance at the question mark (in the sense that I would feel odd to write in that style that myself, though I don’t care to tell anyone else what they should prefer). The reason it’s been bugging me is that it’s obvious that “just drop the question mark” can’t work, precisely because it significantly alters the quality of what is being expressed – as you stated. So how would I say that?
And I think I just realised the answer: the way to correctly express that sentiment in a more formal register is simply “Have I really found a Mac kernel bug?” D’uh, I guess.
-
Absolutely. And there’s “I think I might have found a Mac kernel bug” in slightly more formal colloquial registers, “Discovery of potential Mac kernel bug” for a title of some Technical Letter to a journal 50 years ago. More formal titles have fewer questions.
And we’ve been repurposing punctuation to convey pitch of a sentence when spoken, useful to convey one’s meaning when writing. Sometimes it’s a question mark to convey High Rising Terminal, sometimes it’s comma splices and lack of terminal period to convey a fading train of thought, it’s a fun writing constraint, you should try it
-
-
-
Thanks for taking the time to reply. I was asking because I felt I might be missing some language slang/common use that was pointed out here.
Regarding your blog posts: I love reading them, your technical content is sound, delivered in a fun way and a dive into things I rarely look at myself - I’m following all your ruby profiler posts. Keep up what you are doing, the silent majority appreciates it ;)
-
-
the high rising terminal - often associated with “valleyspeak” - is stereotypically associated with shallow, unintelligent women, especially in american pop culture.
If anyone else on the site had asked about this, I’d wager we would see far less common contentious voting patterns. But hell, let’s call a spade a spade: I’ve seen enough of OPs previous comments to have a pretty good guess at what he’s doing when he made that comment - and I wager the downvoters did too.
-
As a meta-discourse thing, I don’t really like this kind of comment even from people whose good faith I’m confident of. It’s really easy for a forum to fall into a pattern where 90% of the discussion is about pretty superficial aspects of the posts, especially in a dismissive way. I wouldn’t say that kind of thing is always off-topic, but I guess I try to think: is this observation novel and non-obvious enough that someone reading the comment learns something? Usually when I’ve been tempted to post a comment complaining about superficial aspects of a post (and there are definitely things I dislike and am tempted to comment on!) it’s hard for me to argue with a straight face that the answer is “yes”.
-
-
-
-
I don’t know enough about Linux namespaces. Couldn’t this just be handled with chroot?
-
I don’t know what you mean by “couldn’t this just be handled with chroot” (what solution are you suggesting exactly?), but mount namespaces are not the same as chroot! here are a couple of articles that might be helpful: http://man7.org/linux/man-pages/man7/mount_namespaces.7.html, https://lwn.net/Articles/689856/
-
-
-
She should be able to use dtrace to investigate deeper.
-
Where would you start with using dtrace to investigate this? I already know the responsible system call – is the idea that I could use dtrace somehow to trace what resource is under contention inside the kernel?
I’ve basically never used dtrace except running dtruss occasionally to look at system calls so it’s pretty unclear to me where to start.
-
I’m not a dtrace master, or even low-level amateur but this might be a first start:
sudo dtrace -n ':::/pid == $target/{@[stack()] = count();} tick-5s {exit(0);}' -p PID_OF_YOUR_STUCK_PROGRAMThat will sample the kernel stack of the process any time something happens with it and count them, then after 5 seconds it’ll print the kernel stacktraces out in ascending order of count. You can also look at
-cinstead of-pThat’ll probably give you way too much stuff, though. You can only get the stack traces when it does a syscall with:
sudo dtrace -n 'syscall:::/pid == $target/{@[stack()] = count();} tick-5s {exit(0);}' -p PID_OF_YOUR_STUCK_PROGRAMMaybe what you could do is use dtruss to figure out what it’s stuck in (probably a syscall?) and then use dtrace to see what’s going on there. For example, to see what syscalls were called in doing
sleep 10I did (on FreeBSD):sudo dtrace -n 'syscall:::/pid == $target/{}' -c "sleep 10"And I got a bunch of output, where it clearly sat for 10 seconds on:
2 80973 nanosleep:entryThen, to see exactly what goes on in the kernel for this process between
nanosleep:entryandnanosleep:return, I did:sudo dtrace -n 'BEGIN {trc = 0} syscall::nanosleep:entry /pid == $target/ {trc = 1} syscall::nanosleep:return /pid == $target/{trc = 0;} ::::/pid == $target && trc == 1/{@[stack()] = count();}' -c "sleep 10"Kind of hard to read but if you pull the stuff in quotes out you can see it’s using a variable called
trcand for this pid, when nanosleep is entered it sets the variable to1, and when nanosleep returns it sets trc to 0. Then, for any probe for this pid if trc is 1 then record the kernel stack. I got a bunch of output in that.Hopefully that is helpful. I’m not near a trace wizard so I’m sure there is some much more clever things one can do, but that might be a start to digging.
You can see probes available to you with
dtrace -l.
-
-
-
One can imagine a scenario where one of the nodes has a latency higher than it’s election timeout, causing it to continuously start elections
I have used Raft in production and can confirm this is a real thing that happens. Here’s an issue on the etcd repo discussing this problem https://github.com/coreos/etcd/issues/7970. basically: “a 5-node cluster can function correctly if two nodes are down. But it won’t work if one node has slow disk.”. Which is a weird failure mode!
also I found this post valuable, I’d never read the raft website/paper but this appeared in my RSS reader and it caused me to actually learn more about how Raft works!
-
Using Raft’s PreVote extension should alleviate this issue, though etcd’s current PreVote implementation could be more stable. See https://github.com/coreos/etcd/issues/8501, https://github.com/coreos/etcd/pull/8517, https://github.com/coreos/etcd/pull/8288 and https://github.com/coreos/etcd/pull/8334.
-
-
I don’t understand why these, frankly, childish drawings of things you can learn from reading a wikipedia article have reached this level of popularity.
-
I’d be the first to point out that I’m not a particularly talented artist. So why do I spend my time drawing comics, when I’m not even that good at drawing?
it’s because I’ve found they’re, in some situations, such a great way to communicate that I feel silly not taking advantage of it
A few reasons:
Comics are great for summarizing. I wrote a blog post at work about how we do service discovery. I started out with just writing 1200 words, and trying to be as informative as possible. I thought it was pretty good. But then I drew a comic summarizing a main ideas! A really common reaction was “wow, the blog post took me 15 minutes to understand, but after reading the comic I understood the main ideas in 30 seconds”. This is awesome because somebody can see the main ideas and decide whether they want to continue reading.
I can trick people into reading about concepts that they might otherwise think are too hard or not useful or not fun. I wrote a zine called “linux debugging tools you’ll love” (here). This zine discusses a lot of tools which are traditionally considered a little bit advanced. Because of that, a lot of people don’t even know they exist, or might not consider trying them! All kinds of people have told me “julia, i read your zine, and the next day I used a tool in it to fix a bug at work”.
They’re an awesome way to introduce people to new ideas. Anyone can learn about /proc! It is not that complicated. But a lot of people don’t even know /proc is interesting. This comic about /proc took me maybe 15 minutes to draw. I posted it on twitter and it got 180,000 impressions. A lot of people replied to me “wow, that’s so useful, I didn’t even know that that existed, I’m going to go learn more about that now!!”. They will probably learn more about it by reading the man page or Wikipedia or some more traditional means. But they learned about it from a silly drawing :)
Basically, I do it because I love telling people things about computers that help them (“omg julia, i had no idea about this, this, this is so useful”), and silly drawings turn out to be a pretty effective way to do that.
-
Because they have a carefully chosen tone that maintains a sense of psychological safety. If you’ve never been told off for learning I doubt it’d make a lot of sense.
-
-
-
I think someone making books for Linux beginners should consider offering her a job or gig making imagery for both common and complex stuff. She beautifully presents system calls, proc, signals, and killing processes. Her graphics might help the learning process for visual learners.
-
-
Well keep up your hobby. We definitely enjoy it. Might even turn into something profitable on the side one day if you’re lucky. :)
-
-
-
-
I went to Hacker School and I found that the social rules worked very well.
I’m not sure the Lobsters needs to be a place free of discussions of sexism. That works well at Hacker School for reasons that I can’t quite articulate, but there’s certainly a place for discussions of bigotry in the world at large.
-
Could call it “Dev Culture”
-
-
I do an awful lot of interviews. Sadly, few people ask questions like this.
It’s too bad because at least with me, I’m far more impressed with candidates who turn the tables on me and interview me as well. Far too many end up just trying to be “amendable” and “impress”. My advice to people interviewing is, don’t worry about fucking it up. Think about what you want in a job and make sure the place you are looking at will give you what you want. If the place is really good, the interviewer is probably going to be delighted that you asked more probing questions.
-
-
and if you don’t and end up somewhere were you only got the job because you didn’t ask questions? it fills an immediate economic need but we are talking about software engineering jobs. the ratio of supply to demand is greatly skewed towards demand.
-
Eh, I’m totally on board the ask-lots-of-questions train–I have been known to ask more questions of my interviewer than they asked me!–but let’s not pretend there’s not risk involved. For example, a company’s parental leave policies are a GREAT (maybe one of the best) indicators of their approach to gender relations and work-life balance, but as a woman of childbearing age there is no way in hell I’m risking an offer by bringing that up in an interviewing situation, even though I know that legally and in a perfect world that is not supposed to influence hiring decisions. (FFS, I feel the need to disclaim that I have no interest in taking advantage of anywhere’s paternal leave anytime soon, in case someone I know in real life is reading this!) Most of the questions under “quality of life” have similar implications that can potentially be negative; if you’re working against various implicit biases to begin with the risks involved in even planting that seed of doubt may not be acceptable. There’s other skews than demand over supply in the software engineering world…
-
i wasn’t trying to say there is no risk. i’m suggesting that not asking those questions mean you risk ending up somewhere you aren’t going to want to work and that has to be balanced again the need for gainful employment. we are fortunate as engineers that we can be more selective. unfortunately, due to various biases, some of us can afford to be more selective than others, but as a profession, we are blessed that we can regularly take this into account.
-
Agreed! I’d add that if you’re on the hiring/recruitment side it’s worth thinking about how your potential hires are weighing that risk vs information calculation. If the answers to any of those more risky questions are a selling point for your company, getting out ahead of that dilemma by volunteering that info up front or highlighting it in your job listings is a great idea.
-
i try to do that as the vast majority of the time, i’m on the hiring/recruiting side.
-
-
-
-
-
It doesn’t need to be tons of questions, but 3 good probing questions can easily give you a feel for what the company and environment are really like.
-
-
My advice to people interviewing is, don’t worry about fucking it up.
I think I understand the intended mindset this is meant to advocate, but I wonder if this works when I know I’m interviewing for my dream job? How do I not worry about the interview, when I, as the interviewee, already know the job is precisely what I want? This seems like a special case where my primary objective has to be to impress and possibly show I’m amenable (we’re talking about a dream job after all).
Further, what if I give the interviewer the wrong impression by asking questions that could either be interpreted as pedantic or intrusive? What if I give the interviewer the impression I don’t trust the company to get even the basics right? Leading with the impression that I’m concerned at once with small details most decent places are bound to get right or showing mistrust doesn’t seem like something an employer is likely to respond positively to. Conversely I do see how some of these questions might be interpreted positively, as showing an interest in the particulars of the job and how they relate to you as a potential employee–certainly that should be a positive signal to the interviewer.
However, if I know I’m interviewing for my dream job, I’m probably not wondering if they use version control, for instance. And asking a question like that seems like it could be a bit of a red flag or at best noise that could be avoided in favor of more relevant discussion. So maybe this list is potentially less applicable to an interview you know you can’t fuck up. In which case, I’m not sure I can walk into an interview without worrying if I’m going to make a misstep.
-
I’m actually going to send this article to a few peers, maybe even my manager. I live about 1h away from the office when there’s no traffic. If I want to encounter no traffic, I have to leave home at the latest at 5 AM, or no sooner than 8:45. This essentially means working from 6:00-6:30 to 15:00, or from 9:45-10:00 to 18:00. There’s also traffic on the way back.
I don’t want to get closer to the office because: this is my childhood neighborhood, I live right across the street from my parents (which is great when you have 4 kids and/or a cordial relationship with your parents), and the land + house that we have would be worth 2.5 ~ 3 times as much if I moved to a closer location.
Logistics aside, this is also much better for my concentration, I get much less often interrupted too. I need more of this.
one really cool side effect of having a remote-friendly team is that it makes it normal for people to work from home occasionally – one person on my team has kids and he’ll pretty frequently work from home so that it’s easier for him to pick up his kids from school or something, and it’s not an issue at all since half the team is remote anyway :)
My commute isn’t quite as bad as yours. When I started my current job, I negotiated the expectation that I would be working from home about half of the days. I now work from home 2 days a week some weeks and 3 days a week on other weeks. My commute is still terrible half the time, but on average it’s not a bad commute. I would phrase it as “I’m feeling burnt out because of my commute and I don’t think I can keep doing it 5 days a week for much longer. I would like to begin working X days per week from home so that I can continue to work for the company”. This doesn’t send an aggressive ultimatum, but it signals that you’re probably going to quit soon if they don’t accommodate you. If that doesn’t work, it’s probably time to find a new job.