61–70 of 265 posts
Executives: "You should care about the mission, not the money!" (as they keep all the money to themselves)
The dichotomy would be humorous if it weren't so sad.
Some do impress but others have limited lateral experience and so don't fit very well into any place but at prev bigco. But, but, I have five years of experience in X at bigco Y.
I'd like to remind people that large companies are the only ones capable of hiring junior engineers who might not be at full productivity at day 0. This is especially true of the C++ ecosystem.
Earlier quoted context omitted.
"Emphasize that the most important part of software development is moving fast." No, that is not the case most times. The most important part of software development is, as with any other part of the company, to maximize the value of the company. That may be speed, but if you have 1m users the most important thing may be to preserve trust, to acquire new customers, to automate existing infrastructure, etc. etc. Speed…
"Maximising company value" isn't a useful end goal you can give to anyone but the CxO team. For everyone else, it's a motherhood statement. Trotting it out as though it's some kind of engineering compass isn't helpful. To this you've appended the hackneyed conflation between "speed" and "cowboy attitude". It's a common category error, but in truth, rapid iteration is one of the enablers of high quality and is a huge…
In a well-functioning company, I don't need to make that decision myself, of course: I have management who has evaluated the cost of having the bug and the benefit of having the feature, or who's experienced and smart enough to determine whether doing the short-term thing now or investing in the longer-term thing will be likely to have better payoff. Because this process is there, if I trust my management, I don't have to spend-time second-guessing them (or worse, doing the research myself), and then I get to move quickly. But again, moving quickly isn't the point. It's a tool on the way to delivering value.
"But the CEO never noticed that the payoff had ended for the other 95% of his company." It seems a lot of C*Os forget this after a while. For a lot of rank and file employees the stock price makes no difference.
Earlier quoted context omitted.
"Emphasize that the most important part of software development is moving fast." No, that is not the case most times. The most important part of software development is, as with any other part of the company, to maximize the value of the company. That may be speed, but if you have 1m users the most important thing may be to preserve trust, to acquire new customers, to automate existing infrastructure, etc. etc. Speed…
"Maximising company value" isn't a useful end goal you can give to anyone but the CxO team. For everyone else, it's a motherhood statement. Trotting it out as though it's some kind of engineering compass isn't helpful. To this you've appended the hackneyed conflation between "speed" and "cowboy attitude". It's a common category error, but in truth, rapid iteration is one of the enablers of high quality and is a huge…
Exactly right. Frequently, in industry, I see people confuse the "slow" and "competent" bits. They think that just because a given change needs to get a bunch of sign-offs that the overall effect of the system requiring the sign-offs is a net benefit to the organization.
It's not. It's paralysis, and you won't notice how ungainly and slow you've become until a different org a tenth of your size manages to clone your entire feature set in a hundredth of the time it took you to develop it, all because your developers have to deal with bullshit all day long and your competitor's can just act.
A lot of people will claim that you need gatekeeping and approvals and such to maintain a rigorous standard of quality. You have to be brave enough to disregard their advice. You have to be able to take the gut-wrenching step of saying, "No. We're not doing that. I don't care if this change caused a SEV, we're not adding process. Moving fast is important!".
It's very easy to believe the nostrum of "no pain, no gain". But sometimes you have to realize that pain is just pain.
The most important lesson for people in power in big tech companies: FORMAL PROCESS IS THE ENEMY. Don't let the accumulation of gatekeepers and approvers and other capital-P Process let things become 100x harder than they need to be. Do not confuse difficulty with prudence. Your organization will become slow and ossified by default unless you take specific steps to maintain flexibility. One of these steps is to insta…
The ratio of students that decided to major in engineering because they were good at math in high school vs. the students who decided to major in engineering because they they wanted to make something inspiring, I feel ( and let me stress my inexperience as a current undergrad, without experience in the actual field ) is vastly favored in career growth towards those that decide to create instead of simply learn.
While there is always room and lucrativity to tie engineers on a leash and juice mathematics and logic out of them until they reach an existential crisis, there is always (ALWAYS) room within the budget to let them set out upon a path which is in tune with their not necessarily young, but foolish and hopeful beliefs.
Despite the overall theme of this interaction, opening an office in the East Bay seems more employee friendly than keeping them in Palo Alto.
Earlier quoted context omitted.
"Maximising company value" isn't a useful end goal you can give to anyone but the CxO team. For everyone else, it's a motherhood statement. Trotting it out as though it's some kind of engineering compass isn't helpful. To this you've appended the hackneyed conflation between "speed" and "cowboy attitude". It's a common category error, but in truth, rapid iteration is one of the enablers of high quality and is a huge…
> Fast+incompetent = cowboy attitude, sure, but the problem there isn't the fast bit. Exactly right. Frequently, in industry, I see people confuse the "slow" and "competent" bits. They think that just because a given change needs to get a bunch of sign-offs that the overall effect of the system requiring the sign-offs is a net benefit to the organization. It's not. It's paralysis, and you won't notice how ungainly an…
The moment that some minor disaster hits, which it inevitably will, whoever is in charge will find themselves no longer in charge.
I think this is one of the fatal flaws of a big company. Everyone is terrified of risk. I'm not sure it's possible to counteract this tendency unless the company was built from the ground up not to punish risky behavior (e.g. Facebook, supposedly).
The most important lesson for people in power in big tech companies: FORMAL PROCESS IS THE ENEMY. Don't let the accumulation of gatekeepers and approvers and other capital-P Process let things become 100x harder than they need to be. Do not confuse difficulty with prudence. Your organization will become slow and ossified by default unless you take specific steps to maintain flexibility. One of these steps is to insta…
> Emphasize that the most important part of software development is moving fast. This doesn't seem to me to be true. Can you expand on your thoughts here? I'd agree that the ability to move fast is an essential part of effective software development, but I don't think it's the most important (the most important is producing business value accurately and reliably), and I think that moving fast for the sake of moving f…
By default, all software development organizations slow down. I say that developer velocity is the most important goal because, without focusing on this velocity, you end up solidifying, like a cooling lava, and it becomes difficult to accomplish any of your other goals.