51–60 of 71 posts
Earlier quoted context omitted.
Easy to say when you don't hold the pager.
What's that supposed to mean? I am just agreeing with the previous comment... early stage Facebook had a mentality in the spirit of the original article, and as they grew had to stop it. That's all. Just agreeing.
Earlier quoted context omitted.
Easy to say when you don't hold the pager.
What's that supposed to mean? I am just agreeing with the previous comment... early stage Facebook had a mentality in the spirit of the original article, and as they grew had to stop it. That's all. Just agreeing.
In most companies I've worked, approval process is the scar tissue of years of mistakes. In every case where you need to ask for approval to do something, you can probably trace back in the company's history and find the past mistake that some goofball made that necessitated getting approval to do something like that. Someone got us sued. Someone lost us some money. We need to take some kind of corrective action and…
Move fast and break things => Move fast with stable infra
I've also worked in places with near absolute freedom, right down to the level of individual engineers building out new products without approval where a single crash meant all hands on deck.
In most companies I've worked, approval process is the scar tissue of years of mistakes. In every case where you need to ask for approval to do something, you can probably trace back in the company's history and find the past mistake that some goofball made that necessitated getting approval to do something like that. Someone got us sued. Someone lost us some money. We need to take some kind of corrective action and…
My company has been getting a lot of talent from Amazon and Microsoft, so we are getting their "scar tissue" without any of the context, jacking up our culture. I have to do a detailed doc and plan for everything . It wouldn't be a big deal but we've gone from 700 to 1500 employees in just 2 years, so its been fast change.
As your company grows from small-sized to medium-sized, your technical processes need to grow, too.
I can’t help but think having such autonomy is tied to profitability. I’m sure there are plenty of examples where an employee at a profitable company doesn’t have autonomy. But how many have autonomy where there's not profitability?
There's a relationship here with profitability, for sure - companies that are profitable are likely not prioritizing growth over profit, and aren't beholden to investors who want a big exit, but the profitability is more of an indicator than the cause.
Earlier quoted context omitted.
What's that supposed to mean? I am just agreeing with the previous comment... early stage Facebook had a mentality in the spirit of the original article, and as they grew had to stop it. That's all. Just agreeing.
So you're suggesting a progression rather than one being vastly superior? I took it as the latter. Sure, we all know the trick to startup success. Sprint as fast as you can for that cliff and hope the cliff moves before you get there.
Earlier quoted context omitted.
Basecamp was founded in 1999 so I think they've had time to make plenty of mistakes. While I don't dispute the idea of approval processes as scar tissue, perhaps most companies scar too easily. I mean that both in the sense of being fragile and in the sense of over-reacting.
Basecamp has 50 employees. Google was founded in 1998 and has 50k employees. I think there's something more to be said about the differences in their experiences and the kind of mistakes they have made.
In most companies I've worked, approval process is the scar tissue of years of mistakes. In every case where you need to ask for approval to do something, you can probably trace back in the company's history and find the past mistake that some goofball made that necessitated getting approval to do something like that. Someone got us sued. Someone lost us some money. We need to take some kind of corrective action and…
My company has been getting a lot of talent from Amazon and Microsoft, so we are getting their "scar tissue" without any of the context, jacking up our culture. I have to do a detailed doc and plan for everything . It wouldn't be a big deal but we've gone from 700 to 1500 employees in just 2 years, so its been fast change.
I find spending a few days writing a detailed, in-depth design document for a given implementation often saves weeks or more of development. In the immediate term it takes longer. In the medium to longer term a thorough design can often lead to fewer bugs, less severe bugs, and less complicated enhancement development.
What you describe is what engineering is, at least partly. Your attitude, which is quite common, is why I scoff at calling what this industry does "software engineering". It's rarely as thoughtful, careful and detailed as engineering requires.
Not that that is a bad thing. Often what a business in this industry is making just isn't complicated enough to need much beyond simplistic hacking at a terminal.
>If you can make a decision and you don’t think it’s going to get you fired, just do it. This advice only applies to people with enough experience. I'm thinking of a certain ex-employee that followed that advice all the time, despite us constantly correcting him. Even on their final day, they was still insisting that they was doing good work. To this day, we are still finding code they wrote or modified that is wrong…
You are talking about programming, but this is about questions like "should I add feature x" or "should I try to improve the build process by using tool y". Somebody that can't program still might take the right business decision. I had the "pleasure" of maintaining the ColdFusion "programming" of a guy that sold airline ticket systems to a lot of different companies and in terms of business decisions he's about a fe…
Only if I'm very, very certain do I not bother asking.
And I've certainly got non-programmers around me that make business decisions all the time. It's their job. I'm not sure how that's relevant?
The same thing applies: They should only be doing it without consultation if they have the experience to back it up.
>If you can make a decision and you don’t think it’s going to get you fired, just do it. This advice only applies to people with enough experience. I'm thinking of a certain ex-employee that followed that advice all the time, despite us constantly correcting him. Even on their final day, they was still insisting that they was doing good work. To this day, we are still finding code they wrote or modified that is wrong…
Isn't the solution to this a good code review process? Even the author of the article states "I either wrote up a plan and shared it beforehand, or I just announced what I’d done after it was completed". This is very similar to asking someone review your code.
However, I noticed that he only told others after it was completed sometimes, which is often far too late.
Experience lets you know which ones that's okay for, and which ones it isn't.