Live data from Hacker News

The art of interrupting software engineers

content.pivotal.io

101–110 of 255 posts

Re: The art of interrupting software engineers

#101
post #79

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 doin…

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.

I think parent’s point stands: if JIRA is hard and requires excellent discipline, why bother in the firth place, and why not go with a rougher board and the micro status checks only ?

Re: The art of interrupting software engineers

#103
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 - clients 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.

Re: The art of interrupting software engineers

#104

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 co…

>Is it really common for software engineers to work under these conditions?

It wasn't like this before fads like XP, Agile, Scrum etc. and micro-management became mainstream. Most of the current management done by PMs and their ilk can be easily categorized under "Bullshit Jobs" (https://strikemag.org/bullshit-jobs). The problem is that once somebody has codified their experience under a catchy title and started marketing it, people blindly follow it without understanding its context and applicability. Given that the barrier to entry to these sort of positions are so low (you can become a PM without any sort of domain knowledge!) people who might not cut it as Engineers seek these jobs to boost their pay, power and egos.

PS: The above might come across as a little harsh but unfortunately is the reality for most Engineers.

Re: The art of interrupting software engineers

#105

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 atm…

I didn't even get halfway through that description of an XP workplace before the little voice in the back of my head started screaming and it still hasn't stopped.

Re: The art of interrupting software engineers

#106

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 atm…

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.

Re: The art of interrupting software engineers

#107

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…

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.

Re: The art of interrupting software engineers

#108

Earlier quoted context omitted.

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 peo…

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 embra…

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.

Re: The art of interrupting software engineers

#109

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...

I think you need to read between the lines to get what the Engineering Community is saying. When you try to micromanage something without any domain knowledge, you are doomed to scorn and in the long-term, failure. You do not follow a process blindly but understand the domain, your people and business objectives to adapt the process to a particular context. That is where the Software Management community has failed. A process which makes perfect sense in a Consulting context is forcibly thrust upon Product Development teams to everybody's detriment. And they can't see it!

Re: The art of interrupting software engineers

#110

Earlier quoted context omitted.

>>> Folks who don't want to pair generally don't apply. Of those who apply, some try it during the interview process and decide it's not for them. That... sounds like forced to me?

If you interview with a company known for making widgets, you don't get to say they "forced" you to make widgets to keep your job.

It's pretty damn near forced if you're on a visa. I had brilliant friends in the Bay area that felt like they were forced to stay at their incredibly toxic jobs since the job market was rough for them and not having a job meant leaving the country.
Post reply on HN