llm/3a862c31-848e-4e32-be93-99402d2b43b6/topic-16-7814dea0-c855-440c-9517-a258bdd0eb7e-input.json
You are a comment summarizer. Given a topic and a list of comments tagged with that topic, write a single paragraph summarizing the key points and perspectives expressed in the comments. TOPIC: Process and Bureaucracy Critique COMMENTS: 1. Very true. We waste alot of valuable labor on “software engineering” that is grossly inefficient. Capital gets allocated to these so called startups that are incredibly inefficient. 2. > This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. You actually described the job that Product Managers _should_ be doing: "understand the purpose and real world usage of your software". 3. Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefully functional) team, product strategy is not what the software engineer should be concerned with. 4. Developers shouldn't test, they should throw it over to QA who will test it precisely to meet the defined requirements. The Product Manager's job is to communicate the customers needs to the developers/designers and the developers/designers constraints back to the customers. It's up to the developers and designers to understand those constraints and make sure they are communicated back. 5. Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized. And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two). 6. The other argument about this is whether or not an SWE is a fungible resource. When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another. We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly. 7. I appreciate the reply. > If upvoting doesn’t require justification neither should downvoting. I disagree, since downvoting is not equal to upvoting. First off, not everyone has the ability downvote (at least on hackernews). Second, upvoting usually means you agree with something, while not agreeing should be reserved to the action of NOT upvoting. This is how most social media works. Downvoting should be reserved for something that should not belong on the thread. Regarding the topic of the discussion, I agree that "builders" should be proactive and knowledgeable about the system that they are building, but the "chief architect"/project manager should be the intermediary between them and the clients, if for nothing other than being a single source of truth. 8. Rightly said. I spent good amount of time cleaning up 15 year old codebase and removed almost 10MB of source code files which was being part of production build and it was never used. This helped reduce the build time. I thought I'd get appreciated from everyone in the team, but it was never acknowledged. In fact my PM was warried and raised an alarm for regression. Even though I was 100% confident that there would not be any regression, the QA and PM got annoyed that I touched a working software and they had to do extra work. I then posted on LinkedIn about this achievement to get my share of appreciation. :) 9. Because the 10 minutes of chatting has value too. Which is why corporations make you spend so much time on team building exercises and axe throwing. 10. No, that's HR justifying its existence. Plus that's for higher stature service based roles, not warehouse logistics. It's also mostly bullshit. Teams work because they have the right combination of skills, both personal and technical, high EQ and IQ, leadership and ownership. Whether or not you fall backwards into a team's arms or have to participate in childish games is not relevant. 11. > But how does one make judgment a repeatable process? Principles can help scale decision-making. 12. Completely insane, who doesn't get to have coffee breaks without manager permission? Surely any org that treats its employees as adults would not have this problem. 13. This first 3 hit me very hard, 1. The best engineers are obsessed with solving user problems. I think this problem is rooted in early education: students learn languages, frameworks, and tools first without understanding what problems they actually solve. Once engineers have experience building a few products for users, they begin to understand what matters to the user. 2. Being right is cheap. Getting to right together is the real work. - Sadly most of the arguments are won by either someone in power or experience. Right decisions are made with consensus. You build consensus during creative process and leverage power and experience during crisis. 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one. - Every decision is a risk management. The smart people convert higher risk into lower risk. Most people struggle here to take the risk because of the fear of failing and just waste time arguing, debating and winning over each other. 14. The problem with point 3 is that once you start with a bad draft and everyone starts working on it you're kind of locked in to its trajectory, even when it'd be a lot better if you were to do it another way. You can't start from scratch even if you're feasibly within the window to do so, because now the work has started. 15. They are pretty insightful. Particularly this one: > 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one. I have my own version of this where I tell people that no amount of good advice can help you make a blank page look better. You need to have some published work before you can benefit from any advice. 16. I liked that one, too, but for an additional reason. Typing that first character on the page reveals the problems you didn't even know existed. You don't have a keyboard. You do, but it's not plugged in, and you have to move an unexpectedly heavy bookcase to reach the USB port. You need to learn Dvorak. You don't have page-creation privileges and need to open a ticket that will take a week to resolve. You can create the page, but nobody else is able to read it because their machines aren't allowed to install the version of the PageReader™ plugin that your page requires (and you'd need a VP exception to downgrade your PageGenerator™ toolchain to their version). And so on. All these are silent schedule killers that reveal themselves only once you've shipped one full development (and deployment!) cycle. And as ridiculous as these example problems seem, they're not far from reality at a place as big and intricate as Google. 17. Sounds a bit like a rephrasing of the old "it is better to ask forgiveness than to ask permission". 18. The problem is I've worked at at least 5 companies that professed a strong "bias for action" and it nearly always meant working nights and weekends to ship broken things that ultimately hurt the user and then moving on to the next big leadership project to do the same thing again, never looking back. The exception of course would be when leadership finds it's broken in 5 months and complains about poor engineering practices and asking why engineers can never get things right. I've heard all the truisms listed in that post in my 14+ years at many companies that aren't Google and in all cases there's a major gap between the ideal and the reality. This entire list reads to me as "I got paid 10s of millions of dollars to drink the Kool Aid, and I must say, the Kool Aid tastes great!" 19. I’m a big fan of Amazon’s leadership principles. One of them is bias for action. I worked at AWS for a few years and I’d be in a meeting and someone would say bias for action and we’d all know what we needed to do. 20. The problem with this approach is that once you've started with a "bad" draft and enough people have signed on, you're locked in to its trajectory and can't do foundational rewrites even if you were within the feasible window. It'll just end up being a bad product overall. Starting right is important. 21. This reads like it was written by a PM. You lacked higher level context and prioritization skills early in your career so the take away is it's best to divest agency to others? There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams. 22. There's not enough hours in the day for everyone to do everything. > There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams. Yes, this is great for agency over implementation, because leaders do not have context to decide and dictate the What/How of implementing every single change or solution to a problem. And the implementers need to know the context to ensure they make decisions consistent with that context. But "leaders providing the context" is very different from "everyone researching the context on their own." So where are leaders getting this context from? A not-very-differentiated pile of 1000 generalist engineers-who-also-talk-to-customers-frequently-and-manage-their-own-work-streams? Or do they build a team with specialists to avoid needing the majority of people to constantly context-switch in a quest to be all of context-gatherers, work-prioritizers, market-resear 23. > The engineer is not supposed to engage directly with the customer. I don't know if companies have finally stopped pretending to be "agile"; but if not, this is such a clear demonstration of how they are anything but. 24. If an engineer talking to users is considered problematic, then it is safe to assume, that Google is about as fast away from any actually agile culture as possible. Does Google ever describe itself as such? 25. "data-driven agile"™ 26. Almost nobody else in engineering did this. What you described is the job of a product manager. Are there no PMs at Google? 27. There are, and often times they're stuck in a loop of presenting decks and status, writing proposals rather than doing this kind of research. That said, interpreting user feedback is a multi-role job. PMs, UX, and Eng should be doing so. Everyone has their strengths. One of the most interesting things I've had a chance to be a part of is watching UX studies. They take a mock (or an alpha version) and put it in front of an external volunteer and let them work through it. Usually PM, UX, and Eng are watching the stream and taking notes. 28. Xoogler here. When you get to a company that's that big, the roles are much more finely specialized. I forget the title now, but we had someone who interfaced with our team and did the whole "talk to customers" thing. Her feedback was then incorporated into our day-to-day roadmap through a complex series of people that ended with our team's product manager. So people at Google do indeed do this, they just aren't engineers, usually aren't product managers, frequently are several layers removed from engineers, and as a consequence usually have all the problems GP described. 29. With continuous delivery and access to preview and beta features, the documentation is fragmented and scattered and half of it technically is for the previous version of the product with a different name but still mostly works because microsoft can't finish modernizing most software... And the customer support is not great until you start really paying the big bucks for it. 30. I feel like you're giving too much credit here. I don't know if it was a leak or an urban legend, but I remember the awful win 8 "flat boxes UI" being that way because it could be designed by managers in PowerPoint that way 31. This is almost certainly not the case. The larger the company the more change is viewed as a negative. Yes people may hold titles to do the things you describe but none are empowered to make change. 32. You are onto something there, if you mean, the design roles being taken over by the people who are not techies - like the POs. But if you just refer to UX being designed for mobile devices - that is not an excuse for an even worse UX on the mobile. If anything I would have expected more effort put in there, given how many more issues the limited screen estate can cause... 33. How so? Those two together is literally agile; not as I've seen it done, but as it's intended. Learn, iterate, repeat. 34. Mood. As someone who normally leaves after two years because the opportunity never raises to what was offered in the job spec these really don't for for me these bullet points as well wouldn't work for office culture in the EU. 15 Years worth of jobs and none gel. I'm a contractor now which feels more me. I have a contract length, don't have to deal with red tape political bullshit. Turn up, do work and leave when contract had ended. 35. Seems reasonable. Many points maybe more applicable Google/Google-like companies. With layoffs and overall job shortages a lot of workplaces are having a cake and eating it too. They demand fast delivery and taking shortcuts (calling it creative thinking ) and once things blow up directly due to shortcuts put blame on developers / testers for taking shortcuts and compromising quality in the process. 36. > In large organizations, decisions get made in meetings you’re not invited to, using summaries you didn’t write, by people who have five minutes and twelve priorities. If no one can articulate your impact when you’re not in the room, your impact is effectively optional. Very true in large organisations. But... in a company whose stated mission is to " organize the world's information and make it universally accessible and useful " ... this feels like a failure. When a truly data driven company manages to quantify impact by more than the volume of hot air emitted :) then it's going to eat the world. Perhaps it's for the best that nobody does that? 37. This and the other top story on HN right now ( I charged $18k for a Static HTML Page) [0] make it clear the the most important thing as a software developer is jumping through hoops and being agreeable. It does not matter if it makes sense to you. I’ve come to accept that I can’t always predict what is actually valuable for the business and should just go with the flow and take their money. The leetcode-style interview selects for this by presenting as an arbitrary hoop you have to jump through. [0]: https://news.ycombinator.com/item?id=46469877 38. There are many big bosses under the Google CEO that lead hordes of developers to specific targets-to-meet. Eventually they prioritise their bonuses and the individual goals deviate with every iteration. So the quality will diminish continuously. 39. It's frustrating to read this advice, which to me can be summarized as "don't think too hard, dumb it down, keep it simple, be a people-person" and then look at their hiring process full of advanced data structures and algorithms. Why hire top tech talent if you just need to keep a simple vibe and not over-think clever solutions? 40. Here's the lessons all ex-Google colleagues I've worked with have brought with them to their new jobs: 1. Use Bazel for everything. Doesn't matter that the documentation sucks and it's unbelievable bloat for smaller companies: use it anyway. Use it for everything. 2. Write things from scratch. Need a protobuf parser in C? Just write one up instead of using any of the battle-tested open source options. 3. Always talk down to frontend engineers and treat them as lesser/ not real engineers. Real engineers are backend engineers. Frontend is so easy that they can do a perfectly fine job if needed. Make sure to use Bazel for all frontend builds. 4. Did I mention Bazel? It's the solution to all problems for all companies. 41. Where you can serve corporate interests more directly and with less overhead? (:shrug:) 42. Worked at an AI training company for a few months. Enshittification is real. Idiots who never deserved to be here coming up with new policies every week, sometimes twice a week. Absolutely spineless when receiving nonsense from the client which is one of FAANG but will screw colleagues with no remorse. Write a concise, engaging paragraph (3-5 sentences) that captures the main ideas, notable perspectives, and overall sentiment of these comments regarding the topic. Focus on the most interesting and representative viewpoints. Do not use bullet points or lists - write flowing prose.
Process and Bureaucracy Critique
42