Earlier quoted context omitted.
I don’t even have to imagine it, you just described my job now that we have LLMs.
I believe that was the point
Lessons from 14 years at Google
621–630 of 732 posts
Re: Lessons from 14 years at Google
#622Re: Lessons from 14 years at Google
#623Earlier quoted context omitted.
One of my work involved automating some process which was very manual and tedious, took a lot of time and there was dedicated employee for that process. After I did the project, it turned out that this job wasn't necessary anymore and that employee was fired. I felt uneasy about the whole situation.
And they will have to go find another job instead. It feels weird but this is how we raise living standards - removing human labor from production (or, in other words, increasing the amount produced per human) Automation is a game of diffuse societal benefit at the expense of a few workers. Well, I guess owners also benefit but in the long term that extra profit is competed away.
I don't think its automation that increases living standards. We increase living standards by consuming more energy, and that often comes along with increasing the amount of costs we externalize to someone else (like pollution or deforestation, for example).
Re: Lessons from 14 years at Google
#624Earlier quoted context omitted.
Well you can "work to live" in a nice big house, with a nanny, eating steaks, flying business class to ski in the alps or scuba in the Galapagos... I think it takes a lot of money before you feel like you don't need more money.
Other than the big house, which can easily be achieved in much of the country, nothing in the list above incentivizes me to either work harder or kids ass.
Though to be clear I should have said "it can take a lot of money..."
Re: Lessons from 14 years at Google
#625Earlier quoted context omitted.
It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day. Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make…
If upvoting doesn’t require justification neither should downvoting. But let me try to express why people disagree. Change is software compared to physical systems is comparatively incredibly cheap. Unlike in building something known, design at the start of a software project is unlikely to be the one the client actually wanted nor would be the one that is one going to be build. Or at least it shouldn’t be. The “bric…
> 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.
Re: Lessons from 14 years at Google
#626Earlier quoted context omitted.
It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day. Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make…
They should have a general idea of what they are building and why, in exactly the same way as a construction worker. That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction. Sure, a carpenter is j…
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).
Re: Lessons from 14 years at Google
#627i mean, addy has literally been at google 14 years, i think internal network has outweighed the external one here
Re: Lessons from 14 years at Google
#628Earlier quoted context omitted.
In Norway there's laws for that, but other places do it even without them. You just retrain the person to do something else. He might take a job of a temp that was hoping to get a fast contract (instead of a few weeks at a time during trial period). Other than that, it's good for the person (not losing job) but also for the company - you get a tried person with good work ethics that comes on time. It's not zero cost…
Why do the laws exist if its better for (almost) everyone involved? Without the laws why would people not do it that way if its the better approach?
Re: Lessons from 14 years at Google
#62915 years in leadership worked at 3 jobs lead major transformations at retail where nearly 100B of revenue goes through what i built. Ran $55-$100M in a yearly budget… over 300 FTEs and 3x contractors under my or my budget,…largest retailer in google at that time…my work influenced GCP roadmap, Datastax roadmap, … much more all behind the scenes…. besides your capabilities and ability that had to be there to get you i…
So teach your kids to kiss ass and play poltiics. Or to stay far away and do something useful with their lives.