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.
The art of interrupting software engineers
101–110 of 255 posts
Re: The art of interrupting software engineers
#102> This was mostly me passing by and asking how things were going Hello Peter whaaaat's happening?
Re: The art of interrupting software engineers
#103Here'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
#104Is 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…
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
#105There 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…
Re: The art of interrupting software engineers
#106There 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…
Re: The art of interrupting software engineers
#107I 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…
Re: The art of interrupting software engineers
#108Earlier 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…
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
#109Judging 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...
Re: The art of interrupting software engineers
#110Earlier 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.