An empirical study of working speed differences between software engineers [pdf] • Hacker News Board

Re: An empirical study of working speed differences between software engineers [pdf]

#61

Post by codingmyway » Fri, Jul 15, 2016, 12:28 PM UTC

lifeisstillgood wrote: post #16

I want to start the "Slow Code" movement after the slow food movement. Yesterday at a clients code base I was under pressure to fix a thing, and the obvious approach was adding gobs more code, quickly implementing the most obvious route. And after a (inordinately long) time reading, the light bulb moment happened and I added a single line of code. In my view, when you are in the business of making Seven-League Boots,…

That's so true. The 10x programmers are those that make everyone else's work faster and more accurate.

To me the main job of a lead dev is setting up all the boring processes of build scripts, continuous deployment, package libraries, testing environments etc., that make the other developer's jobs easier.

Re: An empirical study of working speed differences between software engineers [pdf]

#62

Post by smaddox » Fri, Jul 15, 2016, 2:04 PM UTC

ForHackernews wrote: post #52

Hydraulix989 wrote: post #36

Earlier quoted context omitted.

I might add that the difference between a hacked together kernel and the Linux kernel is HUGE. "Hacked together" projects are full of weird bugs, incorrect concurrent code that still works 99+% of the time but then rarely crashes and burns when that ill-anticipated failure case execution interleaving randomly strikes -- to say nothing of problematic and unrefined UX. Well-designed projects are a work of beauty.

> full of weird bugs, incorrect concurrent code that still works 99+% of the time but then rarely crashes and burns when that ill-anticipated failure case execution interleaving randomly strikes -- to say nothing of problematic and unrefined UX. That sounds like an accurate description of 95% of existent software in the world.

Closer to 99.99999999%, i would estimate.

Re: An empirical study of working speed differences between software engineers [pdf]

#63

Post by collyw » Fri, Jul 15, 2016, 2:39 PM UTC

JimDabell wrote: post #33

snoman wrote: post #9

Earlier quoted context omitted.

I'm not saying anything about you here, but I feel like this is what a typical engineer would like to believe to make themselves feel better, but getting things done faster leaves more time for doing them better. Once you're at that stage, it's a simple matter of discipline.

> getting things done faster leaves more time for doing them better It's the other way around. If you take the time to do things better, then you build up momentum and make future work easier. If you want to improve productivity, slow down and do things right, consistently. It'll pay off in the long run.

One example of this I see all the time. You need some new functionality, but altering database tables is a pain in the arse, compared to adding more code. So you add more code. Rinse repeat until you have an unwieldy mess of code. Changing the database model would have been more difficult initially but its often worth the effort.

Re: An empirical study of working speed differences between software engineers [pdf]

#64

Post by jondubois » Fri, Jul 15, 2016, 4:16 PM UTC

modarts wrote: post #34

jondubois wrote: post #31

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 wa…

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

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.

Re: An empirical study of working speed differences between software engineers [pdf]

#65

Post by jondubois » Fri, Jul 15, 2016, 4:56 PM UTC

papapra wrote: post #50

jondubois wrote: post #31

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 wa…

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

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.

Re: An empirical study of working speed differences between software engineers [pdf]

#66

Post by TheCoelacanth » Fri, Jul 15, 2016, 7:48 PM UTC

School-Cotton wrote: post #58

panic wrote: post #35

Earlier quoted context omitted.

Can you give an example of an "IQ requiring task"? I'd buy that there are programs you can't write without the proper background knowledge, but I don't understand what IQ has to do with any of this.

Write "hello world" with IQ 0. (E.g., Terry Schiavo) Apply the Intermediate Value Theorem to this example, as needed.

First you have to prove that the relationship between IQ and performance on writing "hello world" is continuous, otherwise IVT doesn't apply.

Re: An empirical study of working speed differences between software engineers [pdf]

#67

Post by BurningFrog » Sat, Jul 16, 2016, 1:08 AM UTC

fapjacks wrote: post #55

BurningFrog wrote: post #41

Earlier quoted context omitted.

Find fast people to pair program with. You'll learn some good speedup techniques.

This is really a fantastic suggestion! Pair programming can't be advocated enough. I used to think it was stupid many years ago, and then I made friends with a guy who'd been programming longer than I'd been alive. We'd both stay late and shared an office, and in the evenings he started mentoring me, and we'd pair program. I think there is no better way for bringing programmers up to speed (whether junior-senior or s…

Are you not allowed to pair during the day?

Re: An empirical study of working speed differences between software engineers [pdf]

#68

Post by Dr_tldr » Sat, Jul 16, 2016, 2:21 AM UTC

Hydraulix989 wrote: post #32

Dr_tldr wrote: post #17

Earlier quoted context omitted.

Surely you must realize how ridiculous that sounds. You can build basically anything (including a kernel) by working from tutorials and starter projects, then hacking through it. Someone's solution may be extremely sub-optimal, but I've yet to see a programming task that wouldn't to googling and persistence. Inventing Calculus was hard, but virtually anyone can learn to pass a Calculus test given enough time and ince…

Tutorials don't cover things like corner cases, and they neglect nearly every aspect of designing and integrating a large system, particularly scaling it. Some of the worst code I've ever seen was "tutorial code." I've encountered concurrency challenges in my day-to-day work that have no cookie cutter solutions, are specific to my application (particularly in constraints and requirements), and I haven't even been abl…

100% agree, but this is an epoch where even the most mediocre dev is capable of having a long and fairly successful career. I've worked with some huge systems filled with garbage code, and I've never seen a comment anywhere in there that said "the people who wrote this have all been fired."

If the end user experience is anything better than catastrophic and it's making a profit, it's very hard to make anyone care. At best, there will be a big cleanup project that takes it from being totally incoherent and inefficient to being merely very stupid, but in a fairly consistent way.

Re: An empirical study of working speed differences between software engineers [pdf]

#69

Post by fapjacks » Sat, Jul 16, 2016, 2:57 AM UTC

BurningFrog wrote: post #67

fapjacks wrote: post #55

Earlier quoted context omitted.

This is really a fantastic suggestion! Pair programming can't be advocated enough. I used to think it was stupid many years ago, and then I made friends with a guy who'd been programming longer than I'd been alive. We'd both stay late and shared an office, and in the evenings he started mentoring me, and we'd pair program. I think there is no better way for bringing programmers up to speed (whether junior-senior or s…

Are you not allowed to pair during the day?

Well, this was years ago, and we were working on different tasks during the workday. It started with me asking questions and him showing me how to do something that ended up being pair programming. Like many workplaces, there wasn't much time for teaching moments during the workday.

Re: An empirical study of working speed differences between software engineers [pdf]

#70

Post by sctb » Sun, Jul 17, 2016, 12:15 AM UTC

ForHackernews wrote: post #49

fredophile wrote: post #39

Earlier quoted context omitted.

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?

A "dead" (or shadowbanned?) user replied to you: 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. Th…

If 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.