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

Big company tale: six months for a list and a button

rachelbythebay.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Big company tale: six months for a list and a button

#81

Post by didntknowya »

treis wrote: post #53
merrvk wrote: post #9

Earlier quoted context omitted.

> their PM told them to disagree with me to pump up the final bill This explains a lot of my experiences now

IMHO that would a rare to almost non-existant thing. Any sort of Mega Corp has an unending stream of IT work. There's no real need or desire to pump up the final bill. You'll make way more money in the long run coming in on time and under budget.

although the problem is there's no incentive to perform when delivering late and over budget rarely has any consequences (on future work streams)

Re: Big company tale: six months for a list and a button

#82

Post by cutemonster »

siscia wrote: post #24
noisy_boy wrote: post #20

Earlier quoted context omitted.

> For instance figure out the resources that was suppose to create the application, pass by its office, offer its a coffee and communicate clearly why the things is important and how important it is and what is the goal of the project and finally reassure the resources by putting in whatever work tracking system all the details. You are assuming that just because the manager can swing by at author's desk, their team…

Of course it was just an example! But even a chat message or an introduction does wonders. My point was that, from the tale, I don't think the author did enough to actually accomplish the task and that the complaints on the internet public square is hardly justified. Said so, I find it a well written piece that may be useful to younger engineers approaching these kinds of dynamics. I would find extremely interesting…

> comparing when stuff goes well

I suppose that then the dashboard team would have replied that same afternoon: "Done, here: __", end of story. Without needing any coffee.

And if they (the dashboard team) didn't see how the dashboard was important, they'd kept asking for clarifications until they knew, and then clearly said if they'd do it or not

Re: Big company tale: six months for a list and a button

#83

Post by Rastonbury »

somebodythere wrote: post #41

I wonder what was wrong with the shell script thing really, other than it didn't have the panic button.

Yeah was the acutal business benefit I wonder? How much time was spent by the author over wrangling and learning to do it from scratch, it does not seem worth it

Re: Big company tale: six months for a list and a button

#84

Post by physicles »

cutemonster wrote: post #75
physicles wrote: post #61

You can also use this essay to examine opportunities and pitfalls of horizontal coordination across organizations. I used to work at a big tech company, but now I’m one of a few cloud devs at a startup. One day we realized we needed a dashboard, so I spun up a server and put a single binary on it that saves data to SQLite and renders HTML server-side. Dumb stuff. Took 2 days, problem solved, been humming along for a…

> dashboard team ... create a self-service solution for making a new dashboard > Am I missing a downside I don't think so, I'm just wondering, what to do if the dashboard team creates a buggy & hard to use, worse than nothing, dashboard self service, and everyone is supposed/required to use it > 100 devs. ... If you don’t do this right, the dashboard communication/management overhead at some point grows larger than t…

> I'm just wondering, what to do if the dashboard team creates a buggy & hard to use, worse than nothing, dashboard self service, and everyone is supposed/required to use it

That sounds like the situation in the OP's article. Maybe it would be best to address that as a political problem ("don't make us use this thing") instead of a technical one.

Re: Big company tale: six months for a list and a button

#85

Post by thecoppinger »

lodovic wrote: post #7
xyzzy123 wrote: post #4

What impresses me most about this is that $BigCo's dashboard team didn't block them from doing it themselves...

That would be typical, take ownership of another team's pet project, block that team from contributing further, take all the credits from management and let the project die. Seen it happen multiple times at my current gig.

Happened to my personally at the gig I recently quit at. I thought I was the only one.

Re: Big company tale: six months for a list and a button

#86

Post by utunbu »

haukem wrote: post #76
utunbu wrote: post #71

> April 8: it seems there's now a mock-up of sorts from the team. Inside the group, we start talking about that situation where if you mail the $open_source_project mailing list asking for help with a legitimate problem, nothing happens, but if you make up a shitty version of something and fire it off, then suddenly 50 million people show up and go OI! DO IT THIS WAY! But, three months earlier when you politely asked…

Yes I would say this is a case when someone wants to contribute something to an open source project. Often these initial questions are very unspecific and often as a maintainer you only get the question, answer it and then never see this person again. Time wasted. When someone already wrote code and want to contribute it you know that the person already invested some time and is seriously about implementing some stuf…

I see, this makes a lot sense. I guess perhaps community forums and IRCs are better places for those initial and unspecific questions?

Re: Big company tale: six months for a list and a button

#87

Post by mbrodersen »

xyzzy123 wrote: post #4

What impresses me most about this is that $BigCo's dashboard team didn't block them from doing it themselves...

The trick is to make your own dashboard but not calling it a dashboard. When they try to stop you, claim that it is not a dashboard (even though everybody knows it is a dashboard). Insist that they define, in writing, exactly what a dashboard is. Continue rejecting their definition with counter examples. Insist that the definition is unclear and needs to be defined in a formal language. Reject their formal definition after spending months being “too busy” to review it. Change the background colour/font/title and claim that it is changed so it needs to go through the review process again. Ask for their written definition of their review process. Insist that it is ambiguous and needs reviewing/fixing. Repeat forever.

Re: Big company tale: six months for a list and a button

#88

Post by MrDOS »

utunbu wrote: post #86
haukem wrote: post #76

Earlier quoted context omitted.

Yes I would say this is a case when someone wants to contribute something to an open source project. Often these initial questions are very unspecific and often as a maintainer you only get the question, answer it and then never see this person again. Time wasted. When someone already wrote code and want to contribute it you know that the person already invested some time and is seriously about implementing some stuf…

I see, this makes a lot sense. I guess perhaps community forums and IRCs are better places for those initial and unspecific questions?

IMO there are very few places where it's appropriate to ask unspecific questions. IRC and forums are “better” for them in the sense that there's a tighter response loop on narrowing down what the asker is actually interested in, but it's still a waste of time for everyone involved. Being able to ask questions well is a skill, and everyone has to learn it somehow, but it's generally better for everyone if the question includes too much situation-specific detail than too little.

Re: Big company tale: six months for a list and a button

#89

Post by spikej »

mbrodersen wrote: post #87
xyzzy123 wrote: post #4

What impresses me most about this is that $BigCo's dashboard team didn't block them from doing it themselves...

The trick is to make your own dashboard but not calling it a dashboard. When they try to stop you, claim that it is not a dashboard (even though everybody knows it is a dashboard). Insist that they define, in writing, exactly what a dashboard is. Continue rejecting their definition with counter examples. Insist that the definition is unclear and needs to be defined in a formal language. Reject their formal definition…

You've clearly played the game

Re: Big company tale: six months for a list and a button

#90

Post by spikej »

cutemonster wrote: post #75
physicles wrote: post #61

You can also use this essay to examine opportunities and pitfalls of horizontal coordination across organizations. I used to work at a big tech company, but now I’m one of a few cloud devs at a startup. One day we realized we needed a dashboard, so I spun up a server and put a single binary on it that saves data to SQLite and renders HTML server-side. Dumb stuff. Took 2 days, problem solved, been humming along for a…

> dashboard team ... create a self-service solution for making a new dashboard > Am I missing a downside I don't think so, I'm just wondering, what to do if the dashboard team creates a buggy & hard to use, worse than nothing, dashboard self service, and everyone is supposed/required to use it > 100 devs. ... If you don’t do this right, the dashboard communication/management overhead at some point grows larger than t…

Buy a COTS product that fits the criteria rather than try to build own buggy/hard to use product.
Post reply on HN