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.
> 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.
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.
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.
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.
I would think the speed ratio between the best and worst programmers has to be infinite. Some programmers simply cannot accomplish a task. Once they die you may as well divide by infinity.
For every task you need some minimal iq. Some tasks need higher iq than others. A programmer is someone who can at least do the least iq requiring task. He will fail on some more difficult tasks.
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 incentives.
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 able to fully convince myself of the correctness of my own solution, let alone contrive a way of systematically proving or even testing it.
On the other hand, programmers faced with solving technical challenges such as optimizing and approximating in the face of limited resource, where heuristics and intuition only discovered and learned through experience and trial-and-error (pattern building and "finding" at its best). These meta "design patterns" aren't found in any books yet, especially because they are pretty hard to articulate using the English language.
There is an inventive element to the sort of problem solving that good programmers perform that goes well beyond pasting solutions from StackOverflow. This is why duct tape and bubble gum cobbling of out-of-the-box solutions rarely works in practice (and why good engineers are paid so well). Clever hacks are actually pretty damn clever.
It's scary how many "best practices" I've only learned through building my own production systems and having actual users test what I've coded -- having already done a fair deal of sitting in classrooms being inundated with CS theory from the very minds who conceived it -- even years of building pet projects of my own haven't prepped me for the challenges I am encountering now.
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.
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.
Imagine you're given a problem that is completely novel in its description yet is actually reducible in some non-trivial way to a well-known NP-complete problem that has great probabilistic algorithms available for it.
Googling the original problem description will (for a novel formulation of the problem) not result in any advantage and implementing a standard algorithm will not work if you need n to be large for your application.
I will admit that it's a slightly contrived example ;)
0.001% of devs would be around a few hundred in the whole world, there are way more CS grad students than that...
I'd guess that at you get to at least a few percent if you count grad students, researchers, people working on performance critical stuff like GPU drivers, people working on state of the art tooling like Google internals or large OS libraries etc.
Here's one: Take a complex system and make it as simple as possible but no simpler. The complexity may be essential or accidental (as introduced by previous 'fast' programmers). When you need someone with this ability, you really need them because the system is falling over under its own weight.
The truly bad programmers destroy more than they create, making extra cleanup work for competent and productive programmers like me and everyone reading this.
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.
I think what you call it is more complex. As I can see there are three important capacitities: attention to details, working memory and iq (capacity to see patterns, what is tested in iq tests). In my experience they are all important, I'm pretty bad at the first two, and this makes me miserable in my job.
attention to detail correlates with interest in the topic. Maybe find something to work on that you care about a lot of that excites you. If not cultivate your interest. Pretend it's your child then love it unconditionally.
Working memory: Memorize things that surprise you. Then Try to understand why you were surprised. You don't have to memorize things you understand.
In summary, the difference between "fast" programmers and "slow" programmers is not 28 (as per Grant and Sackman folklore), but more in the range 1--7. Specifically, The work time variability tends to be larger for task type “test/debug” (SF50 = 2.4, SF25 = 3.2) and even more for “programming” (SF50 = 2.4, SF25 = 7.1) than it is for “maintain” (SF50 = 1.7, SF25 = 2.4) or for “understand”
(SF50 = 1.8, SF25 = 2.9). Task type “review” is special. It exhibits both low variability
(SF50 = 1.1, SF25 = 1.3) and low skewness.
"Thus, if we ignore the most extreme cases, the differences
between the slowest and the fastest individuals are by far
not as dramatic as the 28:1 figure suggests"
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, you don't need to sprint.
Yes we want to deliver products quickly, but the link between good products, effective business and speed of code writing is tenuous at best. Take your time, line up your shots, and be sure you are a value multiplier. (That's the real 10x programmer. 10x as valuable. That might mean using good SEO techniques to get paying customers, but using boring old SQL back ends)
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.
I suspect that the most important difference between great and typical engineers is that the great ones make a better product, not that they make it faster. If my hunch is correct, worrying about concepts like "10x" is missing the point.
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.
Doing thins faster leaves more space to do more thing faster, not making anything better.
And that's how you end up with a pile of technical debt and impossible to change system.
>>but getting things done faster leaves more time for doing them better.
I don't buy it. Sometimes you need to do things deliberately slowly in order to think everything through. All the use cases, the potential edge cases, failure modes, and so on.
IMO a "10x" programmer is someone who knows when to crank out code and when to take things slow.
>getting things done faster leaves more time for doing them better
I'd love to believe that, but it assumes that the incoming rate of things to be done is and will remain lower than your sustainable velocity. In practice, that "more time for doing them better" has a significant chance of becoming additional technical debt.
hehe in my experience once it's done, it's done- no time to make it better as there is the next feature up waiting and the customer does not buy quality only "quantity" (of features,...)
If X introduces half as many bugs as Y, and finishes tasks as fast as Y, and debugging takes majority of time in the project - then X is moving the team forward many times faster than Y.
I think they still found a large difference between the best and worst developers. Another summary (quotes that I can't seem to format):
The main findings from this investigation of the dataset variance.data can be summarized as follows:
The interpersonal variability in working time is rather dif- ferent for different types of tasks.
More robust than comparing the slowest to the fastest in- dividual is a comparison of, for example, the slowest to the fastest quarter (precisely: the medians of the quarters) of the subjects, called S F .
The ratio of slowest versus fastest quarter is rarely larger than 4:1, even for task types with high variability. Typ- ical ratios are in the range 2:1 to 3:1. The data from the Grant/Sackman experiment (with values up to 8:1) is rather unusual in comparison.
Caveat: Maybe most experiments represented in variance.data underestimate the realistic interper- sonal variability somewhat, because in practical contexts the population of software engineering staff will often be more inhomogeneous than the populations (typically CS students) used in most experiments.
Still only little is known about the shape of working time distributions. However, variance.data exhibits a clear trend towards positive skewness for task types with large variability.
The effect size (relative difference of the work time group means) is very different from one experiment to the next. The median is about 14%.
The oft-cited ratio of 28:1 for slowest to fastest work time in the Grant/Sackman experiment is plain wrong. The cor- rect value is 14:1.
"The ratio of slowest versus fastest quarter is rarely larger
than 4:1, even for task types with high variability. Typical
ratios are in the range 2:1 to 3:1. The data from
the Grant/Sackman experiment (with values up to 8:1) is
rather unusual in comparison."
Even if it isn't the mythical 10x ratio, hiring somebody that can do 3 times more than the next person is a no-brainer. Although I honestly wonder if that baseline is dragged down so hard by all the people that really can't do the job they are supposed to be doing. Programming is hard, and doing it well is even harder. "Everyone can code" movements are great propaganda, but I'll be honest, I've never known anybody that actually could code who wasn't a couple of standard deviations smarter than the average Joe or Jane.
I'm much slower these days than I used to be, and it's because I'm bored. That I need to do my work with a web browser, usually necessarily with internet access doesn't help.
For the last year I've been working on a project that has a complex toolchain, such that every time I hit cmd-s I have to wait 2-5 seconds before I can reload the browser to see the changes. It's remarkable how easily I can get distracted in that short interval, especially if I experience it dozens of times per day.
For the last couple days I've been doing Project Euler with Ruby and the lack of lag time translates into much better focus.
I'm good at tests where you need to code fast and to a high level of quality. But there is no way is keep that speed up for 2k hours per year.
Another issue is of course the person who replays technical debt on every completed JIRA ticket will probably be a bit slower. And the person who removes lines of code and asks if a feature is really necessary is another beast. All that thinking is going to slow down your LOC per second.
The Grant Sackman experiment, often quoted, rarely reproduced.
To «prove» a 10x programmer existence you would need a bi-modal repartition on the percentile of workers/speed.
The grant sackman/peopleware/The Mythical Man Month all try to answer a question that is tricky : what makes someone creative productive?
People focus on the speed. But they are just forgetting the most important part of the experiment.
One of the most important part of G/S experiment that everybody forget is the lack of correlation between performance and
1) diploma
2) experience after 2 years of practice.
Having done more than one job, other fields of works that are also creativity based, the «feeling» was that it is not only about coders but musicians, intellectual professions, journalists, project manager...
What are the implication of the lack of relation between diploma and experience?
1) Diploma are overpriced, the job market is artificially skewed in favor of those who have the money for it;
2) New devs are underpaid, old devs overpaid.
The burden of the proof that a diploma/experience is relevant for a job should be in the hand of the one selling diploma. Diploma especially in computer science seems to be a SCAM
The effect of this scam is :
1) young workers enslaved by loans in jobs they may not be good at/liking;
2) a rigid job market that prevent people from moving hence artificially creating difficulties to have full employment
3) an artificial exacerbated competition resulting in cheating from both sides.
I'm pretty sure that I'm a "slow" developer. Not in terms of actually coming up with the core fix to a problem that I'm working on (that's actually the most straightforward part of any project) but everything else that follows. That is to say writing clean, well-tested, documented and maintainable code. Is this something to be concerned about long-term or should I just accept that my work will always take a little longer to complete than my fellow developers?
One of the slower developers on my team is also very precise and methodical. He gets those tasks which require those attributes. It would be difficult to replace him.
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 slow-fast or new-old or whatever). Also, having tried a variety of interviewing techniques, I find pair programming to have one of the highest concentrations of useful information about a candidate. Work sample being another.
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.
If you're saying that your code is actually cleaner, better-tested, and better-documented than that of your fellow developers who seem to work faster, then I don't think you have anything to worry about, as long as you find a job where the value of those things is understood.
> [] Three of the twelve subjects did not use the recommended high-level language JTS for solving the task, but rather programmed in assembly language instead. Two of these three in fact required the longest working times of all subjects. One might argue that the decision for using assembly is part of the individual differences, but presumably most programmers would not agree that doing the program in assembly is the same task as doing it in a high-level language.
In my experience, making the right decisions like that is the real
difference between good and not so good programmers. Good programmers
do on average better choices that results in less code, code that is
easier to maintain and reason about, and choosing language and architecture
that fit the problem at hand. It is not that good programmers develop
so much faster usually.
I have a feeling that implementation speed is an instance of Goodhart's Law (https://en.wikipedia.org/wiki/Goodhart%27s_law). If you keep everything constant (code quality, amount of tests, documentation, etc) then a faster engineer is obviously better. However, if you start using speed as a criteria to judge engineers, then the easiest way to increase speed is to sacrifice things which make code maintainable and modular.
Finding metrics which work well even when people try to game them is incredibly difficult (if not impossible).
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.