Ask HN: Which headphones are you using? - <AUTHOR> I'm looking to get some high(er) quality headphones for everyday use.
Either for commuting or traveling, but also for sitting at my desk and trying to deeply focus on something or casual music listening outside in the nature.
A friend told me to look for noise cancelling headphones as they are great for traveling and besides that to buy something from "the big brands" like Sony or Bose.
Not sure if that really helps in case something is broken, but I think they still have a name to lose and are eager to produce good quality.
I had a look at the "Bose QuietComfort 35" and they look good to me, on the other hand Sony has some for around 100 Euro ("Sony WH-CH700N") with noise cancellation, too. Not sure if double or triple the price for the Bose gets me a long way or if I should just buy new ones in a few years when the ones from Sony are broken down.
So: Which headphones does HN recommend for everyday use? <comment><USER3> I have a Sennheiser HD 280 Pro which I love. I think they are supposed to be studio phones, so they have a fairly flat frequency response (which is what I want). They are also really comfortable--even with glasses; I've worn them all day for years. They only have 10 dB of isolation, so while they reduce office noise, they don't eliminate it. But the 10 dB plus some quiet music is pretty effective. And you can still hear when someone asks you a question (or pretend not to).

I think the "big brands" in headphones are Sennheiser and Audio-Technica, though, with Sony as a lesser brand, and Bose down there with Beats. But I'd recommend going down to your local music store with your laptop / music player and trying on a bunch of headphones and seeing what you like. I got the Sennheisers after a friend at work loaned his to me for an afternoon.

(On the topic of audio, I bought a MacBook Pro recently and I'm really impressed with the speakers. They are about 90% of the Sennheisers, the only weakness is that they are a touch weak on the bass [no surprise, the surprise is that it's only a touch weak].)

<comment><USER4> I also keep the HD280 on my office desk. I love them. They do a pretty great job at attenuating noise. I have taken them on planes and it's enough to put them on without music if I want to sleep. They are in fact really comfortable, but I do prefer them without glasses. My head starts to hurt after about an hour or so with my glasses on, especially if I'm wearing larger rims. But I think that any decent closed back set of cans is going to have that problem as they need to grip your head to make the seal.

It appears to be a pretty common consensus in headphone circles (read:head-fi) that Beats/Bose are decent quality but terrible value for $$$ (for instance, you'll get better frequency roll off on the HD280's we are discussing vs a set of Beats that often retail for 2.5x the price). Occasionally you'll read someone on the internet saying Bose or Beats are crap; they really aren't unless you're speaking purely in terms of what you get for how much you spend.

</comment></comment><comment><USER5> The best thing I ever bought in an office were the Bose QC25, I just can't see myself not using them. Anyone enjoying music and working in an office should really try a noise cancelling headphone it's a life changing device. The NC feature is even more impressive in a plane.

</comment><comment><USER6> I've been a happy user of these for a decade now: [https://www.koss.com/headphones/on-ear-headphones/porta- pro](https://www.koss.com/headphones/on-ear-headphones/porta-pro)

They sound amazing for a very reasonable price. Not noise-cancelling though, unfortunately.

<comment><USER7> I'll corroborate. I've owned $300 headphones, including some Sennheisers and Beyerdynamics. My $40 Porta Pros are my most used headphones when I'm not at work.

</comment></comment><comment><USER8> Check out this website: [https://www.rtings.com/headphones/reviews/best](https://www.rtings.com/headphones/reviews/best)

I recently went with the new Sony's after trying on a bunch of high end noise cancelling speakers in store. very happy with them so far: [https://www.rtings.com/headphones/reviews/sony/wh-1000xm3-wi...](https://www.rtings.com/headphones/reviews/sony/wh-1000xm3-wireless)

</comment><comment><USER9> Commuting/Daily: Apple AirPod Gen 1 (~220AUD at the time) Office / Airflights: Sony WH-1000XM3 ($350AUD) Others: MH40 for home listening / PC, Grado SR215E for Open back listening at home with Jazz etc.

AirPods for general day to day travelling when I'm not using a backpack. The Sony 'cans' for noise cancelling and concentrating and added Bass.

Previous Earphones/Headphones: In the last 5 years * Bose QC35 - Rubbish sound quality for a pair of 300+ headphones. Active Noise cancelling is very pressured, hurts my ears. Microphone picks up EVERYTHING! Do not recommend * Shure SE215 - Great sub $200 in ear canals with great sound quality. I broke mine cause I stepped on them, decided to go wireless. * RHA T20i - Great sound quality but the rubber on the earlets broke. I replaced them twice, was to expensive to send to London each 12 months so I gave up on them. Too expensive for this design flaw. * Master and Dynamic MH40 - Look cool but heavy and expensive. Sound quality doesn't justify the price

Recommendation: The Sony WH-1000XM3 is the bee knees!

</comment><comment><USER10> +1 to the Koss Porta Pros, and their cheaper sibling - the Sporta pro. They both sound fantastic, and are cheap. They do leak sound quite a bit - <USER2> standing in a bus next to you will know what you are listening to.

I've also loved the Sennheiser Momentum II wireless over-the-ear head phones. They sound fantastic, but are expensive. Their noise cancellation works well enough. They look great, feel great and sound great.

I am now going through a set of wireless Bose QC35 (series II). They are decent. They sound like a generic set of headphones, nothing to complain about, but not really good enough to get excited over. The active noise cancellation is buggy - severely distorts my audiobooks at times and I have to turn the noise cancellation off and on again to make it go away.

I also always carry my airpods - they sound ok, but feel very liberating. I'm strongly considering upgrading to airpods v2, but I've spent a bunch on headphones already :-) Not looking to spend any more money on headphones.

</comment><comment> Zack-sgu Sony WH1000XM3 for great ~$400 noise cancelling cans. I feel like I'm in a different universe with them on.

Only problem is that it's a little clunky switching connections between my phone and laptop. I also tried B&W PXs before that handled that a little better, but overall preferred the Sonys for the NC and comfort.

<comment><USER11> I bought a pair of the Sony wh1000mx3 and let my coworkers try them out, as we have a noisy open floor plan. Everyone who tried them bought a set in spite of the price tag.

My only complaint is that they don't support multiple device connections. I can wear these cans all day without discomfort too.

</comment></comment><comment><USER12> Sony WH-1000XM3: I've used several ANC headphones before. None of those come close to this. Sound quality is extremely good too. Good battery life. A 15 minutes charge gives me 5 hours of playback.

On the negatives: A bit heavier than Bose headphones but not by much. The "touch control" is sometimes annoying to use.

</comment><comment><USER13> Beats Studio Pro. I can't use modern Bose because they noise-cancel so strongly that I get severe nausea. They fold nicely (but only for height- width, thickness - earcup diameter - remains unchanged). Noise cancelling is effective enough to forget to turn off a faucet, double-tap power to disable/enable canceling without interrupting sound. Probably work fine enough for calls but I don't do that with them even though they support it. I often forget I have them on without any music playing, as they're comfortable and the noise canceling isn't intrusive.

<comment><USER14> > _I can't use modern Bose because they noise-cancel so strongly that I get > severe nausea._

Even on the "low" canceling mode?

<comment><USER13> Unsure, sorry. I think they now have 11 degrees of canceling of which I'm sure only a fraction make me puke, but the Beats just have the one level and it's safe, so I haven't made any effort to test Bose further given the risk.

<comment><USER14> > _I think they now have 11 degrees of canceling_

The QC 35 has 3 canceling modes: "High", "Low", and "Off"

<comment><USER13> I encourage you to write a review for OP if you haven't already, but it's been some time since I tested them and I won't be able to clarify further.

<comment><USER15> Actually the latest Bose model does have 11 levels of NC.

</comment></comment></comment></comment></comment></comment><comment><USER16> For everday use at my desk while working, Audio-Technica ATH-M50x have been my go to for the last couple years. They don't have noise cancelling, which I prefer for when I'm at work so I don't end up ignoring people when they come to my desk. The sound quality is really good, no complaints.

I do use Bose QC35s when travelling though. The noise cancelling makes airports and flying a much much better and less obnoxious experience. I high recommend them, but don't like them when I'm working.

</comment><comment><USER17> Sennheiser HD25: fantastic sound quality, bulletproof construction, easy to drive, and replacement parts (earcups, pads, cables) are readily available and easy to install. I've used them daily for a decade and have no regrets. No noise cancelation, but they block out ambient sounds well. One caveat: they are "on the ear" earcups... if you plan to use them for more than 2-3 hours at a time, then "over the ear" models may work better for you.

</comment><comment><USER18> I really prefer an over-the-ear headphone for an office environment because they keep out external noise and, I presume, leak less sound to my co-workers. After years of habituation, my brain focuses more when I wear them. I really liked a noise-cancelling headphone for airplane travel (when I was traveling a lot), but the one I had didn't have good enough sound quality for me for regular use. Although I like the sound quality of Apple EarPods, they don't fit me well and my eardrums feel assaulted after using them.

My two over-the-ear picks:

Sony MDR-V6: basically flat response, great price point (~100 USD). I can't compare them to higher priced cans, but I have enjoyed them for 30+ years. One difficulty, though, is that the ear pads can pop off (especially after they've been replaced once) so they require a little extra care when traveling.

Audio-Technicia ATH-M40+. I loaned out my MDR-V6 (long story) and I thought I'd try something different. ATH-M40 is also over-the-ear, basically flat response, similar price. I don't feel I get as much detail in the sound, though it's not dissatisfying enough for me to look further. They are much easier to travel with because they fold flat and the cord tangles less than the MDR-V6.

</comment><comment><USER19> A friend got me a pair of Nuraphones for my birthday and they've been great: [https://www.nuraphone.com/products/nuraphone](https://www.nuraphone.com/products/nuraphone)

Noise canceling, Bluetooth and analog, good battery life, awesome sound quality. They're a little weird as they use both cans and earbuds. It took me about a week to adjust to the feel but now I can wear them for long times no proble.

<comment><USER20> Ditto. Just put in an order for the NuraLoops [https://www.nuraphone.com/products/nuraloop](https://www.nuraphone.com/products/nuraloop)

Best thing about these (and original Nuraphones) is being able to still connect an AUX cable to them (think flying).

</comment></comment><comment><USER21> I have the WH-CH700N you mentioned. It was more of an impulse buy at Amazon, but they are fine headphones. I compared them in the meantime to other NC headphones in the low to medium price category and I think they compare favorable there. I found them more comfortable to wear than others (e.g. the Sennheisers), the physical control buttons are nice, Bluetooth works flawlessly, battery life is good, and sound is also decent.

The downsides are that one can only pair them with a single device at a time (all Sony headphones do that), whereas others can do two devices, and that the noise cancellation is a lot weaker than on the class leaders (Sony 1000XM3 and Bose QC35). Sound quality might be bit weaker too, but I doubt most people would notice. I might want to upgrade to one of those at some point of time.

If you have the money, use the headphones more often in noisy environments or just wear them often enough that the pricy doesn't matter too much investing in the class leaders certainly won't be a regrettable decision.

I wouldn't go for a non noise cancelling option now anymore. Even in my apartment the sound is better when I can block out the outside street noise.

</comment><comment><USER22> Some people (myself included) have trouble wearing noise-cancelling headphones for a long period of time. Something about the active cancellation is uncomfortable.

I have used a Sennheiser HD 380 for several years now and love it. It has better audio quality than my Bose QC25 (though not as good as something like an HD 650). It doesn't have active cancellation, but it is still pretty good about passively blocking noise.

</comment><comment><USER23> Over-ear headphones for me get too uncomfortable during the day, either too hot or they press down too hard on the sides of my glasses.

Currently using the Shure 535 in ear monitors - only real complaint with them is that the bluetooth adapter it shipped with was not hi-def so I ended up shelling out extra for one that is (was worth it though)

<comment><USER9> What adapter is that?

Does it use aptx?

<comment><USER23> [https://www.shure.com/en-US/products/accessories/rmce- bt2](https://www.shure.com/en-US/products/accessories/rmce-bt2)

"Support for multiple codecs. Qualcomm® aptX™ audio, aptX™ HD, aptX™ Low Latency, AAC, and SBC enable superior digital audio"

Not cheap for something that I feel should have been included with the headphones in the first place (seriously, the BT1 it came with was garbage), but it has made the world of difference to me.

</comment></comment></comment><comment><USER24> I'm using a cheap 40 USD noise canceling headphone from Amazon for the past two years and I have nothing to complain about it.

[https://www.amazon.com/dp/B01E3R87DW/ref=cm_sw_r_cp_api_i_Kv...](https://www.amazon.com/dp/B01E3R87DW/ref=cm_sw_r_cp_api_i_KvafDbGT24FVG)

</comment><comment><USER25> Audio-Technica ATH-M50x with a set of memory foam ear pads (the stock ones are uncomfortable). Great sound quality (bass is _slightly_ exaggerated, but it works for the music I listen to), extremely comfortable (I can wear them 12 hours plus most days and barely notice I have them on), and reasonable noise attenuation. Not noise cancelling, but with them on and any sort of music I rarely notice anything except loud background noise.

Only issue I've had is that a tab that holds the headphone in place has broken twice, though Amazon replaced it both times under warranty and I haven't heard of this being a widespread issue, so YMMV (this is over about 5 years of heavy usage, and one pair was an Amazon Warehouse pair to begin with - current pair is about a year old and showing no signs of the issue).

</comment><comment><USER26> Anything from these brands will be decent - Sennheiser, Beyerdynamic, Audiotechnica, Shure. If you're not actually producing music and just looking for casual music listening, anything within the lower price range($100-$300) should be alright.

Avoid Sony, Bose etc. Especially avoid Beats, they're a total scam.

</comment><comment><USER27> I use bluetooth Bose headphones day in day out day out, but in all honesty my next bluetooth headphones will be in-ear and non noise cancelling - e.g. AirPods.

In-ear headphones are orders of magnitude lighter than on-ear or over-ear ones. They're much more comfortable when you wear them for more than a few hours. And seeing how my on-ear headphone's ear cups look like a dog's chew toy after a year, I'd add that they're more durable to boot.

Perhaps most importantly IMO is that they _don 't_ have noise cancellation. There's plenty of situations where you most definitely do _not_ want noise cancellation, including but not limited to when walking outdoors or riding a bike to notice approaching dangerous situations earlier, and when someone you care about is trying to talk to you.

</comment><comment><USER28> Use cases, 200k miles of international flights/year, light gaming, listening to music/podcasts around the house.

For long haul air travel; Bose qc, no contest. You get on a plane, and all the serious business travelers are using the same headphones for a reason. They aren't the best (but are good enough) at weight, sound quality, comfort, but they are the best at drowning out engine noise. On a 7-12 hour flight that's pretty much the only thing that matters. I prefer the version with a AAA battery and a cord for the instant battery swap recharge vs the version that's wireless Bluetooth but has an internal rechargable battery.

 _Edit

Important note about the QC and other noise canceling headphones -some people feel a weird "pressure" or stuffy feeling from what I assume is all the work the active noise canceling mics/speakers are doing. It can be uncomfortable. I feel it a little when im using them, but for me it's a non issue if im playing music or sound through them. I do avoid using them without an audio input. Even when I sleep on the plane with them I play soft music.

If you read the comments below, it sounds like some people experience it worse than others. I strongly suggest trying before you buy at a local Bose store.

_ End Edit

For everything else, jawbra elite 65t. Decent sound quality, I can choose to only wear the right ear if I want better awareness of my surroundings(say walking the dog), good noise reduction b/c of the in ear seal and noise canceling (keeps the music volume low and protects your hearing), and Bluetooth means small and no wires. Battery lasts 4-5+ hours on a charge for me after 6 months of heavy use, wireless is nice, and the form factor is small and discreet (unlike air pods which scream im not paying attention to my surroundings). You can also turn off the NC.

In hindsight I wish I would have bought the active version with better water resistance for a few dollars more, but so far so good -they even lived through a trip in the washer machine.

</comment><comment> bra-ket Sony WH1000XM3, bloody amazing noise cancelling [https://www.amazon.com/Sony- Noise-Cancelling-Headphones-WH10...](https://www.amazon.com/Sony-Noise- Cancelling-Headphones-WH1000XM3/dp/B07G4MNFS1/)

</comment><comment><USER29> Sony MDR 7506. I got my first pair for monitoring to use with a Panasonic DVX-1000 video cam. I was so impressed I got a pair for my desk and have replaced them a few times over. I've tried may others' headphones but nothing beats it for midrange clarity and neutrality.

For my commute I'm using JVC HA-FXD80 in-earphones that I imported from Japan. Great isolation and sound. Again very neutral with clear midrange and no exaggeration of bass or treble. Surprisingly the wires are still fully attached despite being ripped out of my ears and catching on bags etc repeatedly.

Edit: I also keep a pair of Bose QuietComfort somethings around with no signal just NC and wear my in-earphones underneath them. Great combo on flights.

</comment><comment><USER30> AirPods + Sony WH1000XM series.

I use the latter for at-desk use (at home and work) and on airplanes. I use AirPods for everything else. Sometimes I even use AirPods at my desk when I don't feel like having something heavy on my head.

One thing's for sure - I'm done with wires.

</comment><comment><USER31> I have used and will continue to use Status Audio for my everyday headphones. [https://www.status.co/](https://www.status.co/) I'm really rough on headphones and cables so being able to replace the cables is really important. The overall design looks great and holds up to my abuse. If I do end up breaking the band, replacement cost is not going to break the bank. In fact, they've offered discounts to me for replacements even though it was 100% my fault.

Plus the sound quality is amazing and holds up to all but the absolute top end expensive brands.

I currently use the BT One for work and out & about use, and the CB-1 for home cabled listening.

</comment><comment><USER32> Bose is coming out with their next gen NR headphones next week. Might want to wait and see the full reviews. Its headline feature is reducing ambient noise from leaking into calls you make (like if you're making a call from a coffee shop). That may not be relevant to you at all, but it should also have slightly better NR and sound quality. You can also occasionally get deals on the Bose QuietComfort 25 model (under $150) which is the same as the QC35 except wired.

[https://www.tomsguide.com/us/bose-700-noise-cancelling- headp...](https://www.tomsguide.com/us/bose-700-noise-cancelling- headphones,review-6552.html)

<comment><USER33> I have the QC25s, they're great. Sound reduction is great when you need it, not too hot, good weight, great sound quality, decent when used as a mike. Plus fold up a bit so you can fit them in laptop bags in a pinch. If you want the noise reduction on all the time though, you'll be switching batteries every few days (easy to do). Wonderful on plane journeys.

Well worth the money.

Wired is slightly annoying, but my previous Corsair wireless headphones were too heavy and always seemed to need plugging in at the most inopportune moments.

</comment></comment><comment><USER34> [https://aiaiai.dk/](https://aiaiai.dk/)

Great and modular. Build them the way you want. If you're a member of FoundersCard, a nice discount too!

</comment><comment><USER35> I've been using the same pair of Bose noise cancelling headphones for the last 6-7 years and aside from needing to replace the ear cups they've been excellent. Sound is fantastic and the noise cancellation is genuinely the best I've heard. Replacing parts is quite easy and at least in Sydney the people in the Bose outlet are very helpful and friendly. If I was buying again today though I'd quite like something with bluetooth because the wires do get in the way a bit...

</comment><comment><USER36> You have to be careful with some of these big brand names. They tend to make a mix of good product and stuff that is sold at a higher price point with sexy marketing, but you're just paying 4x as much for the same audio quality as a $50 pair.

I've been tempted by wireless headphones, but I would personally stick with wired. Not a fan of noise cancelling. Depending on your budget, my brand choice from low to high would be Sennheiser > Grado > ZMF.

</comment><comment><USER37> I love my Beyerdynamic DT 990s. So much better than Sennheiser 598s or M50s in my opinion, but M50s are probably the best folding/portable headphones.

<comment><USER4> 990's and 598's are both open back so they are not really comparable to M50's. M50's are great though, a lot of people in my office use them. Though you did pique my interest with the 990's since I have a pair of 598's I use at home and I love them, so would be interested to check the 990's out.

</comment></comment><comment><USER38> My favorite 'around town' headphones are Sennheiser Momentums. Really light, comfortable headphones that sound great.

Along with these, @brundolf's suggestion of the Koss PortaPros is excellent. Cheap headphones that fold up small, but still give excellent output.

Personally, I would avoid NR headphones for a commute if you're walking at all -- especially in a city.

</comment><comment><USER39> Sony WH-1000XM3

I wear them everyday at work. Better than the BOSE QC35, and better than the new Bose 700's I had the opportunity to try.

<comment><USER15> How are they better?

</comment></comment><comment><USER40> I've had Audio-Technica ATH-M50X at work for around 5 years and despite having used them most working days they still look mostly new, and are quite comfortable for my (large) head.

Never had a set with NC, so maybe I don't know what I'm missing. However I can't hear much else at all when I'm listening to music.

</comment><comment><USER41> Bose QC35ii. They're probably my most used electronic device after my phone. I love them.

</comment><comment><USER42> I bought this one:

[https://amzn.to/2RDBR2U](https://amzn.to/2RDBR2U)

This one is pretty solid, very quiet and comfortable, I never experienced bad as few said, though u may check the reviews.

</comment><comment><USER43> Audeze makes great cans. I am not a fan of active noise cancelling headphones.

</comment><comment><USER44> Bose QC35

</comment><comment><USER45> V-moda Crossfade. I have a pair at home and one at work.</comment>


Ask HN: How to get a small team off the ground remotely? - <AUTHOR> A group of friends and I won a pitch contest at our university and decided we want to pursue the idea and try to start development. However, break just started and I am struggling to decide what the best way to organize the team/get started is, especially considering we are all over the US for the month. <comment><USER2> You need a cloud based means to communicate and also a cloud based means to start working on the project. There are various tools for doing that and you might go through a few before you find a good fit.

For collaborating remotely, I use a lot of email, shared google docs, private blogspot blogs where I can invite other authors and even Twitter. Of course, Slack, Trello, Github and other tools are popular in the development community. If possible, use something familiar. Trying to learn a new tool can be a project in its own right. If it isn't critical to the success of the project, don't do it. It just becomes a means to procrastinate.

If you have nothing, start with a design doc. If there are no roles assigned yet, take the initiative. Set up a file, start a Google group or a Slack channel, list goals and start hashing out who needs to do what.

You need a central repository. It does not have to be fancy. As your project grows, layers of organization can be added as the need for such becomes clear.

Just start. No more excuses. Expect the first attempt to be ugly, bad and stupid. Do it anyway.

Best.

</comment><comment><USER3> Communicate! I am managing a team of highly qualified employees across the country and I have booked every Wednesday from 2pm to 4 pm or more to discuss not only work related items, but life , universe and everything... this really creates a good bond in the team , so I would suggest do it even once a day if needed...

OR just enjoy the vacation for a month and start when everyone is back, some people just cannot be trusted to step up and work unsupervised unfortunately...

</comment><comment><USER4> The following has worked marvellously for me. More than half of my team is remote: 1) Sync up once in a day - at a fixed time - for a fixed duration, with a clear agenda for every one to tell their plan for the day. 2) At EOD every body share a two liner update on Asana.

</comment><comment><USER5> Gitlab/Github, slack and Skype or hangouts. These are the tools I use everyday to handle coworkers in other offices on my projects.</comment>


The art of interrupting software engineers - <AUTHOR> https://content.pivotal.io/product-managers/the-art-of-interrupting-software-engineers <comment><USER3> > I followed my mentor's advice and started to check-in at least every half > day with each pair of engineers I was working with.

This is monumentally bad advice.

> I try to find a time when a pair does not seem to be heavily focused. Some > of the cues might be they are having a casual non-work related conversation > or are just returning from a break

So surveill and/or eavesdrop and/or ambush. Nice.

> Hadrien Raffalli is a Product Lead at Pivotal.

Here's me thinking it's probably a more junior PM doing this. Nope, it's a Product Lead.

PMs/TPMs can be great, if they are good. I've worked with some that made my life easier. I've worked with others who really didn't.

Based on this article alone, Pivotal's PMs would make me quit.

<comment><USER4> Pivotal is well known for having a particularly extreme point of view, bordering on forthright religious fervor, when it comes to pair programming and taking highly bureaucratic versions of Agile development to an extreme.

Pivotal can deliver things to customers _in spite of_ all this (given that it's surely not _because of_ all this), which sort of makes any advice published out of there fundamentally irrelevant for people working pretty much anywhere else.

<comment><USER5> As far as I know, Pivotal's process is based on Extreme Programming (XP), a process which deliberately takes an extreme point of view. (It's in the name.) It's not bureaucratic, but it is demanding.

I have a lot of experience with XP. In my experience, XP succeeds _because_ of its extremeness, not _despite_ it. It's not for everybody, but for organizations and teams such as Pivotal who are willing to understand and embrace it, it works very very well.

So I challenge your "given that it's surely not because of all this" comment. Do you have any evidence? Or are you just saying, "I don't like this, so it can't possibly work?"

<comment><USER6> Taylorism worked -- it decreased costs for companies, but people suffered -- they couldn't find meaning in what they do, their every move was monitored and choreographed, and they were squeezed for the last bit of efficiency possible.

The kind of "pairing all the time" kind of XP that is being preached is similar for programmers. It also works for repetitive work - building yet another web application - at scale, not at scale, not much of a difference. But programmers often get into the job because it is an inherently creative field. There is nothing like this kind of XP to suck it all away and leave them disillusioned about the craft until they escape and find a product role or even a consulting company with more empathy and kindness.

<comment><USER7> I'm another person who has done a fair amount of XP. Definitely some people feel this way. Some people do not. Personally, I really enjoyed it. I enjoy working with people. I enjoy shared experiences. I found the atmosphere to be challenging yet friendly. Quite often solo programming can be lonely. Sometimes you wonder what people think of your code. Sometimes you hear all too well what people think of your code -- three days after you could have done something about it ;-). In the pure XP teams I was on, I had a lot less conflict overall -- mainly because you are kind of forced to deal with conflict up front.

However, we had a few guys on our team that _really_ didn't like it. They left and I don't think less of them in any way. It's a different way to do things.

As for the "repetitive work" aspect: the most successful XP project I did was a collaborative sketching application using pen input with automatic shape recognition: somewhere around 2000 (when did MS put out those pen based computers??? -- We did it for their unveiling).

<comment><USER6> This conversation is probably moot in teams where programmers are actually empowered to make their own decisions. In that case XP is fine, if you enjoy it, which makes it sort of a tautology.

The problem though is the Agile Industrial Complex and "thought leaders" who have pushed this as a religion on the industry. I enjoy pairing, and the excitement of two minds working at the same problem in tandem is an experience to be relished. But give it to an Agile snake-oil salesman, most of whom gravitated away from programming a long time ago in favor of making money training others in how to program, and they'll wield it as a weapon by prescribing the only true way to work.

<comment><USER7> Well, I won't disagree. I've had the moniker "Agile Coach" before it was ever a thing (I though I'd invented the term :-) ). But I have never been a business consultant. My "coaching" was exactly what you would expect from a sports coach: I helped the players, not the management :-).

XP (in its traditional sense) doesn't scale past 8 developers anyway. Anybody selling you XP for a team of 500 is someone to be wary of ;-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> There seems to be a lot of misunderstanding about this article.

First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams:

1) All production programming is done in pairs, all the time.

2) Everybody sits in a shared team room at dedicated "pairing stations."

3) The atmosphere is highly collaborative and friendly, and there's always a low buzz of conversation in the room. Interruptions are normal and expected, as the team's overall performance is valued more highly than individual performance. Due to pairing, interruptions tend not to interrupt flow.

4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out.

5) The team values feedback and wants frequent conversations with their on- site customers (including the product manager) to confirm that they're on the right track, particularly about nitpicky details that are difficult to anticipate in advance.

Given this context, the author is talking about how he, as a product manager, does his job of providing business context and customers' points of view.

This material is not meant for people who aren't on an XP team. It's good advice for product managers who are.

<comment><USER8> This sounds like the most horrifying work environment I can imagine. I have to assume that all XP developers are extroverts, because as an introvert this would be a living nightmare.

<comment><USER9> I'm extrovert as hell and I like pair programming...but not having "what are we going to do" written down, combined with a constant hum of conversation in the background sounds awful.

<comment><USER10> Depends how hard the problem is you are working on? I could totally imagine solving easy to medium problems in that environment. For hard problems I'd probably leave the room and think alone till I have something worthy of discussion

<comment><USER9> Me: "What was the problem again? I forgot." 5x times until my pairing partner just does it himself while I try to stay focused and follow along.

</comment></comment></comment></comment></comment><comment><USER11> > 1\. Check-in regularly

> I followed my mentor's advice and started to check-in at least every half > day with each pair of engineers I was working with

Uuuuhhh...

If a PM did that with me when I have a lot of work to do it'd send me off the rails.

This article seems more to be about "what I have done as a non-technical PM to reduce my own anxiety at the detriment of my team".

It's hard to say without a lot of detail, but I think there's something disfunctional about the team or about how the project is structured in this example. How big are the tickets? It's common for a "user story" to take days or weeks; it can say something simple like "user can submit a form" but have a lot of big system dependencies that were not well thought out (a form system, a state system, a server component, etc).

Instead, tasks must follow a technical logic (a form system first, state management after, etc) and engineers should be left to do their own thing, with minimal "checking". Something like BaseCamp's "Shape Up" [1] comes into mind, with a few bets every cycle.

1: [https://basecamp.com/shapeup/](https://basecamp.com/shapeup/)

<comment><USER12> I would pretty much quit if someone came and interrupted me in person twice a day to ask me how things are going?

In my decade of experience i've usually seen new PMs be extremely anxious and paranoid about timelines. As they get more experience and they see more projects that go off the rails they understand the tech speak a bit and have laxer expectations.

Sure we'll be 2 weeks late, but in the grand scheme of things, it doesn't matter. Don't burn your engineers for a dumb deadline that makes little difference to the customer.

There's a reason we have kanban boards and sprint boards. How are things going? Look at the board. The tickets are updated. Any blockers? Read the slack channel. Only interrupt in person when shit is really on fire. But even for that, the monitoring software will page the opslead.

</comment></comment><comment><USER13> I'm a PM and this does not resonate with me. If you're getting status twice a day... I think something is very wrong.

The brutal truth of software development is that the quality of your output is going to vary with the quality of the engineers you work with. Good engineers don't need daily standups to build great products, and bad engineers aren't going to be helped by doing twice-daily checkins.

<comment><USER14> I think you jumped the shark here. The point of doing multiple checkins a day is to make good engineers feel like they are barely good enough, and make them hungry to please the bosses! Pavlov at work here, I think.

<comment><USER15> I'm not sure you're using "jumped the shark" correctly.

<comment><USER14> Sorry. I should have read before using that phrase.

</comment></comment></comment></comment><comment><USER16> Seems like engineers are not trusted to do their job. I mean if you hire lots of inexperienced engineers, fair enough, but I certainly wouldn't work at Pivotal.

If my PM was constantly worrying about whether I was distracted, or working on something outside of the backlog, I wouldn't be too happy about that. As an engineer, part of my job is to prioritize my daily and weekly tasks, and to avoid getting distracted throughout the day. Unless their is a hard deadline coming up soon (in which case it is helpful to check in with the PM so you know what to cut), requesting status updates on stories on a daily basis seems like way too much. If you want a window into what I am doing, come to standup (which should be async most of the time anyways, IMO).

I've worked at a company founded by people from Pivotal, with a very similar culture, and I'm not very surprised by this post. There were a lot of new bootcamp grads and more inexperienced developers, so the company didn't really give them the same freedom that developers are used to. Everyone pair programmed all the time, even when doing basic UI work (super exhausting), working hours were fairly strict, and work was broken down fairly finely. For better or worse, developers were treated more like just people who can write code, for the most part, rather than people who are able to intelligently prioritise tasks and take initiative on things that need to be done.

<comment><USER17> The point at Pivotal is that stories tend to be less than a day to implement. If they take longer than a day (or two), something is very wrong with the estimate, and the PM might be able to help shift priorities.

</comment></comment><comment><USER18> You know what I don't get about status updates? We're all using tools like Jira, Trello, _Pivotal_ Tracker, GitHub issues, etc., where you can see what everyone's working on and the status of each of those tasks. Why do we need frequent status updates like standups and PMs looking over our shoulders if you can _just go to the project board_ and look for yourself? If I'm going to be asked about the status of what I'm doing every day, then don't make me use these systems.

It's like that episode of Seinfeld where Kramer pretends to be Moviefone. "To update the status of your ticket, press 1 now. .......... Why don't you just _tell me_ the status of your ticket?"

<comment><USER19> Your team needs excellent JIRA hygiene for that to actually work. I've been on and managed teams where it's expected and demanded and others where it was an afterthought.

<comment><USER20> Our JIRA board is being gamed for management. Our sprint burndown chart always looked terrible because management changed things around mid-sprint by adding issues or swapping them around. So we have a fake JIRA board that has a perfect linear downwards progression because we keep changing the story points.

For actually tracking the progression of the sprint we have a secret Slack channel that management can't see.

This way we don't have to explain to a spreadsheet monkey why the burndown chart looks like a skyline.

<comment><USER21> > Our JIRA board is being gamed for management. Our sprint burndown chart > always looked terrible because management changed things around mid-sprint > by adding issues or swapping them around. So we have a fake JIRA board that > has a perfect linear downwards progression because we keep changing the > story points.

This makes me so sad.

The jagged burndown chart should be the perfect tool to explain management that you didn't finish the sprint BECAUSE MANAGEMENT CHANGED OR ADDED THINGS, and so visualize the cost of such actions.

</comment></comment></comment></comment><comment><USER22> Is it really common for software engineers to work under these conditions? As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup and thankfully Jira was recently dropped as it was considered more trouble than it is worth (management just wanted to know the big things going on and not all things). Of course it's better than plenty of other jobs, but the constant treatment of employees like they're on an assembly line sounds rough. I know software development is tough and respect those that do it. I have critical time sensitive tasks and I'm expected to have them completed on time. My manager might check in once a month on a year long 1/4 million dollar project among all the other work I do. I know that's peanuts compared to a large software project, but still.

<comment><USER23> It depends a lot on the company. I've been fortunate enough to avoid companies like the one posted, but there really are two (maybe three) views of developers:

1.) Treat them as engineers who are capable, able to communicate problems or expected delays, and professionals who want to grow. 2.) Treat them as assembly line workers who constantly want to screw around and need to be whipped back into shape.

I'd argue maybe a third is the startup mentality where you need to sell your life to the company, but maybe that's a mutually exclusive thing.

In my experience, the second comes from the same mentality as the old waterfall companies. Spec everything, trust no developer, micromanage, etc. Developers are a risk, not an asset, and never trust them at a management level. I would never work for a company like that, and avoid them like the plague.

Regardless, both of the views above seem to be a self fulfilling prophecy. Professional shops who treat developers as engineers produce some quality stuff and usually on time. Sweat shops have a lot of failed and over-budget projects and a high turnover.

<comment><USER24> In my experience "the old waterfall companies" are the ones where the engineers are trusted with a task and left to do their thing. In such an environment, managers are only there to assist the engineers. I.e. escalate issues, provide ressources etc. and most importantly: fight for their team/department in meetings. We go to our team lead only when it is necessary and he only asks for updates when he needs to report our status to a superior.

What I have witnessed in those hip, agile young companies is that you have to report exactly what yyou have done, what you are plannign to do etc. constantly. At least once a day, plus whatever other weekly meetings you are in. Sometimes your entire day is filled with meetings and you are supposed to fit your actual work somewhere in the breaks. And if you can't finish a task in a day, you trigger extra attention from managers and suddenly you find yourself sitting at your desk with another engineer and a manager looking over your shoulder, wasting hours of expensive time instead of letting you work.

Those are the two extremes I have encountered and they are only annecdotes. But they do serve to show that the development process chosen for a project is not tell you anything about the management style.

<comment><USER17> What's odd about the "agile" companies, is that while you are a designer or engineer in product mode, you're not supposed to attend _any meetings_ beyond daily standup, weekly IPM, and weekly retro... Maybe the odd town hall. Maybe the odd inception day or cross-team retro every few months for a major new initiative. But that's about it. PMs do attend other meetings mostly as a liaison to the outside world, because that's the gig, but even then, it tends to be limited.

The whole _point_ (at least at Pivotal) is to spend more time coding/designing/testing and not in meetings.

</comment></comment></comment></comment><comment><USER25> Here is a missing advice in the art of interrupting software engineers: don't. Use asynchronous messaging, not alert-based messaging. Send emails. Make sure they read emails once a day and only interrupt if your question is really more urgent than that.

Thanks.

Daily meetings are not good. They waste people time and constitute an interruption. If you can sync the whole team so that the meeting happens on the morning before people start working, that's better, but still not good as you are imposing a schedule on a team that may know better.

I just finished a deadline at 2 am yesterday. My team is sane and did not expect me in the morning today (joined the slack around 11 am). Would not have done that if I had a daily at 9:30 am. I would not only have missed the deadline but the daily would have even further delayed it. What's more, I would have spent some time preparing it because I would feel I need excuses ready in case someone starts a blame-game.

If developers time is precious, don't waste one hour per day on dailies/daily preparation.

<comment><USER26> 16 people in the daily, 1 hour every day (because we are 16). That means 16 man hours a day are for the daily. 2 people work full time to have the daily. Crazy.

</comment></comment><comment><USER27> There are two times of the day to catch software engineers: the start and end of the day. Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in.

The team I joined - 4 developers and 1 manager - goes for a coffee walk in the morning. The manager waits for us to go through email and other communication that came in overnight. Then we walk to a nearby coffee shop. On the walk, we discuss issues and what we intend to accomplish for the day. It takes about 20 minutes.

Occasionally, we take a walk at the end of the day as well to discuss issues. When the manager calls for an end of day walk he senses our energy is low.

As I get older, I like routines in the morning. They help me get my mind in gear. We go for the coffee walk. When we get back I might read a short technical article. Then it's time to get stuff done.

<comment><USER28> I'm going to sound really entitled saying this, but I hate morning status meetings because they eventually end up being used as a "this is a reasonable time to expect you to be in the office by" kinda measuring stick lol. It ends up leading to unnecessary stress trying to make the damn 'meeting time'.

<comment><USER29> I know engineers are in demand and we are a high priced commodity but is it unreasonable for a company to expect you to be in office at a certain time? The standup at my current project is at 10:30. And most of us here come around 10.

<comment><USER27> It's not unreasonable. My team is usually in by 9, 9:30 at the latest. We take 20 minutes to get coffee and discuss issues, what needs to be done, etc. Then we set about completing tasks.

A startup I worked at in the mid-90's had people working in pairs: a server developer and a client developer. They didn't care what hours you kept as long as you didn't hold up the other person in your pair. I arrived around 9:30am daily. The client guy I was paired with came in around 8:30am. I always stayed later so I'd check in code before I left and leave a message for him about the progress. He tested stuff before I arrived and went over any issues when I got in. Then we'd work together the rest of the day. Other engineers came in at 10:30am, noon, and as late as 1pm. They worked it out with their other halves the same way I did.

I think wise managers work with the team, minding company-imposed limitations, rather than enforce personal preferences.

</comment></comment></comment></comment><comment><USER30> I honestly can't tell if this is a terrible practice or just the worst possible way to describe it for the HN crowd.

People who end up in manager roles tend to be _people persons_ and some use very touchy-feely language. I'm personally put off by all the references to his own anxiety as just one example. That doesn't necessarily mean he's actually a terrible manager.

Part of his job is to make sure things get delivered in a timely fashion. If that's not happening, then feeling stressed by it isn't unreasonable, but the article sounds like he's just trying to manage his emotions rather than get deliverables from his people in a timely fashion.

I'm not posting this to dog the author. I'm posting this to suggest that his framing may reflect the fact that his job involves managing people rather than things.

If it were framed differently, the exact same practices might sound much more reasonable and palatable to people here on HN who are overall reacting fairly negatively to this.

<comment><USER6> I've also seen that programmers who're not really good at the job, but don't have qualms about playing politics often end up managing the teams they were unfit to work in in the first place. They were not necessarily better at people than others. The idea that programmers are not good with people is, in my observation, a self-perpetuating stereotype. Mostly because if you're writing code, you are on a maker's schedule and you don't have much time or bandwidth to think about anything else. Managers on the other hand have more control over their time and can for example spend an hour to decide exactly how a conversation should go before they speak to someone. They can reflect on it, and deliberately improve over time. The programmer on the other hand would be figuring out why a particular technical decision was wrong and how they can identify it next time etc.

<comment><USER31> Spot on!

>The idea that programmers are not good with people is, in my observation, a self-perpetuating stereotype

It was never true. It is a TV/movie stereotype just like the term "Hacker".

</comment></comment></comment><comment><USER6> The Art of Micromanaging Software Engineers!

Here's the thing: as programmers we sometimes have a bad day. Sometimes a bad week or two. Sometimes there is unresolved ambiguity in how something needs to be done that we tend to procrastinate on it until it becomes clear. When you're working through an agile/XP backlog - a never-ending backlog mind you - you're expected to produce at a consistent cadence, not much different from laying brick after brick, but unlike construction, this one is an infinite pool of uninteresting work.

This is common in consulting work. Agile and XP were created by consultants to create predictability in delivery. It makes sense for that context - <USER2> are often far removed from the consultants, there is no intrinsic alignment between their incentives, and being external people there is always an information gap in what is best for the company and whether the contractors are making actual progress.

So you need a way to smoothen this out. Transparency, constant communication, a structured process, consistent cadence, measurable metrics, and most importantly number of hours with your bum on the seat.

When consulting companies start out, there is a distinct messaging on their websites: "we don't want to be just consultants, we want to be an integral part of your team" or suchlike. See, we also want meaningful work, we want to truly participate in your business. But as consulting companies mature they realize this is not a feasible approach at scale. While external messaging might not change, internally they realize the business is about selling X number of hours in a year per consultant, with a percentage of their earnings as your profit margin. To make this work, you need Agile/XP. You need to bring Taylorism back into the world of programming. That is just the systemic incentive of this sort of business. Companies that fail to realize this and change accordingly (the idealists) go out of business very fast. Others thrive.

Within this system it is still possible to have meaningful work for developers (I've worked in such companies, and I've enjoyed it). But if you have a micro- managing PM like in this article, then better run for the hills or you'll find out hating IT and fully burnt out in a few years.

<comment><USER31> Amen, Brother!

Do us all a favour and send this write-up to every XP/Agile/Scrum/Whatever acolyte that you come across :-)

</comment></comment><comment><USER32> > This was mostly me passing by and asking how things were going

Hello Peter whaaaat's happening?

<comment><USER33> Yeah I cringed when I read this bit. If any managers are reading _don 't fucking do this_. Your intentions may be benign (this person apparently thought they were) but most devs are going to read this as veiled micromanaging and get just as stressed out as the earlier approaches in the article.

Just use scrum as intended, maybe push for more detailed updates if devs are just saying stuff like "still working on x". Or just trust them and don't try to babysit.

</comment></comment><comment><USER34> Thank you for reminding me how much I dislike working with PMs

I especially can't imagine working with this one. Imagine constantly having to revise estimates and getting micromanaged by someone who isn't your manager. The "role responsibilities" conversation would happen very quickly

I find it especially ridiculous that this person is interrupting people two times a day for fresh updates _on top of a daily standup_. And they even admit their technical knowledge is not good enough to actually be able to help much if there is an issue. If you are bothering and interrupting every single person on your team multiple times a day just in case you need to increment a number in a JIRA board now instead of tomorrow morning, you are wasting people's time. Leave it to the standup.

Your job as a PM is not to micromanage engineers. If that is anybody's job, that is the engineers' managers. Your job is to make the engineers more productive and make sure they're working on the right things - but not at an hourly granularity.

<comment><USER35> I agree with everything you wrote, but I also wonder if this is less of a distraction in the case of Pivotal since their engineers work in pairs.

<comment><USER36> Less distraction? Unless you are doing cookie cutter crap, you sometimes need to be able to walk away from your workplace for an hour or two to have good ideas; frankly, I've worked with some of the best scientists on this planet and it was common to see them leave their desk for an hour and walk around the block to clear their mind once a day or so.

Moreover, I recently fell into the trap of working for an entire week nonstop to solve a really hard problem. Took a few hours off one day to clear my mind and when I came back, I had the problem solved inside of an hour. If I continued down the route I was going down before that time off I can guarantee you it would be more days wasted.

<comment><USER35> I don't understand how your comment relates to mine.

</comment></comment></comment></comment><comment><USER37> I work for Pivotal. Product managers vary in how they work with a team, so this approach is new to me.

As an anchor (approximately a tech lead) I made it my business to work closely with PMs on the product: giving feedback on how the technical direction was shaping up, asking for stories to be updated or broken apart, giving options for technical seams and so on. Frequently we embed product designers as well, so discussing design options and asking for modifications was common.

But when I was pairing with another engineer we did whatever was on the top of the backlog according to our best judgement and with attention to quality. If it needed refactoring, we refactored. If we felt that would be better to wait, it would wait.

The most important discussion, I found, was about chores -- work that engineers view as paying dividends in future velocity. Our view is that engineering is the ultimate owner of chores and can schedule them according to its considered discretion. The system works because of trust. I trust that product managers and product designers will be diligent in identifying user values and priorities. They can trust us to do what needs to be done to make the software to a sustainable high quality.

I remember once I was rotated in as anchor for a product that had begun to struggle a bit. In particular we had a particular giant tech debt: we had fallen behind on React versions. Worse, there were three parts of the codebase using React, in three different ways. With my peers I decided that we were going to fix it. "I think it will take one pair week", I remember saying.

It took five weeks. But nobody ever said: stop, you work for me, my way or the highway. We talked about the reasons. This tech debt would only grow as time passed. There was no good time to repay it, so sooner was better than later.

We were trusted to do the right thing, so we did the right thing.

<comment><USER38> You should probably have your management team look at these comments. How much hated it is getting. I can say from experience that I have quit because of a manager like this. Don't do this. You will lose any engineer that can get another job and be left with those that can't jump ship. I'll let you determine the quality of those engineers.

<comment><USER37> If it's not already blazing on a dozen slack channels I'd be surprised, we are a tech company after all.

As I noted in another comment, I would give feedback to a PM that this kind of checkin isn't necessary and try to understand how to help foster trust.

At Pivotal I have worked with 9 or 10 product managers, none of whom have asked during the day how things were going.

If anything I would be the one interrupting them.

</comment></comment></comment><comment><USER39> If I had a PM come by my office twice a day to "check-in" I think I'd quit.

<comment><USER40> Pivotal also has thing where everyone is expected to pair program all the time. I think I would despise the environment but it's clearly not for everyone, myself included.

<comment><USER41> I thought I would hate pair programming, but it turned out to be, BY FAR, the best thing that ever happened to me professionally.

That said, it really isn't for everybody. But you may want to give it a chance.

<comment><USER42> You also need somebody good to pair with. It can be really infuriating to have to deal with someone who can't keep up but on the other hand if you work with someone you respect, it's great.

<comment><USER41> Yeah, pairing is a _learned skill_!

If you put two random programmers together and ask them to "pair program", you'll very likely end up with two annoyed people at the end of the day.

I was lucky in being mentored into it by some very seasoned pros, and I learned the tricks of the trade that way.

</comment></comment></comment></comment></comment><comment><USER42> One trick a lot of PMs and other managers don't seem to understand is to listen and really understand what people are dealing with. If people are complaining about something then listen and see if you can improve the situation. It doesn't help to constantly ask "When is it done?" but you should ask "How can I help?". And then really help and don't just set up more meetings that don't result in anything.

Also, learn how to use JIRA or whatever tracking is being used. In my company managers doesn't bother to look at the JIRA board so you end up reporting the same thing five times to different management levels.

In short, be less controlling but try to help and treat people like professionals who know what they are doing.

</comment><comment><USER43> This should be called the art of micromanagement. It's complete bullshit. I've worked under such conditions for a few months and I came very close to quitting. I didn't quit because it eventually stopped but I was considering some offers. This is one way to get your top engineers to quit. Why even hire product managers if this is what they think the job is? Save money. All they will do is slow down your team. Measuring time estimates in hours is also ridiculous especially when one has multiple things to work on. If this guy was a product manager in my company he'd be looking for a job in the morning.

</comment><comment><USER44> I see a lot of anxiety in the article. This sentiment is going to permeate through the team!

As a developer, all I need from management is clear priorities. Let me know what the business needs, and keep reminding me what those are in case I get lost into code. Create chunks of time where the priorities don't change so I can focus. The bigger the chunks the better.

Then let me do my job please! I need to be able to trust that management is picking the right priorities, and management needs to trust that I am able to convert those into code. Trust is paramount.

If you can do that, I will be 10x more productive than any of these pseudo management techniques. It doesn't matter if we do scrumm, agile, daily standup, use Trello or some other tool. These are just implementation details. Let the developers pick whatever they are comfortable with.

</comment><comment><USER45> Software engineers aren't special. Literally any job that requires a modicum of concentration, whether it's writing marketing copy or doing complex financial forecasts, means that interruptions are costly.

<comment><USER46> I once had a boss (legal - so lots of drafting/reviewing) who had a rule: no meetings & no drivebys before lunch. For anyone on the team. Calendars were expected to be clear from 9-1. He'd say "If you aren't sprinting down the hall to talk about it then it can wait until after lunch."

Of course there were "emergencies" and things so it was more like a team standard than a rule but it was phenomenal. When I got to my desk in the morning I always knew I'd have a solid block of time to get through the important work before I had to go to a bunch of meetings and take on more.

</comment></comment><comment><USER47> I've found the best way to avoid interrupting engineers is to have a daily sync (a.k.a stand up meeting). My team meets for 30 minutes each morning to give an update, have Q&A, and discuss priorities and issues. We're a small team (3 developers) but it works perfectly because folks either had their inquiry answered earlier in the day or can execute good judgement to try to figure it out and if not ask about it tomorrow. We all receive tickets and if it's critical enough we'll meet to devise a plan. Under this scheme we are rarely interrupted and have been grinding through features all summer.

<comment><USER48> A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams.

edit: at the most, I think async are passable via slack or something similar. Otherwise all data on this can be easily done via a Kanban board.

<comment><USER34> I like daily syncs if they are done quickly (<15m), and if people are working on different-enough things that they don't really know what their teammates are working on. Because that way you can unblock each other and actually use agile the way it was meant to be done in the face of underestimated tasks or changing requirements

<comment><USER37> In my experience anything more than 10 minutes is a smell. It typically means you've got stories that are too big, have unaired problems, that you dive into implementation instead of just syncing briefly, or the team has too many people.

<comment><USER34> I personally think brief dives into implementation / explanations of issues is fine. If something takes only 5 minutes to discuss between everyone, I'd rather do it while I'm already in a meeting, and having the whole team there helps opinions get heard. But this is just personal preference

</comment></comment></comment></comment></comment><comment><USER35> I don't see the point in getting updates more than once a day. If something could change that you needed to know before tomorrow, isn't something else potentially wrong with the process?

The only case where I want such frequent updates are when (1) there's some P0 bug on production and it needs to be fixed / tested / deployed yesterday or (2) we're trying to pressure the person to want to quit their job or magically improve (more the former than the latter).

</comment><comment><USER49> I only read the first paragraph and couldn't read anymore. I'm unsure why he cannot Know when a story will be delivered. A story should fit into a sprint and so he should reasonablely expect that it's delivered at the end of that sprint. If it's not going to be delivered then this information should be relayed back to the pm.

Going and pestering the team is only going to slow down development process and increase the likelihood of the team not delivering for the sprint.

<comment><USER37> Pivotal doesn't use sprints. Stories are pointed by engineers and ordered by the PM, but they're done when they are _done_ , to the satisfaction of both.

Tracker is able to give short-term forecasts of what will be done by when by averaging the last 3 weeks of deliveries (ie, velocity).

Personally I think the idea of sprints is a menace. It creates an artificial deadline that leads to either waste or stress. Deadlines should be reserved for actual meaningful deadlines.

<comment><USER49> I think that artificial deadlines and stress exist because the team and management allow it to exist. A story should fit into a sprint, but it may spill into the following sprint, but you shouldn't sacrifice quality just because you tried to finish it within the sprint. And a team should stand up for themselves in this regard, as a team, because a team succeeds and fails together. If you sacrifice quality because of some artificial deadline you put in place then you're only going to suffer maintaining that later on.

<comment><USER50> I think two core ideas of sprints are to 1) combat Parkinson's Law by creating an artificial deadline (the team should try to solve things within the sprint) and 2) protecting the team from changes (avoiding that requirements change all the time)

With that in mind, sprints can work pretty well, and work "spilling over" to another sprint is generally no problem. It starts falling apart if the artificial deadline becomes a forced deadline, or if the protection part is dropped.

</comment></comment></comment></comment><comment> rv-de First I hoped for a parody but now I'm left unsure whether this is meant serious or not.

Especially this (joke?) is hilarious:

"I followed my mentor's advice and started to check-in at least every half day with each pair of engineers I was working with."

But I suspect he is not at all trying to be funny and, I'd say, it is utterly terrible advice from some PM fitting right into what seems to me a work environment turned buzzword hell.

</comment><comment><USER51> Wow, where do we start here? First of all, it is much more effective to team with a tech lead or engineering manager to remain semi-realtime up to date with the status of where things are in engineering rather than asking status update questions directly. To not understand that is a level of naivete that prevents a product manager from operating at the basic level of competence to be considered a senior IC.

Second of all, I've seen two kinds of product managers. One kind looks at software development estimates as commitments to be contractually adhered to. The other treats software development estimates as assets/investments with risks to be managed.

Which kind is more effective? Well, which computation accomplishes more results, the one that doesn't halt and logs the same line over and over, or the one that does halt and additionally does the thing it set out to do?

</comment><comment><USER52> I've worked with quite a few POs over the years; good and bad. We used to call them project managers and it's more or less the same thing. As soon as you are asking when questions instead of what questions, you are managing a project.

One thing that I've learned over the years is that product management is often effectively a junior management position and actually should not be a management role at all.

That puts things in perspective in terms of their authority. I've ended up coaching PMs on my team more than once in terms of helping them understand what the product was (often non trivial for new PMs joining an existing team), what kinds of things are easy technically and what kinds of things are not. Even just understanding that there is low hanging fruit to pick (i.e. opportunities for them to look good) is non trivial, etc. All the good ones I've worked with were quick on their feet in learning who to talk to and who to take advice from. A good project manager does not need to be a domain expert to be effective. They just need to learn to ask the right questions.

Ultimately, knowledge-sharing between all the stakeholders in a project (including the customer) is key. PMs acting as bottlenecks can actually be a problem when they are inexperienced. I've more than once had situations where a PM asked me "can you estimate building X please because customer Foo needs this ASAP" where we ended up having a discussion about why building X was actually important, what customer Foo was asking for vs. what they actually needed and us both deciding that actually building something else is a much better way of helping customer Foo. Asking the why questions is always important for both engineers and PMs.

That's why it's important for them to be free to do that and why the proper job title is Product Owner, not Product Manager. In the organizational hierarchy this sits at the same level as the tech leads he's working with in the same team. As soon as you have engineers reporting to PMs, it's a problem and if they have no-one reporting to them, they are not managers.

</comment><comment><USER53> > The engineers would give me highly technical explanation I couldn't > understand.

That's the problem right there. How do you expect to manage a project you don't understand?

I don't think I will ever agree with handing the project to a non technical person instead of the team lead.

<comment><USER54> the opposite is dangerous too: having somebody who is so full of himself that he thinks he knows everything is rarely a good idea. Knowing your limits and being honest about thinks you know and understand is a requirement for a leader, imho.

<comment><USER53> I'm sorry but technical knowledge and feelings are just two completely different aspects. BOTH are required, you can't just simply get stuff done by being a nice guy.

</comment></comment></comment><comment><USER55> I have started to have a simple rule for being a productive developer regardless of client or boss pressure:

Get 1 tangible thing done a day. Ideally it has a visible effect (but don't make this religion- I had to rip out a cache infrastructure last week and replace it with a home-grown one and there was no visible effect other than things not breaking!)

Now, some days, this means you either don't work the full 8 or you go over 8 because the particular piece you're building just won't get built sooner (or you didn't break it up enough). But on average, just having this goal seems to be working.

If interruption would be costly, I take it to a quiet place for a few hours such as a library.

</comment><comment><USER56> > I would let time pass and, on occasion, stories that I imagined would take a > few hours would turn into a day or more.

...or even more...

</comment><comment><USER57> It sounds like a low trust environment.

If you actually need to know whether something is falling behind schedule every few hours (which seems unusual), of course not everybody is going to provide updates that frequently of their own volition. But most good engineers, under the right circumstances, will have a sense for when something is not on track and can raise their concerns.

If you actually had a good level of trust on the team, you would work to get people to buy into it. Of course, it's probably hard to convince most engineers that you actually need an update twice a day, for good reason.

</comment><comment><USER58> Ah, if you require better visibility into the progress of a sprint why don't you just attend the daily standup where the developers talk about what they have accomplished, what they will be trying to accomplish and if they have any impediments? There is no need to shoulder tap each and every individual on the development team for a status update. If you are doing that then you don't understand scrum or agile. Maybe a few more years in the industry (myself 20years vs your 3?) and you can write a more feasible blog post.

</comment><comment><USER21> > It masks the fact that I have expectations as to when something should be > delivered and does not communicate urgency to the team.

But why mask the expectations?

IMHO the best thing you can do is it to communicate priorities (which is your job as product owner / manager), and then if you do need time-based estimations, work them out with the team -- with the clear expectation that they are provisional.

Setting up expectations yourself, and possibly communicating them, but not down, is just a recipe for stress and desaster.

</comment><comment><USER59> This guy went wrong as soon as he thought it was appropriate to measure ticket timings in hours rather than days or sprints. The pressure in this workplace must be unbearable.

</comment><comment><USER60> This reads like a satirical article. Gives a really bad impression of Pivotal.

</comment><comment><USER61> What I don't like about agile is its an awful approach for building large complicated products.

The focus should not be on time management, that's not why software fails, it fails due to bad design.

The "ongoing conversation" developers should have should be about modules, objects, interfaces and algorithms, not about user stories. And refactoring the system to better handle new features should be encouraged, not thought of in terms of "how does this advance a user story".

User stories should be input into the exhaustive design process, and then the design should drive the development tasks.

I'm expecting push back on this, I'd probably go as far to say that for a large team on a large project 1/3 to 1/2 of a Sprint should be spent designing, and the remainder of the time coding.

Writing tests fits in this "designing" bucket for me. TDD is a great way to flesh out how the system should be structured.

</comment><comment><USER62> From the title I expected to see something a bit more, well, _tactical_ about how to arrange communication by changing "real" interruptions into queued requests. For example, e-mails, or (varying by workplace-cultures) instant- messages that nobody expects immediate answers to.

</comment><comment><USER63> This whole method is rubbish. I worked for a company who forced this method on us. The fluctuation was astronomical. Pair programming is only useful in specific cases (like getting a junior up to speed or solving super-complex problems) but in other cases it is a colossal waste of time and an extreme demotivator. Fixing bugs in pairs is the most boring thing that ever happened. Not writing down anything is a surefire way to forget what was the supposed solution for problem X or why did we put workaround Y in the code... A horrible, horrible method, I'd suggest steering clear of any company which adopts it.

<comment><USER64> IMHO it can work quite well, but everyone needs to know what they're getting into. A company that not clearly advertises that this is how they work beforehand is a recipe for failure.

</comment></comment><comment><USER65> Interesting to read about the term "user stories" as narrative documents product managers hand off to devs so devs know what to build. (See also[0], found following links from OP.)

Is anyone able to share such "user stories"? I'd love to see how these business needs get transmitted in the real world.

Also - they're usually way longer than the one sentence referred to in these articles, right?

[0] [https://www.producttalk.org/2012/04/user-stories-are- better-...](https://www.producttalk.org/2012/04/user-stories-are-better-than- prds/)

<comment><USER66> User stories are used (often in scrum) as a measurable deliverable and definition if done for a feature. They are usually 1 or 2 lines, such as `As a user I want to be able to log in to the system` That is the user story for the login feature

</comment></comment><comment><USER67> The problem with checking in so frequently is that it is still intrusive and causes distraction. Many engineers would feel the need to do just make up stuff just to show something has happened since the last update.

</comment><comment><USER68> Why would any talented engineer work with this guy?

</comment><comment><USER69> #2, 3, and 4 indicate that you actually have some idea what you're doing, and an understanding of developers, and are _trying_ to do the right thing, which is all really good. But #1 might be sabotaging all of that.

I don't know how many product people you have, but if everyone followed your suggestion at some companies, then the developers would spend all day chit- chatting with product managers and nothing would ever get done. Even with only 1 product manager, I can't imagine that spending ~40% of the day on status updates is worthwhile. (Literally have had meetings where the answer was "status is the same as it was an hour ago because we've been in this meeting giving repetitive status updates the whole time.")

What you need to do is get to know the developers themselves - how they work, how they communicate, what their domain knowledge is, etc. Then you'll know when you need to message them. And hopefully they'll know when to message you, but you'll also learn which ones might not under which circumstances.

Some will spend a lot of time planning, achieving nothing, but then produce something well-planned. Others take a quick stab, learn from it, iterate, and refine. And there are other styles.

Some try to understand things better before talking about them, others want to talk first. Some have enough domain knowledge that they can 'be the user', while others see the user as the one who keeps screwing things up and making things difficult.

All will occasionally get stuck in that cycle of "ok, it's _almost_ done" without realizing what they don't know until they take the next step. Interrupting to ask in that case isn't going to change anything. It's just something that is always going to happen and is (or should be) factored into the long-term planning averages.

The best PMs know their developers and know when to ping and I'm happy to talk to them when they do, even if (especially if) I'm not doing well. They don't pester me several times a day, so I don't need to spam filter them.

If you're really having anxiety attacks and paranoia several times a day when you're not monitoring your developers' every move, you should consider a therapist and possibly a more easygoing laid-back job. Software is stressful, but it shouldn't be that stressful, and inflicting stress on your coworkers isn't a great solution.

</comment><comment><USER70> "I was a bit paranoid and would sometimes err on the side of conspiracy theories"

This smacks of high stress environment with a bunch of people who don't really know what they're doing, maybe all the way to the top.

Good developers don't work in these places. And if they do get caught here they don't stay long.

</comment><comment><USER71> Judging by all the negative responses do most people see themselves as some sort of vigilante programmer in their company?

I'm not a PM but I sympathize with how difficult it is to discern where a project is up to when it comes to software, especially when you can't come up with short enough milestones...

<comment><USER37> I think lots of people have just had genuinely shitty experiences where they were slowed down in their work by interruptions or made to feel that they were not trusted as professionals.

They see this and it fits a pattern and so they are fairly skeptical.

<comment><USER71> Yeah fair enough, I've been lucky and haven't been made to feel that way

<comment><USER37> I have had a mix of experiences in my professional life, Pivotal is by far my favourite, even when I've gotten super frustrated about particular problems (and I have). I've learned that lots of folks on HN or reddit hear about our common practices and suspect that it's at best chicanery and at worse a deception (all for the fiendish end of working fixed hours with enormous autonomy, _dun dun duhhh!_ ).

Those responses usually upset me, because I feel that my experiences are being devalued. I read the comments and I compare them to my life of the past five and half years and they just aren't the same. It can be hurtful to have casual snide remarks made when you know that the people you work with are kind, thoughtful, intelligent, hard-working humans through and through.

But I _also_ know that other people have had bad experiences and what they hear sounds like other things they've heard from shitty managers and colleagues, so they're cynical. If I talk down to them then I am devaluing _their_ experiences. So I try not to, even though my personal nature is to be an arrogant wanker.

</comment></comment></comment></comment><comment><USER72> There are some nuggets of wisdom in this article, but I think it's very clouded by a certain perspective. I normally don't comment, but feel that it's important to slice what I feel is useful and what can be detrimental behavior as a PM.

As a PM of about 4-years of experience, I understand the author's concerns and at the same time believe that he has solved for the wrong problem; his own anxiety rather than team cohesiveness and trust. The issues he solves for can be solved in different ways without such a negative impact on the team, actually in a very positive manner that increases trust, cohesiveness, and user context.

I'd first like to point out that I've made the mistakes of micromanagement that he mentions in the first section. I also quickly learned how detrimental that behavior is to team relationships, productivity, and outcomes. I'm certainly not perfect!

The way the author solves the problem of pace is by creating regular check-ins every half day. He then goes on to identify, how these check-ins can be used as open to monitor common slow-downs: engineering struggle and product context (he calls is product debt).

I'd first like to make the point that some other engineers have commented here, estimates are estimates, we are agile, you learn things along the way and need to adapt. I believe your job as a PM is not to hold the team to estimates, it is to come up with creative solution and serve as a master facilitator on your team.

So when the author says the following I can't help but notice the irony. I'd explore us all to practice what we preach. Instead care about iterations (sprints) not task micromanagement:

"As a product manager (PM), I often make assumptions as to when a particular user story will be delivered. This is painful because I don't believe in time estimates and don't think I should be involved in estimating the relative complexity of a story since I don't own its implementation.

I know I shouldn't but I can't help doing it anyway…"

So how do you solve the problems that the author points to "struggle" and "context" without adding interruptions?

• For struggle, that is what standup is for. Not only standup, but if you create a culture of trust engineers will naturally reach out if they hit road blocks, make a slack channel for your team. It's even better if you can teach your team about red flags, things that the article says which are true to look out for: complexity is rapidly increasing, not feeling confident in the stack/codebase. For any of this to work you MUST create a culture of questions and answers. Yes, all want to look competent, but what's also great is being able to depend on your team.

• Adding to the previous point, this is why small tasks are soo important, [read this book on product flow]([https://www.amazon.com/dp/B007TKU0O0/ref=dp- kindle-redirect?...](https://www.amazon.com/dp/B007TKU0O0/ref=dp-kindle- redirect?_encoding=UTF8&btkr=1)) if complexity is small to begin with you can avoid that issue AND you get the added benefit of smaller iterations, meaning faster red flags. The author points this out too, this is critically important.

• For context, context is king. Want to avoid "Product debt", get your team/tech lead involved from Day 0 of your quarterly/yearly roadmap, they should know everything about the user that the PM does minus the RAW research effort. Run a Kickoff/Inception/IPM that truly integrates your entire team, every engineer should have product context. Devs will then see tricky edge cases, radiate them up to the PM and you can make a call together if the work is necessary.

All of this is to say that there are some good parts of this article, but I think that adding one more check-in is not necessary when there are other ways to solve the problems identified.

</comment><comment><USER73> Saw a project where the PM would come around like clockwork twice a day. This was not a sprint project, it was a two year long push for a new product. What happened that every four hours a status update was needed?

People laughed behind his back.

</comment><comment><USER74> > I followed my mentor's advice and started to check-in at least every half > day with each pair of engineers I was working with

Yeeeeah... did you get the memo about those TPS reports?

</comment><comment><USER75> My manager expects a formal report once a month, but he is always open to conversation about the products we build. We end up talking daily, but it is never forced.

</comment><comment><USER26> If you don't understand technical details you should not manage anything technical. Ever.

</comment><comment><USER76> I think there's an elephant in the room here, being overlooked:

>The engineers would give me highly technical explanation I couldn't understand. This would frustrate me because I did not add much value and distracted them.

I have a rule which avoids this situation happening, ever, and its a controversial one, but bear with me:

* NEVER accept management from someone who cannot do your job.

This rule, hard and fast, has saved my ass so many times - and every single time I've broken it, things have been more painful than they should be.

Seriously, think about it. How can someone who isn't qualified to do your job, actually manage you? Only if 'management' is an administrative-only task - i.e. "report your hours worked - I don't care about anything else".

But if you put this rule into action and insist that your managers are able to do your job, you have a very strong, very stable organizational structure. This doesn't mean the manager _has_ to do your job - just that they can, if they need to.

You can't manage things you don't understand. So never accept management from people who don't understand the job. And if that is not happening in the organization, you've got another problem: HR are just chair-stuffing. INSIST that this not be how your org is run.

<comment><USER77> > Seriously, think about it. How can someone who isn't qualified to do your > job, actually manage you?

When put in a leadership position, above all "resist the urge to manage".

I don't want a manager, I want someone who serves the team, insulates them from unnecessary distractions, removes obstacles, etc. Someone that supports a culture of humility, respect and trust while helping to care and feed for each individual's autonomy, mastery and purpose.

I've worked on some great teams and less than 1/2 of the time these leaders could not do my job yet it did not matter (of course it was a bit "easier" when they did) because they understood the above.</comment></comment>


Why Can't California Solve Its Housing Crisis? - <AUTHOR> https://www.rollingstone.com/politics/politics-features/california-housing-crisis-causes-874803/ <comment><USER2> Restrictive regulations have choked out the supply of new housing and housing vouchers have driven up the price of existing housing. The state government is unwilling to change its behavior in either of these areas.</comment>