[jondubois]

Initial implementation speed is one of the least important parameters in software engineering. Senior engineers are generally a bit slower but produce higher quality code.

It's MUCH better to have an engineer which takes 3 days to implement a feature in such a way that it doesn't need to be revised/fixed again for at least 1 year than to have an engineer which takes 4 hours to build that same feature but in such a way that the feature has to be revised 10 times by 5 different engineers within the course of the year.

The second approach actually consumes much more time in the medium and long term. By putting too much pressure on engineers to implement features quickly, you encourage them to create technical debt which another engineer will have to deal with later.

It's basically a blame-shifting strategy.

[techno_modus]

> a feature in such a way that it doesn't need to be revised/fixed again for at least 1 year

The only problem with this (correct) approach is that somebody has to be able to foresee what happens in 1 year. Since it is a relatively rare skill, many decision makers choose quick and dirty solution.

[modarts]

How do you explain that to companies that follow the Google interviewing model?

[jondubois]

I think a lot of times during such interviews, they're more interested in seeing how you approach problems rather than the actual solutions that you provide (at least that's what good companies will tell you).

I haven't worked at Google but I have worked in both startups and big corporations and I find that big corporations are usually slower-paced and engineers have more 'generous timeframes' to complete features (and to do them properly).

The downside of the big company/corporation approach though is that managers tend to use the extra time to create bureaucracy around the project (in an attempt to manage risk) and this slows things down further - So while big companies tend to 'get it right the first time'; they do so at a significantly slower pace than what you would see in a startup.

[fredophile]

What do you mean by "Google interviewing model"? Are you suggesting that this is a problem at Google and companies that interview the way it does?

[papapra]

What if one's slow is someone else's fast ?

[jondubois]

That's possible, but then this raises the question; "How much better/more extensible would that feature be if that fast engineer had twice as much time to complete it?"

As engineers, we rarely pick the absolute best solution for every problem - Sometimes we pick the second, third, fourth... best solution (because they have smaller initial implementation costs).

If management puts too much pressure on engineers to implement features quickly, they will rarely choose the best possible solutions to problems; they will keep picking the 6th or 7th most optimal solution over and over again (for every problem they encounter)- In the end, the project will be littered with suboptimal solutions and the whole project will slow down to a crawl.

Better solutions usually take more time to implement - The 10x engineer doesn't type code 10x faster than a regular engineer.

You could have a 10x engineer whose code is so inflexible that they slow everyone else down by 20x - In that case, they are not a true 10x engineer - In reality, they are a (1/n)x engineer where n is proportional to the total number of engineers working on that project.