Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The art of interrupting software engineers

content.pivotal.io

Post reply on HN
Print view View original

231–240 of 255 posts

Re: The art of interrupting software engineers

#231

Post by finder83 »

skgoa wrote: post #133
finder83 wrote: post #64

Earlier quoted context omitted.

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

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…

Interesting. What I meant by "old waterfall companies" is that there's a few businesses in town that write enterprise software, oracle, etc, for fortune 500s. Those tend to not be kind to their developers, and have been around for a while.

I have worked for another large telecom that treated its developers great that did kanban.

Currently I work for an agency that really does neither. :-D

But I think you're right, the methodology doesn't matter nearly as much as the managers.

Re: The art of interrupting software engineers

#232

Post by ryandrake »

repolfx wrote: post #147
ryandrake wrote: post #82

Earlier quoted context omitted.

I'm a big believer in "using the tools engineering is already using" but you need to also have a culture of including status updates in bugs. Developers typically are used to putting developery stuff in bugs, not statusy stuff. Crash logs, stack traces, commentary on possible root causes, diffs, etc. you can always find in the bug history. But updates? Not so much. Even a little "UPDATE: Root cause found, fix in prog…

Developers don't want to give you ETAs, especially not for bug fixes where 90% of the time they have no idea how long it's going to take. I've never seen developers volunteer such estimates - they always have to be demanded (and are often wrong, hence the reluctance).

I agree.. it’s not something that comes naturally. Encouraging this kind of culture/discipline is hard, but worthwhile. I think it’s better than the alternative of getting hounded by PMs all day. Like it or not, estimation, deadlines and status updates are part of any commercial engineering endeavor. I’ve never worked at a place where “It’ll be done when it's done” is the way.

Re: The art of interrupting software engineers

#233

Post by jdlshore »

klohto wrote: post #225
jdlshore wrote: post #220

Earlier quoted context omitted.

The Art of Agile Development. It's published by O'Reilly and quite a bit of it is excerpted on my blog at https://www.jamesshore.com/Agile-Book/ .

No chance of hardcover?

The hardcopy print edition is available from Amazon or directly from O'Reilly, if that's what you mean. There's a link to the Amazon listing at the URL I gave you.

As far as I know, there's only one type of printing, and that's a lay-flat softcover.

Re: The art of interrupting software engineers

#234

Post by jacques_chester »

afarrell wrote: post #123
jacques_chester wrote: post #76

Earlier quoted context omitted.

> I'd much rather sketch some diagrams on paper and try to implement something that works but is a little ugly and then make a second pass to clean it up and properly architect it. Fred Brooks said "plan to throw one away, you will anyhow". He was mostly talking about the value of prototyping or what in some circles is called spiking. > I suppose if you write a lot of the same kinds of software you can estimate up fr…

> it's possible to give useful estimates I think an engineer needs freedom to be able to exercise judgement say "I don't understand this task well enough to estimate it yet." Why? Speaking from personal experience, when I was a recent grad and got asked for an estimate, said "I don't know" and then got pressed for one, my thought process was "okay... I guess I'll just come up with a number and double it" because that…

> I think an engineer needs freedom to be able to exercise judgement say "I don't understand this task well enough to estimate it yet."

Absolutely. This is itself a valuable estimate. Very occasionally engineers will give a very high points value to indicate that the proposed story is simply too complex as written and needs to be decomposed further.

> Establishing this freedom is hard:

It absolutely is. Everything we do at Pivotal that works well is actually hard. Our cheat code for bootstrapping these practices is that we already bootstrapped them years ago. But maintaining a culture is harder than building one, which is a trillion times harder than improving one.

Re: The art of interrupting software engineers

#235

Post by jacques_chester »

commandlinefan wrote: post #177
p1necone wrote: post #44

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?

There's actually a name for this fallacy: https://en.wikipedia.org/wiki/Hobson%27s_choice

I thought about this some more and I think the distinction comes down to whether I am made to pair against my will. I'm not. So to me that doesn't feel forced.

But if I worked for Company X and then one day Thou Shalt Pair Or Else, then yeah, it would feel shitty. Labs developers pair with client developers on engagements and sometimes it feels like they've been dropped from a very great height.

Most of the time it works out fine: people are people and we work in the same industry and share many of the same experiences and passions. Sometimes it just doesn't work for everyone, which is also fine.

But insofar as anyone from Pivotal is explicitly or implicitly saying "or else!", I think they are making a mistake and hope they get feedback about it.

Re: The art of interrupting software engineers

#236

Post by jacques_chester »

pharrington wrote: post #114
jacques_chester wrote: post #25

Earlier quoted context omitted.

I don't know how you get the idea that it's forced. We're known for it, it's part of the interviewing process for Labs and most of R&D. 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 is a good thing. Besides which, solo work is common too. Most of the field org works solo, Spring folks mostly work solo, I love pairing…

To clarify - are you saying that Pivotal doesn't have any formal Standard Operating Procedures?

We have the usual HR, legal, compliance etc. But product teams exercise enormous autonomy, arguably to a fault. A few years back an R&D mechanism was introduced of pushing triaged security issues directly into team backlogs. Something close to a riot broke out.

R&D leadership otherwise pretty much don't interfere. Their main business is explaining our strategy, keeping the lights on and teams connected and adjusting allocations between different product and component teams.

Re: The art of interrupting software engineers

#237

Post by jacques_chester »

twic wrote: post #152
ahartmetz wrote: post #130

Earlier quoted context omitted.

4) sounds like a recipe for disaster if the product is large enough. Nobody can remember everything. Heck, I start writing a text document when something gets too big for myself .

Having followed the process as described, i'd agree. If a project runs for more than a few months, you forget why decisions were made. I don't think XP in general has a great story about how to deal with this.

Yes, this is one of my pet peeves.

Pivotal R&D has struggled with maintaining context. For multi-megaSLOC codebases with many moving parts, organic memory begins to fall a bit short.

Different teams deal with this differently. Some write design notes, some keep architecture design records. But IMO it's one of our weaknesses.

Re: The art of interrupting software engineers

#238

Post by _betty_ »

afarrell wrote: post #169
_betty_ wrote: post #139

Earlier quoted context omitted.

I find requirements start changing as soon as there is a conversation about them or a user interacts with a feature. This practice is just saving time writing down behaviour that won't be implemented.

But if you don't have a few paragraphs of your assumptions written down, how do you keep the 3 other people aligned on your basic assumptions and direction? What do you do when people forget things?

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

There's still something written down, just not massive amounts.

Personally i try break stories down smaller to avoid the need for large tasks which helps. I also try minimise the time between story creation and story development.

Otherwise I just communicate a lot.

Things get differently from what I invisioned, sometimes they're worse sometimes they're better.

Re: The art of interrupting software engineers

#239

Post by cornicecream »

rxhernandez wrote: post #110
PhasmaFelis wrote: post #91

Earlier quoted context omitted.

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.

I don't believe that's the fault of the company, nor their responsibility. There are many people that feel forced to stay at toxic jobs, in the Bay Area as locals, because their lifestyle relies on having zero unemployment windows - e.g., they'll default on credit card and house payments.

Especially to those on a visa, the only one forcing you to remain in the USA / Bay Area / x company is yourself. To put it bluntly, no one is entitled to a job, and this applies to every person. In this scenario, it's not like strangers are being pulled off the streets by Pivotal to pair program.

Re: The art of interrupting software engineers

#240

Post by detaro »

edem wrote: post #153

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…

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.
Post reply on HN