Hacker News Reader

Comment by z9znz | Hacker News Reader

> when the last time was that Mark or Sundar actually wrote any code they pushed to prod

That would be a surpreme waste of company money, and probably they have engineers working for them who are far better developers than they are.

View on HN

At one point Waffle House required all of its senior executives to spend time each year working on the line. (They probably still do I just haven't checked in a few years). They feel this is important for their management team to more viscerally understand the lived experiences of the people working, identify issues in their processes and technology, and generally foster team spirit among their staff.

I think there's a story in the news today about Taco Bell doing the same thing.

More relevant to tech -- Automattic, Klaviyo and probably a lot of other companies require people in certain positions to do customer service rotations. Including C-level execs.

I haven't heard of a version of that for coding, though.

Door dash gets their employees to do 3 deliveries a year

I'm pretty sure that's more to remind their corporate employees what life outside the tower is like. 'See how much better your job is than being a courier who barely makes enough to survive!'

This is about empathy more than contribution, same thing with Quantas right now getting executives to handle baggage. It looks good (see how much we care?), and can be actually positive if it makes senior leadership understand what employees go through, so I think it is valuable for Zuckerberg to do an on call rotation or try and push a documentation change for these reasons

I hope no one will try this out in a brain surgery clinic.

I'll tell you one thing though, EHRM user interfaces would almost certainly be less dogshit if the hospital admins who procure them had to actually use them.

I seem to recall reading that every Disney employee is required to spend a week working in one of the parks for the same reason.

I worked for a national us clothing retailer that didn't require but encouraged their 'corporate' employees to spend time in the stores mostly doing reshelves/reracks, tidying the sales floor, etc. Mostly around holidays/sales.

I worked in software for them but 'close to the store' for a bunch of my time there, so I was often in a store somewhere and always would help out as I had time permitting. It was useful for me, it was maybe useful for some of the buyers, I'm not sure it was useful for anyone else.

I consulted for a Fortune 500 where the CEO would spend a hour or so every month taking sales and support phone calls. He would use this information operationally -- he would send out missives to the head of marketing saying "people are not asking about product X." I wonder what he said when people asked to speak to his manager.

Would it? I understand your point, but the counterpoint is that the leaders are in a position to make big changes if something is broken. They could attempt to push some simple change and see glaring process and onboarding problems, which nobody has been interested in prioritizing, and then make them top priority, saving everyone time.

That sounds good in theory but most leaders are so removed from engineering that it would take them a week ramp up to produce even the most basic tiny change/feature to push to production. A VP should not be spending one week of his or her time doing that. They should rely on engineers to identify and fix whatever is broken at that level. That's why we have staff+ engineers.

But that's also pretty divorced from the topic of what makes good interview questions. There's no way that a VP who spent a week to push out a color change to a button in prod would have any meaningful insight into how to change the coding interviews. That should also be left up to the engineers themselves to decide.

If it takes a week to "ramp up" to produce a tiny change, then that itself is probably a broken process that needs to be improved.

That's about the time I'd expect for a new hire to ramp up on the codebase and submit a PR behind a feature flag and probably experiment that makes it to production. It takes a day to even set up the environment and be able to start looking at and running the code locally. Four days to read through a brand new codebase, identify the changes that are necessary, write a small tech spec (optional based on how small the change is), submit the PRs, get them reviewed and approved, and then merged sounds reasonable to someone who's never worked in the codebase before.

They absolutely should be spending their time doing that. They are in the position to say "I have to do X, Y, and Z to push 2 lines of code??" and actually get it fixed. That week could save the company years of developer hours lost to overhead.

Relying on VPs to do every front-line job in order to identify and fix problems would indicate that something is fundamentally broken at the company. That should never be the primary method by which a company identifies and fixes such problems.

As a former engineering manager, if someone on my team walked me through why getting PRs out to prod was an insane nightmare, I'd take note, work with them to gather evidence, and present it to my director and try to escalate it to the point where we could take action to improve it. If the VP is any good at their job, they'll listen and work with us to fix it.

If they aren't good at their job or it is status quo, they will brush it off. Sometimes it takes a new perspective to say what the fuck is wrong with this?

As an example, I joined a company with ~8k employees recently. They over communicate on email. I get 50+ emails a day. I filter heavily. My inbox is still unusable due to the volume of automated junk. I raised this issue in Slack and the majority of responses were just "well, that's how it is".

I am sure the development process has very similar deficiencies that I am blind to because I participate in it everyday.

> If they aren't good at their job or it is status quo, they will brush it off.

In your example, you rely on them to be even better: you assume that they'll be a competent engineer and be able to understand the complexities of day-to-day software development by making a toy PR when many of them haven't done it for years for decades. That's a much stronger assumption than the one that I'm making: that a good VP will listen to their subordinates.

> That should also be left up to the engineers themselves to decide.

I agree with the rest, but I don't agree with this part. Engineers should have a lot of input into the hiring process, but fundamentally management is accountable for business performance and one of the biggest drivers of success is getting the right people in the door rather than just more people like the ones you already have (which is what happens almost always if you don't deliberately shape the hiring process).

The goal of that would not be to get functional code and a decent price, of course. The goal would be to ensure leadership has an accurate view of what that process is today.

Now, that may or many not achieve what the GP thinks it will. But, if you believe the leadership of your org is out-of-touch, it is a natural thing to suggest.

> a waste of company money Well, I wonder how the CEOs, VPs, and other top level people actually spend their time at work. I get that they obviously must be doing something Very Important And Useful[1], because otherwise it would be a supreme waste of company money to pay them for eating Business Lunches...

1 - https://nypost.com/2022/07/01/rotterdam-wont-dismantle-bridg...

As a counterpoint, in most of the Latin American family empires, where the eldest son is by birth designated to be the next CEO of the company, he usually starts working at the factory in childhood, doing all of the menial jobs. Then he's given a job like outbound sales rep and essentially has to "work his way to the top" (of course on an accelerated timeline, and without really needing to be the best at any level). That way by the time he is CEO, he has the credibility and knowledge of how every facet of the business works.

Yea, as an engineer I would not be happy with my CEO swooping in to commit some code then bugger off.

The point isn't that they commit some useful code. It could be something as simple as just fixing a typo. But force them to go through the motions, so they can see the inefficiency in the processes.

Then they would become the inefficiency in the process

And then what? Are they supposed to design a better development process and build tools to improve efficiency? Again seems like both a supreme waste of time and also as an engineer something I really would not want. Or are they supposed to tell the dev experience team to do something. If so why not just have the dev experience team or leader go through the motions instead?

There is some value in technical leadership familiarizing themselves with internal processes. They could take on a small side project (do Google execs get 20% time?) using libraries and APIs with the goal of providing some feedback on what direction those tools should pursue. BillG did something like this with a measure of success.

I am actually writing a book saying exactly the opposite to this.

I think we are seeing the development of "Programmable Companies" - where all aspects of the company and its data are accessible (imagine a code API that reaches down to some sane mix of data structure).

So while it is crazy for Zuckerberg to try and optimise some Ad server, what should / could exist is a Jupyter-like notebook with something like

for minion in mycompany: if minion.timeatwork < 40: crapminions+= 1

This is mostly done with crappy spreadsheets, but it does not get to the feedback that this sort of platform (I think) enables.

Anyway. The point is CEOs should code. the reason they have stopped is because their job has not been "disrupted" ... yet

Edit: I think there is a further point here. Managers used to (Drucker?) design and build the systems, the factory floor was a battleground of Kanban and command and control. But automation won out. And now the "systems of production" are designed by coders.

All the managers have left is shuffling around people from project to project. But one lever does not a effective d means of control make.

We have learnt from communism that command and control economy falls over at scale. And what is a company but a command and control economy.

Reply on news.ycombinator.com