4 ms·
Initial implementation speed is one of the least important parameters in software engineering. Senior engineers are generally a bit slower but produce higher qu
by jondubois 10y ago
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.
- modarts 10y agoHow do you explain that to companies that follow the Google interviewing model?
- fredophile 10y agoWhat 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?
- ghgfhgfhn 10y agoI think he means: The Google culture is built around cerebral competition. The drive to dominate ones peers, possessed by many technical types, is used to create a fiercely competitive atmosphere. This competition is used to drive productivity. The trouble with this is that it is difficult to measure code quality but easy to measure how quickly the code is produced. Thus within highly competitive environments code tends to be produced as quickly as possible, rather than as well as possible. Of course this is debatable and if true, is only a tendency...
- ForHackernews 10y agoA "dead" (or shadowbanned?) user replied to you: << ghgfhgfhn 26 minutes ago [dead] [-] I think he means: The Google culture is built around cerebral competition. The drive to dominate ones peers, possessed by many technical types, is used to create a fiercely competitive atmosphere. This competition is used to drive productivity. The trouble with this is that it is difficult to measure code quality but easy to measure how quickly the code is produced. Thus within highly competitive environments code tends to be produced as quickly as possible, rather than as well as possible. Of course this is debatable and if true, is only a tendency...>>
- sctb 10y agoIf a dead comment appears in a thread, users with vouching privileges and 'showdead' turned on in their profile can vouch for it to make it visible if they believe it to be substantive. Please do this instead of reposting.
- ForHackernews 10y agoWhat are "vouching privileges" and how might one vouch for it?
- sctb 10y agoAt least 31 karma are required, and a link that says 'vouch' will appear on a dead post.
- ForHackernews 10y agoHuh. I have about 7k karma, and I don't think I've ever seen that link. Is it a new feature?
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- jondubois 10y agoI 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.
- papapra 10y agoWhat if one's slow is someone else's fast ?
- jondubois 10y agoThat'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.
- papapra 10y agoWhat if one's slow is someone else's fast ?
- techno_modus 10y ago> 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.