Throughout my career I've definitely been lumping the skills described in this article about not doing work in with the whole "10x developer" catch phrase.
Like:
Customer needs a CMS.
Clyde looks at the requirements for the CMS. He sets off to write hundreds of thousands of lines of code by himself, complete with CI, continuous deployment, tests and documentation because he is a very good developer. Through the course of the project he leverages his years of experience and background in CS and engineering to make a well-factored body of software that will be maintainable for years. He did this in only a couple months.
Bob looks at the requirements for the CMS. He thinks "I know, I will use a good application framework and an ORM". Bob writes a couple thousand lines of code with all the tests and stuff that Clyde had. Bob's tests and app code, however, are more focused on the customer's needs, making in maintainable for anyone who can read the documentation of the software he's chosen to use. It takes him a couple weeks.
Alice looks at the requirements for the CMS. She realizes the customer will do just fine with Wordpress with a couple of tweaks. She sets up a hosted blog so nobody has to actually maintain it. She has better shit to do with her time.
Alice did the least work but that doesn't make her less productive. You're solving problems. If you do work to solve those problems, fine, but having more "output" doesn't make you go from a 1x to a 30x engineer.
Bob says he is a better driver than Lewis Hamilton (the current Formula One racing champion). He puts forward as evidence that he got into his car right before the Formula One race, and drove in his old car at 40 miles per hour until the race was finished. Then he measured the distance from where he started to where he finished (which was about 60 miles). He compared that to the numbers for Lewis Hamilton, who ended up a few feet from where he started.
Bob went farther than Lewis Hamilton, in a much cheaper car, with no pit crew. Hail to Bob, the 100X Driver!
Your scenario is much the same as the above scenario. Different businesses can extract different amounts of value from programmers. Just like you can't tell a high performance car from a low performance car in a school zone, so some businesses are not tackling hard enough problems to differentiate between programmers. In regards to delivering a CMS, there is not much John Carmack or Jeff Dean could do to distinguish themselves in terms of value to the business than someone who just graduated from Wordpress bootcamp.
In the above scenario, if you are just a run of the mill business, that just needs a CMS to post PR pieces, then Alice is the right choice for you. There is also no point in even discussing 10X programmers because a 2X programmer would be a complete waste of money. If on the other hand, your company is looking to "disrupt" CMS, you want Clyde.
Another way of putting: just because Lewis Hamilton would probably be arrested for driving through city streets the way he does on the raceway, does detract from the fact that he is still a better driver than Charlie Commuter.
The fact that, in most situations, one doesn't need professional driving abilities is also not of consequence.
I think people who are critical of the idea of a 10x engineer are missing the point. Of course hiring a 10x engineer is not sufficient to Solve The Customer's Problem. 10x engineers are not fairy dust. However, hiring a 10x is necessary if your customer genuinely needs a bespoke solution, or if you are trying to disrupt an existing tech market.
I would also add that one of the main contributions of a 10x is that they raise the productivity of everyone else (creating tools, providing guidance, simplifying code, etc.). I am not a 10x, but I've worked on teams that have them and teams that do not, and it makes a big difference.
I agree with you, but my quibble with your analogy that there are problem sets that will probably never need a 10x engineer, like disrupting Wordpress.
Looking to create a completely packaged toolset, from a custom linux distro, that orchestrates containers and does config management (CoreOS)? You might need a 10x engineer.
Alice is clearly the 10x engineer in this story. Probably more like 100x. She solved the problem with 100x less work. The goal is to solve the problem.
I know that's what you're saying already, I'm just summarizing.
Unfortunately, it is Clyde who will have the better-looking resume and portfolio (will Alice even have a portfolio?), Clyde who will be held up as the exemplar of the "10X engineer", and Clyde who will be getting his choice of job offers. Meanwhile, Alice will be toiling away wondering why she can't even get any interviews despite the "talent shortage".
Clyde has better experience of actually developing programs. He has exercised and demonstrated his technical skills. For someone who actually needs new programs developed, these skills may help to deliver a substantial amount of business value. For someone who doesn't need the new programs but is poorly incentivized to care, Clyde is also adequate.
Alice may have a fine future in consulting, but if her projects never demonstrate hard-to-find technical skills no one's going to pay hard-to-find-technical-skill money for her efforts later.
Developing new programs is a means to an end, not an end in itself. The need is to solve problems. Sometimes the best solution is to write new programs, sometimes the best solution is to modify existing programs, sometimes the best solution is to tweak off-the-shelf programs.
If you select for people who are good at, and like, writing new programs, then every solution becomes a new program. That isn't the best way to run a business.
> Developing new programs is a means to an end, not an end in itself.
Yeah, so this is just another case of the principal-agent problem. The thing which is best for you as a programmer may not always be the thing which is best for the company paying you. You'll have to find a balance between the two, and so will your employers.
This is a good point. I think the need for new programs has actually decreased relative to the overall need for software solutions over the past, say, twenty years. Between the rise of open source and the fact that lots of software products being built aren't very technically innovative I suspect the relative need for new code has decreased. It's more often about broadly figuring out how best to solve problems.
I wouldn't be surprised if, in response to this trend, we see the formalization of a new "product developer" role at startups that is kind of a hybrid engineer / product manager. This person can code perfectly well, but is also scrappy and really good at getting shit done. The Alice character in the story above would fit this role perfectly. These people can drive way too much business value for their role not to become a defined hiring target eventually.
for Alice, and possibly also Bob, yes, their career advancement is most likely from software developer to product manager or technical lead, to VP of engineering somewhere.
for Clyde, definitely not. Clyde really loves coding as an end unto itself. his career advancement is probably getting picked up as a "unicorn" at a quant trading hedge fund, or joining a project that is coding low-level technology infrastructure at a big tech company like Goog/Msft/FB/Oracle/whatever.
why on earth would you let your developers decide what to develop? Isn't that the role of the product owner/client/management? There should be some back and forth between stakeholders.
I say this as a developer who, if it were up to me, would just spend all day refactoring existing code and not implementing new features or fixing bugs.
Actually, since we all have a finite amount of time, it's entirely possible Alice has solved real problems with the rest of hers whilst Clive is reinventing the wheel.
For the 99% business he's an expensive liability. Sure he might get jobs, but he'll hardly have a career backed by success.
You don't have anything to back that up, though. You know Clyde will make work when he doesn't have to. You don't know what Alice does in the time she has not spent creating a redundant CMS.
Clyde's portfolio will have "built a custom cms from scratch" and then in my interview I'll ask why from scratch instead of using a framework and something like Pinax or one of the Rails CMS packages.
Bob will have "built custom cms on Rails/Django/CakePHP" I'll ask why him the same questions as I asked Clyde along with why he didn't use Drupal or Wordpress or ...
Alice's portfolio will have more in it that just "set up WP site". In fact it probably won't have that in it at all but it might come up during the interview: "Oh, the marketing site? Yeah, I just fired up a wordpress instance, themed it, got backups working and passed it over to IT and got back to my day job."
And then ask, "what was your day job, because I don't need a wordpress themer."
I guess what I'm saying is that if your resume consists of setting up Wordpress sites, then you better like setting up wordpress sites because that's where your experience is.
Your missing my point entirely. This is what the resumes look like.
Clyde: Spent 6 months writing a custom CMS in Perl in support of Project X.
Bob: Spent 2 months writing a custom CMS in Rails to support Project X. 4 months writing feature A and B for Cool Project X while continuing to support the CMS.
Alice: Spent 6 months writing feature A, B, C and D for Project X.
If I was looking for a developer for Project Y, who looks better?
Except in this example the CMS /is/ Project X, not part of supporting Project X
And you gave zero requirements for what you need in Project Y
So I have no idea and no way of knowing who looks better. Maybe Project Y just needs a CMS to go with it. Maybe Project Y needs an extremely custom web application with niche needs.
I think you just barely touched on the lunacy of even debating who has the better resume. You need to actually talk to them and understand what their real experiences are. Besides how do we not know that Alice is actually a major contributor to WordPress or optimizes compression algorithms on the side for fun.
Then in that case, Alice will have features A, B, C, and D of Project Z. She won't have wasted time developing a system that didn't need to be developed in the first place.
I guess all this rests on the assumption that Alice did something relevant in all that time she saved. If features A, B, C and D. Basically you seem to assume that each or some of those are relevant software development work and not just more WordPress deployments.
I guess the point is use pre-packaged tools when possible. But somebody has to write new software, so you better get some experience in doing that if you want to be a software developer.
Instead of "Used APIs X, Y, and Z and languages Foo and Bar", Alice's resume will say "Delivered project on time and under budget that brought in $X,000,000 in revenue to the company."
There are certainly companies looking for the latter.
The story is simplified. The 10x engineer is usually someone who has the technical skills and knows have to deploy them effectively. The 10x finishes the Wordpress site and then moves on to the next task, and the next, and the next completing them efficiently, even though some require technical skills and some do not.
True. 10X is productivity in the context of business value. Clyde will take six months before he can deliver something of value while Alice will have solved ten more business problems with within that same time period.
The key differentiation is: is the company a technology company (Clyde's approach is more valuable) or not (Alice's approach is more valuable).
I feel like much of high level engineering work isn't having knows (sic), at least beyond a certain level. It's being able to grok a narrow problem domain from first principles, write code, then forget it to learn a different narrow problem domain the next week.
Seems unlikely. "Built my own CMS" is not uncommon on resumes and isn't a big draw. Presumably Alice has other accomplishments from the 99% of time she didn't use writing her own CMS.
You are assuming she is given the chance to work on actual hard problems.
Why do you think Clyde wrote a custom cms in the first place? You think he didn't know about Wordpress? In reality he knew but pushed for the custom implementation because it was the best route to improve his skills and increase his power within the company.
The truth is at a typical company Alice isn't going to be rewarded either financially or with better projects.
I wish it was different but if they both worked at the same company Clyde would be the one taking first pick of all the best projects.
Technical Consultants and Solution Architects make more than Coders or Programmers. The main value of Alice's approach & solution is time - the quick turnaround in providing the right solution.
Maybe - but I know which of my ex-colleagues Clyde, Bob, or Alice _I'd_ be calling up and poaching when I needed to build myself a new team in my next role…
Alice will have several orders of magnitude more projects on her CV than Clyde has.
When Alice is applied to a harder problem (that can't be solved with Wordpress), she'll be able to solve it far faster and more effectively than Clyde because she won't have the not-invented-here hubris and will stand appropriately on the shoulders of giants to construct something that will likely be far more maintainable, broken down into saner components, and on the whole, more effective.
Clyde will be valued as a 10x engineer at his company forever, but would probably find it very difficult to start somewhere else where he doesn't have the luxury of having written the entire codebase.
You're assuming Alice only sets up Wordpress, and isn't doing anything else with all the extra time she has on her hands.
And quite frankly, a portfolio with yet another CMS hand made is not impressive at all. I'd ask the same thing: "Why didn't you use Wordpress, or another off the shelf solution?"
I am just not a fan of this. Avoiding Wordpress issues, just using an out of box solution; what if the customer wants specific features? Plugins? Oh those don't exist yet. Do you build your own plugin? Shoehorn some 3rd party system in?
I can't do that. My customers come to me expecting a solution that isn't hacky and just "there". They expect a solution that solves their issues and not tacks on more issues.
I've never seen any good results come from someone doing the least amount of work possible by finding out of the box solutions that half ass most of the features the client wants.
But I have seen many customers come back repeatedly satisfied with their completely custom solution because it has what they want and not confusing or anything, because it's to their specifications.
If doing half-assed work to get the client out the door and a new one in is the best thing, than I'd rather not be "the best".
I think you are fooling yourself into thinking what you want to think.
IME that is fairly common among developers, who after all got into this line of work because they like writing code, not configuring a web interface. So, many developers will tend toward solutions that involve them writing lots of their own code, especially if it involves using an interesting new technology or framework. "Yes, node + Angular would be the perfect stack for your small business brochure site."
But let's think about the probabilities here, keeping in mind the customer wants a CMS (as specified in the parent comment). Wordpress is used by about a quarter of websites. What are the chances that your client wants a CMS feature that no one else has ever thought of before?
It's pretty unlikely. With very rare exceptions, there is a plugin available for what your client wants. You might need to modify the template to get exactly the look you want, but the feature is available. And Wordpress is not the only popular open-source CMS either--there are plenty of options to meet your client's needs.
From your business perspective, using a popular open-source CMS increases your margins: you spend less time building for the same quality. From a security perspective, a popular open-source CMS is superior to your code because so many other people are trying to attack and defend it. From the client's perspective, a popular open-source CMS is more future-proof--they can fire you and easily find another vendor to take over management. Even better if it's a commercially hosted instance and they don't have to worry about hosting at all.
Wordpress has its place for quick, dirty and simple jobs with common requirements however if you are trying to do something a little more complex wordpress is a awful choice.
You usually end up struggling with sub par plug-ins and unintuitive UI's that are a nightmare for you and the customer potentially wasting more time doing that then doing a custom build.
The point is it takes a 10X programmer to recognize when a out of the box popular solution might not be the right choice for the customer.
Installing a bunch of third party plugins is the fastest way to take an already somewhat vulnerable application and introduce security holes large enough to fly a 747 through.
I used to work in the hosting industry - the overwhelming majority of abuse reports against customers were from people who had installed wordpress and plugins and one of the plugins had a major security flaw, and then the customer was off to the races as part of a botnet or spamming.
So you now have to audit the plugins, you have to worry about future updates to those plugins introducing vulnerabilities, you have to worry about a plugin no longer being maintained and becoming obsolete, etc.
Is there a business case for WP and plugins? Certainly. But the blanket idea that you can just drop a PHP application on a server, install a bunch of plugins, and move on to your next more interesting project is extremely naive.
All of these points are valid, none of them are unique to the Wordpress solution.
If you're writing a reasonably complex CMS, you will create security flaws you can fly a 747 through. This is doubly true if the CMS isn't the end goal and rather a necessary dependency for what's actually needed.
The only guard against security holes is battle-testing your code - Wordpress may not be the most secure thing in the world, but it's likely more secure than something you can whip up yourself in a jiffy.
Ditto maintenance and obsolescence - in fact this problem is probably worse for a homebrew solution than WP, since the number of people qualified to maintain this homebrew codebase is approximately one, whereas you can actually hire for WP plugin maintainers if you need to. Likewise, homebrewing your own solution and then moving onto the next project literally means it's not being maintained from day one, which is strictly worse than even a casually maintained plugin.
WP installs aren't always the right solution, nor is deploying some off the shelf code, but choosing to write your own code needs to pass a higher standard than is normally applied in most companies - it's silly to complain that some open source thing might stop being maintained when by default what you write yourself is also not actively maintained ;)
> it's silly to complain that some open source thing might stop being maintained when by default what you write yourself is also not actively maintained ;)
I certainly agree to a large extent, but there's a lot that mitigates this as well:
When it's code you write, you have control over feature creep, documentation, comments, etc.
If you write something that only does what you need, you reduce a lot of the attack surface vs. off the shelf plugins, and you are in a position to make sure that the code commented and well documented. You don't have that sort of quality control over a third party plugin, and you may down the line be in for a rude awakening when it's no longer developer and has a breaking problem, and you open it up and find the code is a completely undocumented mess from top to bottom.
Of course if you're rushing something out the door, you might not produce anything better - but if you're a software shop with solid engineers, you have a high chance of being able to get better quality code out there than a lot of WP plugins.
(That being said, WP today is a lot more secure itself than it was in the past - the right option might be not writing the CMS from scratch, but writing any plugins you need from scratch)
I get your points, but at least with custom code you have security by obscurity. Using out of the box stuff puts you in a higher level of security risk because anyone can access the code and find bugs and how to exploit them. At least with custom code, it'll take some time for them to find something and attack you.
I mean for crying out loud, just installing Wordpress invites people trying to get in using automated tools. You can deploy a wordpress blog at it's default state, and wake up 3 days later to it being spammed.
The bad guys generally don't bother browsing Wordpress code to find vulnerabilities. It's tiresome to do, especially since a lot of good guys are doing the same thing and patching the obvious bugs.
Instead they use automated attacks to test any website directly for the most common errors. Understand that this is not limited to Wordpress. The types of vulnerabilities they test for are universal: password brute force, directory permissions, code injection, XSS, etc.
Sometimes one of these tests works, a site gets hacked, and then the developer has to a) recognize the site has been hacked, b) diagnose the problem, c) patch the hole, and d) recover the site.
For open-source projects like WordPress, the developer can then contribute the patch back to the community, and everyone else can pre-emptively fix their sites, even if they haven't been hacked yet. Bad guys also get these patches, and add automated attacks based on them. These are often what you see in WP logs, but such attacks are easily defeated by simply applying patches when they come out.
For custom-developed sites, you the developer must do all those steps by yourself, and yes that means you probably won't know about vulnerabilities until they are exploited.
The problem with custom solutions I see is that they are usually awesome at the first iteration but when the customer comes back wanting new features each subsequent version degrades. By degrades I mean that it takes longer, it is a little messier, a little hackier.
I believe this is honestly true for most software. The longer something has been around the more hacks it will inevitably have in it. The projects I have seen that last the longest are the ones built with a solid, generic foundation capable of handling all types of requests with minimal user touch.
I am not necessarily saying all out of the box solutions do this well but certainly, most if not all off the shelf parts have been iterated more to hammer out bugs, security issues, get the feel right, etc. than your homegrown bit ever could.
I of course couldn't advocate that wordpress is the solution to everything but if it meets the customer's needs right now and will do so for the foreseeable future, I see no reason not to use a mature, existing framework.
Rolling your own is almost never the best solution unless you are creating something truly innovative. This is almost never the case for client work as they are operating in defined markets. What always fails to get factored in is total lifetime cost - writing and deploying the code is a marginal part of that
Okay, so they need specific features and plugins. Start with WordPress, then write a WordPress plugin to your customer's specifications. You skipped writing 90% of the CMS, which is also tested and secured by a large group of developers. You have a much smaller codebase you're responsible for maintaining.
And what if the client wants a CRM... Do you install a popular CRM plugin, and then tell the customer to ignore 90% of what's in their dashboard, because posting articles isn't something they want?
If I as a client came to a company and said I wanted a CRM built for my company, and they gave me a Wordpress blog with a shitty CRM plugin, I'd request a refund and find someone who is actually going to build to my needs, and not hurry me through the tunnel to get my money and go onto someone else.
But I believe in quality over quantity. I'd rather spend time building a custom solution (Note, just because I am building a CRM doesn't mean I build the whole thing from the ground up, I use frameworks) that is going to make my client ecstatic and return again and again, than be like a friend's company. No good reviews. My current boss told me he had them make him a website few years ago. He said that lets just say he wouldn't be going back to them anytime soon. Why? Because they build EVERYTHING on WordPress.
>>My current boss told me he had [a friend's company] make him a website few years ago. He said that lets just say he wouldn't be going back to them anytime soon. Why? Because they build EVERYTHING on WordPress.
Sure, but that sounds like a strawman. The lesson in the original post isn't about building EVERYTHING on WordPress. It's about knowing when to use existing tools and solutions instead of reinventing the wheel.
>>I'd rather spend time building a custom solution... that is going to make my client ecstatic and return again and again
It completely depends on the project. If it is for a mission-critical application that needs a lot of custom, well-designed features, building it yourself might make sense. Otherwise using something someone else has built is just as likely to make your client ecstatic because you just saved them a lot of money and time.
> And what if the client wants a CRM... Do you install a popular CRM plugin, and then tell the customer to ignore 90% of what's in their dashboard, because posting articles isn't something they want?
No, I tell them to pay for Salesforce, because I'm not going to build something as good as Salesforce in anything approaching a normal project's budget, and I introduce them to trusted Salesforce consultants I know. It's more important to me that they get the right thing rather than pay me to do the wrong thing. And if you are building a CRM, even with a "framework", for any sort of business under, say, ten thousand employees, it's very likely--not without exception, but I'm betting hard in this direction and I will very rarely lose--that you are not doing the right thing for your client.
> If I as a client came to a company and said I wanted a CRM built for my company, and they gave me a Wordpress blog with a shitty CRM plugin,
The parent comment at the head of this subthread specified that the client wants a CMS. That's how we got on the topic of Wordpress to begin with.
I agree that Wordpress would be a terrible platform for building a CRM. But I am dubious that anyone needs a custom CRM. There are literally dozens of commercially available CRMs at all price points and industries.
That's just an example. I am building a custom CRM as part of a service right now. Or should I shoehorn Salesforce into this service and tell all my customers that to use that feature of our service, they have to also have a membership with salesforce?
My customers pay me for the features I am building all into this service... Not to charge them to hook a membership for another company up to it.
Then I have to provide support for Salesforce. Their service goes down, now I have my customers mad at me because part of my service is down.
Giving the customer direct ownership of their CRM database is a feature, not a bug. They will benefit from a CRM development team who has dedicated experience and expertise in CRM, plus they'll benefit from the feature and security requests of the other CRM customers. And it will make them less dependent on you, specifically. Which, from the client's perspective, is a good thing.
Edit to add: what's more likely, that Salesforce goes down, or that you are unavailable for some reason?
"And what if the client wants a CRM... Do you install a popular CRM plugin, and then tell the customer to ignore 90% of what's in their dashboard, because posting articles isn't something they want?"
No, you modify the template so it's not showing the stuff they don't want. Problem solved.
"If I as a client came to a company and said I wanted a CRM built for my company, and they gave me a Wordpress blog with a shitty CRM plugin, I'd request a refund and find someone who is actually going to build to my needs, and not hurry me through the tunnel to get my money and go onto someone else."
And if I was your boss, I'd fire you for wasting my money.
"But I believe in quality over quantity."
Nobody here is any different. The difference is that I don't think that the only one who can deliver quality is me.
"I'd rather spend time building a custom solution (Note, just because I am building a CRM doesn't mean I build the whole thing from the ground up, I use frameworks) that is going to make my client ecstatic and return again and again, than be like a friend's company."
And again, you're assuming that result isn't possible with an off the shelf solution.
Custom software is a business risk not an asset. Your company processes and people become dependent on workflows that lock you into the software. You become beholden to a single vendor, and eventually the pain of switching away from a woefully outdated system becomes all but impossible. Just ask the companies that still rely on hundreds of millions of lines of COBOL.
To add to this: Very old custom software located on internal systems is one thing, imagine if you are relying on 15 year old web-based software from a vendor that no longer exists. How do you protect that?
I think the point is that the developer should attempt to understand what the client actually needs and act intelligently to determine what tools or technologies would be best for the job.
If your client have the money to pay for the n months of work and maintenance, it is fine. I think most people try to use this solution because budget and time constraints.
> She sets up a hosted blog so nobody has to actually maintain it.
Somebody has to maintain a Wordpress blog, keeping it updated and the plugin list pruned to reasonability. That somebody may be the end user, but a non-technical user maintaining a piece of business-critical software carries its own set of problems.
Someone years ago at my company solved this problem by integrating Wordpress into their own home-baked e-commerce platform. The platform wasn't maintained, Wordpress wasn't maintained, when I came in years later, I found a mess that wasn't even worth maintaining anymore. Eventually it broke. I refused to fix it and so we moved to hosted Wordpress just like Alice.
My solution would have been to find a Rails-based self-hosted blogging platform that I could integrate into my daily workflow. I told them I wouldn't be able to help them if Wordpress breaks and that Wordpress gets hacked all the time. I could have gotten it up in a single day, no big deal. No dice.
Company politics and strategy determine how productive a programmer is. Make him/her do stupid shit and they won't get much done. They say they don't want silos, but then all their technology decisions do is create silos.
"Hosted blog" here means someone else is maintaining it -- Wordpress.com or some other provider. You pay a little bit of extra cash, and you don't have to spend hours deploying patches.
They can't secure Wordpress for you. You still have to do that yourself. Wordpress plugins are chock-full of holes, probably the biggest attack surface this side of Windows XP.
In a lot of cases with the 'hosted' platforms, you're limited to a handful of 'approved' plugins that have been vetted and are kept up to date for you. So... you're getting protected, but losing out on one of the primary reasons people choose WP in the first place - customizability. But it's not the reason everyone does, hence the hosted places can still thrive.
Sounds great in theory. But what about the business perspective? Alice fixed your problem but Clyde gave your company a new product which can bring revenue and become even more profitable that your existing products.
Remember Slack? They needed to chat. Alice said "let's use mIRC". Clyde implemented an IRC clone. Now Slack is a billion-dollar business...
If you want to post animated gifs and embed youtube videos you can't use IRC. Everything depends on the requirements. To find the right solution you have to understand what your client needs, not what he thinks he needs.
A lot of assumptions that I think distract from the important - understanding the need vs solution first thinking.
The business might not be out to build their slack, chat could just be enough of a transformer alone. Besides, Slack is IRC client re-skinned with a bit different rendering. It's not the first either but maybe a business case is good enough to just chat as a big improvement.
Many organizations do just fine using something like Microsoft Lync, as much as I like Slack it's not for all users or instances.
Alice would make a lot because she's billing as a consultant that evaluates needs and produces a working, scalable, "runs itself" solution. She's not being paid for making WP sites, but for identifying that your complex needs can be satisfied thereby.
It's like the old joke, "I'm not billing you $500 for tightening a screw; I'm billing you $500 for the expertise needed to recognize that that was your problem."
(In my work, there have been times when I spent a week working on a problem and ended up with pull request changing only five lines, but it took a lot of research to find out exactly how to change those five lines.)
That's not quite true. He mentioned Alice has better shit to do. She realizes that there is other more important work to do and building a CMS is not the thing to spend time and budget on.
If you are making a marketing website, Wordpress is great. Also, all marketers and bloggers know how to use the admin. I have seen several website projects go off the rails because some developer involved felt that they were too good for Wordpress and turned the job into a personal hobby horse with some "superior" framework that resulted in an end product unusable by anyone else.
Even better if they use their "own" superior framework, because they can do better than Wordpress :D
Well, I saw both. Wordpress and Typo3 filled with dozens of custom modules and "from scratch apps" with half baked solutions.
Maybe it just feels to me that the customized CMS-consultancies are in the majority, because they do their stuff for marketing-customers, so they have more skill in getting the word out.
Slightly irrelevant: I once was in a team where part of the solution involved one dev "hacking Drupal into oblivion" (seriously, that description is incredibly apt). In the end, he had a nervous breakdown and quit the company.
This was mostly caused by unreasonable expectations and a tremendous pressure on the poor guy, but I still like to think that trying to turn Drupal into an eldritch abomination had something to do with it...
When the next round of layoffs come Alice is the least needed, so unless she is good at making sure everyone knows she gets the best solutions, she's likely to get canned.
Then when they apply at the new job at the local starup Alice is surely going to fail the first round programming quiz.
You are making the fallacious assumption that this is the one and only thing that Alice has ever done, because it's the one thing that we've talked about, and it is therefore the one thing under the metaphorical lamp post that you're thinking about.
If this is a pattern that recurs over weeks, months, and years, the delta in results between Alice and even Bob, let alone Clyde, only opens wider. Alice will surely have other opportunities to do "real programming". Granted, the way Alice is doing it may not be immediately impressive on its own but if it has someone else to compare against it becomes more evident.
I can say I've seen the Clyde solution before, but cpdean's story is rather optimistic. In the real world, the Clyde solution actually delivers late, is usually badly bodged together under the hood due to the too-late recognition of the impending deadline, and will actually create an ongoing maintenance nightmare as his code will be buggy and yet not perform very well no matter how much he bangs on it. In the real world, this sometimes gets combined with a bad manager who sees Clyde engaging in heroics and thinks Clyde is dedicated and stuff, but this is far from a sure thing. That's a very specific kind of bad manager and Clyde would be well advised not to count on having that exact kind of manager. (Heck, I've been Clyde. Very educational. Terrible use of resources.)
That's an awfully pessimistic view, and assumes that she is the only one that sees the value in this situation. Also, nowhere was the assertion made that Alice was not a competent programmer that couldn't pass a test, merely that she used her time more wisely in this situation.
Why does everyone assume that Alice just sat on her ass the whole time? That she doesn't know how to program just because she knew she had better things to do than bring yet another half-assed CMS into the world?
Sure they do. For someone who is a little bit tech savvy, but not senior engineer level, there is pretty good money to be made setting up Wordpress sites and the like. This person can be an interface to the small or medium business owner who knows nothing about the interwebs but needs to get a presence online.
Alice learns that problems can be solved by changing problem scope and re-using existing tools. She ends up fighting with her customers over what they really need and fighting with her tools over what they were designed to do. Someone who isn't averse to writing code fixes the problem.
You seems to be suggesting that the only way to solve a problem is to write code, and that's precisely the point that that article is trying to address; That you don't always need to write code to get something done.
It's the same reason why when you need to build a website you don't build a web server from scratch (unless you do in which case, godspeed).
Again, why do you assume that she's not averse to writing code? Why do you assume that she just forced Wordpress on people, instead of doing the same analysis that Clyde and Bob did?
I think build vs. buy is a tangent debate. Engineers should build software that is the core competency of the business. Within that we can definitely debate who is 0.1x or 10x and whether less is more.
A problem here is that the project is rarely described as "customer needs a CMS". If that really truly is all that's needed, and presented as such, yes... use an off the shelf thing that has other benefits.
Usually there are a lot more gotchas that need to be addressed. Maybe WP is a valid solution, with some customization, or maybe it's not, based on a bunch of other factors the client presents (existing integration needs, skills/experience of other staff, etc).
Understanding/parsing/coaxing requirements, and setting and managing expectations... both of those are much larger factors in someone's success than lines of code, of speed of coding.
When the client reasonably comes back and says "oh, and we need XYZ to happen and tied in with the CMS". Well... you're now on a 'hosted wordpress' platform and don't have control of anything, so the tie-ins the client needs are basically impossible (or... require 10x the amount of work compared to Bob's solution). These scenarios happen. We can't always predict them, but with enough experience you should be able to predict many/most of the potential use cases (at least out a few years in the future).
I don't feel 10x means producing 10x as much code, it's getting 10x results, often with a lot of pragmatic approaches, like Alice does in your example.
"You're solving problems. If you do work to solve those problems, fine, but having more "output" doesn't make you go from a 1x to a 30x engineer."
No, you're not only solving problems.
Especially with a complex stack of software, you also try to stay in control. This could mean, a library or a third party software adds a clean, encapsulated and controllable part to your software.
This can also mean, you add a library, it works, first, but then you discover bugs and missing functionality. What then? Raise tickets on the third party software and wait and swear? Write code around the bugs, until they are solved (a 100% loss of developer time). Add required functionality to the library, which makes you depend on the installed VERSION and each update requires more time invested.
It is a decision, how important the job is. Developing key functionality in house, not to re-invent the wheel, but to stay in complete control, can be a time saving option, even if it takes weeks of initial investment that could be saved with a third party solution.
The discussion, who is more productive, becomes then really a side problem.
Honestly though, I make a living replacing Wordpress sites for clients who have gotten frustrated with how easily Wordpress falls apart when they try to customize it. We have an in-house CMS that does not have anywhere close to as many features as WP does, but features is has are robust, secure, and can be customized exactly as requested.
Exactly my thoughts as I was reading the article. To me, a 10x developer is 10x more effective, not productive. This encompasses everything and is very hard to measure, but I think the point is there is the potential gap in the value of an employee, which doesn't exist in many other industries.
Jane did even less work by outsourcing the task to a guy she found at rent-a-coder-for-peanuts.in, so, clearly, Jane is the one who is the most productive there.
People down-voted this because they hate outsourcing due to code quality etc, yet they didn't down-vote a managed wordpress hosting solution.. seems like a double standard.
The flipside of this is that using a framework without first understanding it is asking for trouble down the road. If you look at Rails and go "Great! Now I don't have to understand how the stack works, I can just put some templates down and have a custom blog!" you're going to be the guy who discovers that his system is slow and riddled with security vulnerabilities because you didn't take the time to understand how all of the parts of the platform interact.
This is why I always groan when I see a "solution" that involves bolting together dozens of different libraries (all out of date because updating any one would break the rest of the system) I know I'm in for a long day.
Using libraries is certainly a good thing and saves lots of time and effort in the long run, but they take more thought than most people are willing to put in. There are no shortcuts if you want to keep your company out of the newspaper as the next big data leak.
Wordpress is an excellent example. Even if you have the basic system down and have the management handled (either in house or externally), there's a dizzying array of interactions with the plugins that can shoot your foot right off. And don't think the Wordpress developers thought of all of the edge cases for you, they have their hands full on the main platform:
At the very least you need to know enough about any solution to deploy to turn off all of the features you didn't configure/don't understand/don't need. So many vulnerabilities these days happen in features you didn't even know you had.
I know the popular saying is to never write code that you don't have to, but IMHO it's less of an evil to write your own couple of hundred lines of glue than to pull in a 100MB package that depends on a dozen other packages just to get that one mandatory piece of functionality.
Most code rot comes not from the code itself going out of date, but from its interactions with external dependencies. Managing the number of dependencies makes maintenance easier in the long run. There's nothing worse than a mandatory security update for a module that breaks another external module that is no longer maintained upstream.
As opposed to whoever inherits the hand-rolled codebase, who will get to discover (after spending three months deciphering the architecture) that the system is buggy and riddled with totally-unique security vulnerabilities because the original author was a fallible human being. YUUUUUGE improvement.
Amazingly, yes, it is an improvement. Having the code all in one place and not spread across a dozen different frameworks makes it tremendously easier to figure out how all of the parts are fitting together.
It's the difference between having to figure out a few thousand lines of code written by a small team vs. having to parse through a million lines of code written by several different teams, some of which you don't even have because they only distribute the binary module and of course you don't have a support contract (if they are even still around). If they had a support contract they wouldn't be calling you.
The one big thing you lose however is StackOverflow. Usually bugs in frameworks have bitten people before and they'll have posted solutions online. This can be a big help, unless your client has a particularly unusual set of modules installed that are exposing some new and exciting bug.
> will do just fine with Wordpress with a couple of tweaks.
I see there's already some WP criticisms, right or wrong, in replies to this. I just want to point out that Drupal would take care of this use-case just as quickly and you get a wonderful ecosystem of battle-tested modules and, ignoring a couple security fuckups, really nice secure code compared to WP, or most popular FOSS projects for that matter.
This problem shouldn't be WP or custom code. I find there's almost always some FOSS project that stops me from writing new projects. This wheel has been reinvented so often, that there's often a pro-level project perfect for a lot of business use cases.
Not to attacked new CMS projects, but if you're going to create a new project your first question should be "What can I do here that Drupal isn't doing already? Or that Drupal can't do with just a custom module?"
the CMS example is kinda wrong here. What about something that you don't find "off the shelf"? e.g. video processing with hard memory/cpu constraints; in such situations, the real 10x engineer will outshine most others.
the "plumbing" type jobs are NOT real engineering problems to begin with, but of course, they generate more "business", in general.
I guess people who design bridges are not "real engineers" because so many bridges have been built before and they are only plugging together load formulas that someone else came up with.
We're talking about a hosted blog, ie., creating an account on WPEngine or similar and sending the credentials to the user. If there was a similar service for bridge building ("choose two points on a map, swipe your CC, get a bridge"), the person using it wouldn't be doing engineering, no.
How come it is not engineering? Engineering is all about solving problems. Good engineers solve problems with less work and time and achieve same or better results (high efficiency).
I agree. Good engineering is about efficient outcomes.
The 10x meme is a software thing. From my experience as an engineer outside of software it is rare to be working on something by yourself mostly you are part of a team and you get the best results by leveraging the strengths of each engineer in the team.
To use the example in this thread Dan is the engineering manager, he assigns the latest project to Clyde. Clyde knows he is going to require some modelling work and that Alice is the CFD expert so he asks her to model some cases for him. He recalls that Bob worked on a similar problem for a different client a few years ago so he wanders over to Bob's desk to chat with him about what worked and what didn't. During the conversation Bob mentions he read a recent paper that might be relevant...
Clyde doesn't need to be 10x as efficient as Alice or Bob because he knows they can get more done by cooperating then by competing. That is efficiency in action.
It is true that's what 99% of us will see/do. But that doesn't change a basic fact about good engineer - being able to solve "yet unknown/unsolved class of problems" and not just be able to solve "JUST yet unsolved problems". Plumbing is generally about solving "JUST yet unsolved problems" whereas engineering is about the former. Yes, good engineers will also be (will have to be) good plumbers and that's where the 10x thing comes into play in a big way.
One of the first mentions* I saw on HN about the elusive 10xer was an article about the exact types of gains the author of this article is talking about -- a 10xer knows where to apply their effort and as such is an order of magnitude faster in achieving the business outcome, not producing LOC.
I feel like the author has wrapped up some sensible expectations for any senior developer and then soiled the content with a clickbait title.
* something to do with using a sticker printed on a transparency instead of some computer vision project.
sadly it's precisely what business are not gonna doing. measuring developers by LOC instead of business outcome allows to detach their worth from their productivity, albeit the metric is flawed in many ways it's better to say 'you produced X LOC, here's a 100$ raise' than 'your solution saved us 100M$, here's a 100$ raise'
I've worked in multiple fortune 500 companies and startups at the entry and now management level and been involved in Web Development for 20 years. I've never seen a LOC report except when we run some games with the other devs to see # of changes in GIT or other source control.
Likewise, in my experience across many different sizes of company I've never seen LOC used as a productivity metric.
The one time I've seen LOC taken seriously was when I've been asked to produce a LOC report as part of a due-diligence audit of a codebase prior to acquisition - that's largely because the line of code count of the codebase is indicative of what code IP auditing/security auditing/localization might ultimately wind up costing the acquiring company so they're using it to figure out entries in the liability column, not even valuing the codebase based on LOC count.
Can you tell me which companies you've worked for that determined developer value by the effect on the bottom line? Because I'd like to send them my resume.
Yes. Just because we all recognize that LOC is a shitty metric, doesn't mean that the industry has figured out what a good metric is. Measuring developer productivity and impact remains an unsolved problem. It still amounts to gut feel, and mostly whether or not your manager likes you or not, i.e. how much of a thorn you are to him/her.
I'd be totally OK with a "lines of code" metric. If that was what my raise is going to be based on, let's do it! At least it's a metric and I know about it!
I've worked at my fair share of companies, and not one of them based raises/bonuses (for engineers) on any kind of quantifiable metric or KPI. It basically always comes down to whether your boss likes you, or how much self-promotion you're doing, or what phase the moon is currently in, or some other wizardry. It's never a concrete metric that you can track your progress against throughout the year and know if you're going to succeed or not.
One of the questions I ask in every interview is: Is my compensation entirely dependent on my job performance, and if so, what metrics are used to evaluate my performance. For some reason, nobody seems to have a good answer for that seemingly simple question. Sometimes they'll say "yea it's performance based", but when you press for what they're measuring, you won't get any information. So I'll take the job, and a year later annual review time comes, and lo and behold, it's "Here's your [good|bad|neutral] (it doesn't matter) performance review and your 1.5% cost-of-living increase!" Very demoralizing. Show me a place with clear, transparent, quantifiable performance metrics, and I'll beat a path to your door.
This, to me, is a common fairy tale technical people like to tell themselves to justify not getting involved in the social connections (aka politics) necessary to be fully successful. It doesn't matter what metrics you choose, because they will all be gamed. Just like the politics is gamed. And no matter what game is picked, certain people will just not like playing it, and will bemoan the choice and why couldn't they have picked X, some other random metric that will also be gamed. But at least they like that game so they'll play along and possibly even excel.
I have seen this in the contract in some industries in Sweden. The people that has an optimization idea that saves the company money gets a percentage of what the company earns on the optimization the first five years or similar. Have also seen a few court cases where the company didn't pay out but was forced to pay :-)
I wonder how well those bonuses are received when the payee realizes the tax hike on anything about 36k SEK / month, or whatever the limit is these days. Sweden's tax system isn't very bonus friendly, so unless the bonus is so significant that it's worth the tax cost it's just not that great an incentive. For example, a 10k SEK isn't that meaningful a bonus, since anything above the 432k SEK / year is taxed at ~50% – unless you're ok with that you'd probably want to look into other options.
I left a company because the code I'd written generated 600k in extra revenue (it hooked up their sales system to Amazon) and got a 2% pay rise "just like everyone else". When it came to the review, I did ask, what more I could have done to get recognised.
Wrong way to look at it. Start a company and gain an understanding of what it will take for you to be in a position to have someone write some code that increases your sales. Infrastructure, capital, product, systems, risk, positioning, reputation, marketing, etc. perhaps then you will understand.
I had a sales guy once tell me, as we got a new hardware product ready for manufacturing, that we'd figure out how to split the profits once we started shipping. He felt entitled, even though he'd only been with us for six months. He conveniently ignored the fact that this product had been in development for nearly ten years during which time I invested millions into R&D, marketing and building an infrastructure to support the product internationally. I let him go a few weeks after that comment. Wrong attitude and a complete lack of context.
I actually prefer to hire people who have had some entrepreneurial experience. They make far better employees. They are independent, hard working, no-bullshit on-mission because they get it. Pay them well and unleash them for great results.
The important part of the parent comment was "just like everyone else". For people who are employees, not stakeholders, recognition for success is important and the parent clearly felt they were not being recognized relative to their peers for what they were doing.
1. How much independence did the OP show creating the Amazon hookup? Was it his/her baby? Did they push forgot to happen? Or were they just rotated onto the project and it came with the next item off the backlog?
2. Was the OP the only one to add value that year? Was the value they added more than others or about the same.
Without these two it's hard to see if they should realise they are just an employee and have no leverage or if they did get shafted.
I think we all need to have more P&L responsibility in our jobs - software is about creative capital and should be highly leveraged.
Maybe we should all go back to the partnership model?
Right. Timeline and comtex is missing as well. Also, in general terms, I think it is a bad idea to go to management or a company owner amd battle for a out-of-band raise. This is particularly true if one lacks context or visibility into the other layers that make-up the organization. It can make someone look clueless, selfish and not a team player. Nobody wants needy problem employees.
To me context is very important. Most of the frustrating moments I've had with employees has been with sales people. They come at things from a very different perspective when compared to engimeers. Most business owners I know have the same "chills-down-my-back" reaction when asked about sales staff.
Anyhow, I had a sales guy demand commission for closing sales at the office. The problem is I was spending tens of thousands of dollars per month in marketing and hundreds of thousands per trade show to make that phone ring. The job of a sales person is to go turn over stones and find business. What he was doing was taking orders. You don't pay someone a salary and commission (in a small company) to sit idle while fish jump into the boat. You pay them to fish. Anyhow, that guy was gone too.
The best sales person I had was this 20-something girl who did not know the first thing about selling. I hired her to help at a tradeshow. I noticed she was great with customers and bery comfortable with technical material. I hired her as a sales person and trained her over several weeks. She easily made twice the salary of the best sales person I had up to that point. Changed her life and gained an absolute gem of a team member.
Perhaps the real point here is that that's what you want to become: so good that you cannot be ignored. Business owners or management love to throw money lavishly at things and people who produce results. Not one time "got lucky" results but consistent dedication to the cause.
"push for it to happen" -> "push forgot to happen". It's like being whipped with a Markov chain.
My personal feeling is that anyone drawn to sales has a belief that they can magically make the world / other people / their mother do what they want simply by using the right words / form of persuasion. Its a belief in magic instead of science and it should not be a valuable skill in the 21C. Calling it a Reality Distortion Field is not improving the situation.
OP here. The Amazon hookup was one of the big projects but was a huge undertaking with high visibility and I was left to deliver it on my own.
It was an intense time with me cutting holidays short and very long days. I wasn't expecting a "cut" of the profits but it was very much about being recognised for the hard work I put in and that it was a good piece of work.
I felt I had gone above and beyond for 3-4months. I wasn't bitter. I just realised that after the derisory pay-rise, that it was time to leave.
I still miss that place. It was full of good people (some are close friends) and I did some really cool stuff that made a massive difference to the operation of the company. Would I go back? Yes as a consultant/contractor but not as a permie. I know my worth.
After that I joined an immensely challenging start-up which unfortunately failed and am now consulting and looking to bootstrap an idea in the summer ;)
I hope it is obvious that it is impossible for someone to grasp the entire dynamic of your experience based on a few short posts. This requires a long conversation where one would explore and try to understand the entire context. I can't fault your or praise you in any way, not enough data.
In general, though, I'd say business owners (and good managers) are hungry for good employees who "get it". And, if they are smart, they'll recognize these employees.
But you also don't want one-hit-wonders. What you are after are people dedicated to the long term mission. Anyone can bust ass for a few months, get a raise and then proceed to rest on their laurels.
Recognition for good people often comes in the way of raises and promotions over time. You might invest a few years at a company doing good work and contributing value yet not necessarily see much in the way of praise and adoration. And then, one day, you get a promotion. Because people are watching and paying attention. That's the way it works in some places.
I once worked at job where a bug fix or 'feature' could directly result in sales landing a $1M+ deal. I was fortunate in that it was a growing company and my boss recognized what I was doing and promoted me accordingly. Subsequently when growth leveled off, there was no more recognition other than paltry annual bonus/raises. We lost some good people due to that situation.
me neither tbh, but it was a relatable sample. there still are plenty bullshit metrics out there at the same level of LOC, I used the worse to get the point out
I've been judged on this before. Me and a colleague were working on a system slightly different to others in our dept so the tickets got kicked around for ages after we'd done our bit. My manager kept pointing out how few tickets I'd closed. He eventually realised his error after both myself and said colleagues manager pointed out why but still occasionally referred to it in performance reviews. Moral of the story for me was: a) Figure out asap how a particular manager tracks your work. b) Get your own way to measure productivity so if/when it comes up you can say 'wait a minute I've done x'
or c) optimize your use of the tool to beat the metric. This doesn't necessarily require you to change how you're doing your job. The metric is "more tickets closed?" Great! Let's file more and more granular tickets for each and every sub-task, so that we can close hundreds of them a month.
Sales people know this. They might not even know algebra, but if you make their commission/bonus dependent on a KPI that depends on multiple variables with multiple weightings, they will turn into Einstein overnight to optimize their behavior in order to maximize their bonus. You get what you measure.
sadly it's precisely what business are not gonna doing.
I've spent much of my career doing close to nothing, with pay increasing each year. Many businesses seem to recognize it and reward it. I've never had an employer who measured contributions by LoC (though unless you've proven yourself of course there is some measure of productivity, such as stories completed, etc. Everyone knows what everyone else did).
As stated in the root of this thread, this article completely misses the point of the 10x engineer, to the point of almost parody. The 10x engineer is the one who builds the tiny core of an app that makes everything else easily possible. Or who moves the whole team from one derlict, no longer useful technology to another. And so on. It has never, ever, been "the guy who spits out 10x the lines of code".
The problem is that any nontrivial savings or profit is almost never done by one person or can be traced back to one person or one job; in established companies it's a large team of management, developers, testers, etc which all work together to create value. You could argue that you can pinpoint it in a startup, but that's why a lot give shares to its employees.
Jeff Atwood: “the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options.”
Robert Galanakis: “The fastest code is the code which does not run. The code easiest to maintain is the code that was never written.”
A father of these being, as usual Dijkstra: in his EWD1036-28 "On the cruelty of really teaching computing science" (1988-12-02) he notes
> it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
(emphasis mine)
Though of course "lines of code" in Dijkstra's essay is itself only a proxy, a line of Java code and a line of Perl code have fairly difference costs.
I do not think a product with zero lines of code is always better than a product with 10,000. So there is obviously some metric that goes up with lines of code but goes down with bugs and technical debt.
Sometimes the downswing from a single line is so dramatic, that such maxims are expressed... but don't take them too literally. Let's be real here.
Which is why Dijkstra's take on it is excellent: the LOCs you write are a liability. Incurring liabilities is normal, but your goal isn't to maximise liabilities.
That might be a good way for engineers to think of it, but you don't really want managers to see programming as a liability, because then they start thinking in terms of eliminating liability for business productivity (i.e. killing your job, not investing money to let you do your job effectively, etc).
There's already enough problems with companies considering their tech departments to be "cost centers" that don't result in direct revenue generation, therefore they don't respect the department enough, we don't need them thinking we're completely undesirable.
But it is a liability. If your business could generate the same revenue while spending less resources maintaining internal technology, you'd do it in a heartbeat.
I don't really get what this "cost center" thing gets you at all. Suppose you make televisions. R&D is a "cost center". Whoever's in charge of sourcing components is a "cost center". Hell, making the damn TVs is a "cost center". In fact, the only thing I can think of that isn't a "cost center" is sales. But without everything else, sales would have nothing to sell.
So what the heck is the point of labelling things "cost centers"?
In the same way, spending $0 is not always a better choice than spending $10,000. You're spending the lines of code with the hope that your return on investment makes the liability worth it.
Think of lines of code as surgery to excise a tumor.
Of course you want to remove the tumor. Curing cancer is the goal. But each surgery is a liability; each scalpel cut you make may bring potentially fatal complications, so you strive to perform as few surgeries as possible while still saving the patient.
Rewarding LOCs is like rewarding the high number of surgeries a doctor had to perform on a patient in order to save him/her. It's backwards!
These are the clever quip advice that I know and understand but can never really use. Clever, but completely and hopelessly useless to me.
To get better at coding, I have to be prolific with writing code. Prolificity doesn't have to mean verbosity. Be prolific but do it succinctly. Code like Hemingway wrote.
(The irony in this post is apparent to me, thanks.)
It didn't say the best product. It said "fastest" and "easiest to maintain" code, which are only two of hundreds of factors for success. Many of which are not code related.
Well, technically (or even theoretically I'd venture), empty space is the best MVP of all time. :p It required no code (baring any metaphysical interpretations of the term) and it still functional to this day. :p
MVP doesn't have to involve custom code (or any code at all for that matter). See most startup landing pages or kickstarter for example which test interest in an idea
The fundamental point ("less is more") is a good point that is needlessly obscured by a layer of buzzword-talk ("10x engineer", etc.). Using the buzzword-talk makes for a nice clickbaity headline, but as a consequence, the author spends at least 30% of the article addressing and explaining things related to the buzzword of choice. Such discussion is of little substance. Ultimately, the article can be distilled to a few central tenets (e.g. "don't build anything unnecessary -- think about the human costs of maintenance"). I consider this somewhat ironic: the article, which is chiefly about avoiding cruft in production, contains a fair amount of cruft.
This whole article misses the point of what productive means and why 10x developers are paid hundreds of thousands of dollars at Google et al.
Basically, the author has defined 0.1x to be EXACTLY what people mean when they say a 10x Engineer.
All of this "non-productive" stuff they are mentioning is the actual productivity that the 10x Engineer delivers. Somebody who writes hundreds of thousands of lines of unnecessary code is, by definition, not a 10x Engineer.
In the interests of context and actual references regarding the 10x thing, I have canned response that I churn out:
The 10x programmers thing; from a 2nd edition of Peopleware, the 10x programmer is not a myth, but it’s comparing your best to your worst – NOT best to median (it’s also not about programming specifically; it’s simply a common distribution in many metrics of performance).
The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on your best outperforming your median by a factor of 2.5 (this of course indicates that if you are that median developer, middle of the pack, you’re already a 4x developer under this numbering scheme).
Obviously, this is a statistical rule, and if you’ve got a tiny sample size or some kind of singular outlier or other such; well, we’re all adults and we understand how statistics and distributions work.
Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources.
To be clear, DeMarco found clustering, so it's not your best to your worst, where you refers to a given organization. The gap appears only when looking interorganizationally. In the measured comparable tests they did one company had a lot of highly effective programmers, another company had a lot of ineffective programmers, and it wasn't common to find mixtures of both kinds at any given company. So at a given company it will appear that everyone is similarly productive, and the people there may tend to believe 10:1 is a myth. The 10:1 is only apparent when comparing people interorganizationally.
Also, of course the productivity was not in terms of LOC per hour, but was in terms of several elements regarding solving a given problem correctly. In general the highest productivity people solved that given problem in 10x less time using 10x fewer LOC and 10x fewer bugs than the lowest productivity people who used more LOC to accomplish the same thing, introducing more bugs in the process, and taking more time to do so.
when I started as a trainee dev I was paired with a more experienced dev on my first project and one of the things he was fond of saying was our first role was to challenge the need to build anything at all. This had a significant impact on the project by identifying quite a lot of features that the requirements document had classed as necessary but the users and managers who would use the system confirmed tat they were nice to haves and would not be needed for at least 18-24 months as the functionality that was needed for them to be useful was not built. 2 years later and the functionality has still not been built and it has no time frame for making it into production. Cutting out those jobs early on saved a lot of hassle, time and money and I have carried that thought process with me as we go.
Yes, that is one of the main things for everyone building something be it a bridge or a computer program. Your job is to outline what the customer realy needs, not what fancy words came up on the radio last night. :-)
This is what you do in many agile methodologies. Have the stakeholder rank their stories, understanding that it's a queue you will pull from. They're free to rank them however they want (so 'urgency' doesn't need to be defined; it's entirely on them to subjectively figure things out). As a dev, you just pull from the top.
This doesn't, however, help reduce waste in the same way that pushing back and questioning the need of each story. Oftentimes the stakeholder will think "this thing is super important", without realizing its functionality is unnecessary, or is already in place if you just do some simpler or better thing, or will be useless without some other story done first (that isn't ranked higher). You need to help point these things out.
A real life example I can give is on a project I had in the past, where we were replacing an existing software solution. The customer was adamant that they needed to be able to specify what piece of hardware a job was run on. They were used to the way the existing system worked, where that was the only way you could keep track of where the job was, to see its status, cancel it, etc ("I put it on machine #44, so let me scroll down to machine #44 and see the job"). We wanted instead to just automatically assign the jobs for them, and provide them a search and filter (which they already wanted and had ranked highly), to be able to select, say, just the jobs they had created, that sort of thing. No matter how we tried to explain it, they didn't see that the latter would completely supplant the former, so why do the former. We ended up doing both; they ended up never specifying the piece of hardware. Other places on that project they -did- listen to us, but that one sticks out in my head the most because they didn't.
> Why not just sort the list of requirements according to urgency?
This is a noble idea except that there is more than a dozen ways which "urgency" can be measured. Do you measure by its deadline, where the requirement is sourced, its dependencies etc.
it ended up as an agile project so this is pretty much what we did, these jobs ended up being classed as 'nice to haves' and the groundwork laid down for full implementation if the rest of the business ever got their ass in gear.
What a fool. Only doing what is necessary rather than spending hours and hours reinventing pointless wheels or introducing pointless abstractions is one of the key techniques that 10x programmers use.
There are counterpoints to many of his arguments, too. For example, using existing software is good, unless that software is a bad fit. You can end up with a Rube-Goldberg-esque monstrosity, held together by duct-tape that is impossible to use ("enter your back-end SQL query here in this tiny little text box") or impossible to maintain.
I completely agree. For each 'oh look I found a plugin/library that does that' you can end up with
+ something what you need-ish, PLUS crap you don't
+ a layer of glue code to your codebase that will be as hard or harder to maintain.
+ your famously fantastic imported code will have it's bugs, that will be hard to find (as it's not owned)
+ nobody will 'know/own' it, so any tweaks will be duct taped.
+ it will diverge upstream, will at some point your version become fallow, and you end up with 'code sclerosis': you can no longer extract the old and get a new, fresh version.
So yes, all that time and headache you will spend for your 'quick win' could have been spent solving the problem for YOUR use case by paying the price upfront and writing the code.
I've seen that so many times it's not even funny. There is also the manager's version of that, with the world famous "I found that library online, does JUST what we need and only costs $5k, and we even get SUPPORT!11!!"
I would never want to work for a company who's business model is shoehorning random libs together into a frankenstein just to quickly get that client out the door and a new client in.
Sure if you were rolling everything yourself. But you can still use pre-built solutions.
As a developer I use frameworks to aid in my building, like a construction worker uses premade hammers. But if a building needs a specific type of board, cutting our own wood is a viable option, or molding our own blocks.
The foundation is solid, but we build on top of it so our house is unique and to specifications, not just a cookie cutter run of the mill house that everyone else has.
The times I feel I’ve made most difference to our team’s effectiveness is when I find ways to not build things.
"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."
— Larry Wall, Programming Perl (1st edition), O'Reilly[1]
Reminds me of this quote by Kurt von Hammerstein, a German general of the Reichswehr.
I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief.
As a note, I don't think he's referring to simple dross, the way he uses the word laziness refers to economy of action.
Ironically, almost all Perl code I've dealt with contains large helpings of the last two in the form of layers of ever more complex NIH code as each new set of people work on the code.
I've hacked in stuff like that when it becomes apparent that the CPAN solution could not be made useful in a reasonable amount of time. I've only had this problem with the SOAP implementations, thus far. Except SOAP::Lite.
I may have missed this part in the article, but the "0.1x" moniker, as a reaction to the "10x" label... seems to miss the point.
The "10x" type folks I know are "10 times as productive" as others precisely because they know how to deal with some of those issues in the 0.1x list - push off new features, reduce amount of new tech introduced, drop old features, etc.
Knowing how to focus on the things that provide the most value in the least effort - but still move the project forward - that's where my understanding of the 10x label always was based. Maybe I'd had it wrong and people were always focused on "lines of code"?
Or maybe this was the point the OP was making anyway, but it went over my head. I know only a handful of places that have ever really looked at pure "output" (of code, for example) as the primary productivity measure.
>Maybe I'd had it wrong and people were always focused on "lines of code"?
No, the original studies talked about 10x productivity, not 10x lines of code. The more productive developers also produced fewer lines of code for similarly complex tasks, and it was easier to debug, to understand, and to modify. They also frequently would produce net-negative-lines-of-code on productive days.
Article is clickbait with a strawman premise, no question. I think it particularly attracts the clicks of 1x developers who like to think the 10x developers aren't anything special. There are certainly many more 1x developers.
The top-voted comment as I write this frames someone who recommends WordPress as a solid engineer. Enough said.
"The top-voted comment as I write this frames someone who recommends WordPress as a solid engineer. Enough said."
What's this mean? The top-voted comment describes a scenario in which WordPress does meet the business needs, and yet two others decide to go and write from-scratch code. Whereas the other one has time to actually solve the problems the business has.
If you're trying to be a WordPress snob, then you're missing the point entirely.
WordPress-as-a-service can meet business needs. But WordPress is an awful idea outside of that. Someone is needed full time to keep it and its plug-ins patched. I would laugh at just about anyone who suggested a self-hosted WordPress as a reasonable solution to anything.
There are other sites where you can get managed CMS hosting (wix.com, squarespace.com, even wpengine.com etc.) to build a CMS on.
To suggest that "WordPress" is a good solution at this point should get you laughed out of the room. wpengine.com is a reasonable solution. "WordPress", hosted on your own server, is a disaster waiting to happen.
I actually tried building something, not on WordPress, but Drupal, and as a result can't imagine recommending anything that's PHP-based being a good technical solution.
Call me a PHP snob then. It's so horrible to work with I can't imagine that other solutions can't be better.
So one, you completely missed the part about her suggesting a hosted solution, and two, you're being a snob about stuff for no other reason than to be a snob. I don't think anyone can take your assessments about this stuff seriously.
>So one, you completely missed the part about her suggesting a hosted solution
Hosted != wpengine.com, hosted can mean a managed site with CPanel installed.
> you're being a snob about stuff for no other reason than to be a snob
No, I avoid using or recommending technology that is insecure-by-design. That includes PHP and just about everything built on it.
>I don't think anyone can take your assessments about this stuff seriously.
Considering how much I make consulting about "this stuff," I have no worry about how seriously I'm taken. Sorry if I've offended a technology you like, but it's really pretty awful.
Yeah, agreed on who this may appeal to. Personally, I don't think I'm necessarily one of those "10x" devs, but... then I work around many other folks on different projects, and I see the extremely wide range of skills and productivity levels. The wider range I see the harder it is to judge. (and... judging doesn't normally net me anything except feeling better or usually much worse about myself!)
Great clickbait title but I do agree with the point of the article. I know "excellent" programmers that their first reaction is to crank out as much code as possible. My reaction is always: let's find a plugin that does this, I am too lazy to write it from scratch. Most of the time it gets the job done faster with fewer bugs.
As there is “more than needed” there is “less than needed”, thus adding, not adding, removing or not removing features should be given equal consideration.
What I strive for, is to be a “textbook” engineer. I'd like my work to be as a textbook example, something a newcomer could use to learn the technology I am working on or that a new maintainer would have no trouble understand what I did.
If you become reasonably good at finding existing solutions to the problem at hand, and you save 90% of yours and company's time, then it frees you (and the business, and consequently society at large) to pursue any other new problems that haven't yet been solved. Software is a means, not an end in itself.
To me, solving known problems and doing the same thing over and over, just changing the tools, is akin to digging holes and covering them again. And what is the fun in that?
I see that line of thinking a lot in the iOS dev community. Lot of people publish components, and lots of people just stick together published components.
Of course, each of those components is a dependency. It's not unusual to see an app use a dozen third party frameworks.
Every time that an OS upgrade comes along, you need to hope that non of the dozen frameworks you are using breaks, and if one does break, hope that it is still maintained. If not, you will have to get familiar with an unknown codebase at the most inopportune moment...
Also, usually existing components do only 75% of what you need, and lots of stuff you don't.
If you write everything yourself, you will never depend on other people to maintain code that you use, and you wont include lots of bloat that you don't need.
What you are talking about is more about the eternal discussion of "buy vs build", but this is not what I am talking about. It seems like you are just looking for a rationalization of NIH. There is a lot of middle ground between "let's build something that depends on a dozen different frameworks" and "let's build everything ourselves".
What I am talking about that if you have a good solution to the problem that we (as software engineers) are supposed to solve, then by all means take that solution instead of focusing on re-implementing it. "The exercise is left as an exercise to the reader" is fun and all when we are still in college, but when we start talking about the progress of your career, the industry and society in general, please don't waste your precious brain cycles working on something that has already been done.
Why not? Sometimes the stuff in the standard toolkit is crap.
I mainly work on the Mac, and the classes provided with AppKit vary greatly in quality. Most parts work really well, but others are really buggy. For example, after years of struggling with IKImageBrowser, I just wrote my own grid view. It would have saved me a lot of trouble if I'd have done that in the first place.
For a limited few things, maybe. But the vast majority of things don't need that. I'm dealing right now with someone who wrote their own autocomplete text view, which doesn't work properly now that I've fixed their mess with auto layout.
I'll have to do that soon as well... I get lots of requests for auto-complete in my app, but it looks like Apple's built-in autocomplete is unfortunately not flexible enough for my needs (eg. it has it's own ideas what a word is that aren't compatible with SQL)
If you call yourself an engineer, then the tenants of this article should be seared into your neurons. When enumerating possible solutions to a problem, one of them is always "Do Nothing". Find out a way to eliminate the problem before attempting solutions to the problem.
A lot of this blog post assumes that developers have a voice at the table. In my experience at smaller software companies/startups the model can best be described as WDD, Whim Driven Development. If someone has a whim, the developer provides the way.
This happens a lot in companies where the CEO drives product decisions. There's nobody to push back on ideas, so you end up with developers implementing every half-baked idea that comes out of one person's mouth.
In grownup companies, where you have a product manager and that person has a boss and that person has a boss, the product manager has to justify his decisions to people and has to get feedback, and perhaps has to convince people before he/she's let loose on the engineers, so you get a lot less time wastage on people's whims.
In really big-boy companies, engineering and QA has a stake and can push back on harebrained ideas too! The best places have it where there's a product manager, a project manager, an engineering lead, and a QA lead, and they all are empowered to get into a room and have to agree on whether what we're doing provides business value, whether it's feasible, and if can be done by the deadline.
Of course, in any case if you've got senior leadership who engage in seagull management, all bets are off.
I think a core problem that the author identifies is that it's very easy to find markers of programming ability, and those are the things we've optimized for, while its much more difficult and time consuming to determine if some one has good judgement. You can be an amazing engineer, but being an ok engineer with good judgment ("do we REALLY need to do this?") generates more value.
About a month ago a friend asked for help with his arduino project. He was having difficulty figuring out obstacle navigation. Getting the compass to work combined with the math strategy had him puzzled.
My suggestion, based on my experience as pilot, removed the compass and the math calculations. We both had a great time working with the implications of this new approach.
Offering a fresh perspective from a different domain was very valuable. Reducing the complexity of the solution to his problem made sense to me, felt good, and delivered an easier to maintain "product".
My friend is about 70 yo and has been developing software professionally since his early 20's. His resume is filled with pretty cool projects with notable peers in tech over those 5-ish decades. There was something very affirming about being able to help such an accomplished engineer in this manner. I learned a lot in that hour.
This is absolutely ridiculous. Obviously a 10x engineer is not the one who churns out lines of code, but instead the one who produces results without a lot of code.
> I have observed that some people are able to get 10 times more done than me.
There are many poor definitions of "getting things done". Why waste time using them?
I think there is a ton of subtly and trade-offs around choosing to do vs not do something. Of course not doing something is better in the abstract, but that isn't always an option. I'd be much more interested to read something on how to best make these kinds of trade-offs.
I have only been able to group developers into the following categories:
- not competent
- competent
- competent + problem focused
I would never hire non-compitent developers. They suck. They make terrible decisions and code. They are many.
I would be careful hiring competent developers. In fact a competent developer is usually a junior developer who needs proper mentoring. I would push hard for getting that developer above competent.
The last type of developer is the golden goose. They can code, but they are focused on solving problems NOT writing code. They focus on what problems need solving, can they be solved later, what is the price of solving such problems. All that while being competent at making code.
So thinking of someone as 10x or 0.1x is an error IMO.
He has a point when you are talking about a large company. It is hard to extract the full potential of most 10x engineers in this setting. Difficult, but not impossible. Put those people in R&D or in some leaner group creating the next thing, not the current one. If what they make doesn't have a net positive impact then throw it away.
In a small startup the 10x'ers are critical. When you don't have a product sitting around and deciding what to build is probably worse than giving up. MVP it over and over until you have something. 0.1x'ers please don't apply.
Have been on board with this idea for some time, but, that said, here's some criticism of the specifics:
> Is there existing software that could be used instead?
Agree, up to a point. Very few OTS/SAAS solutions are practical financially and customized, and if they are (as in a company that adds those crazy features you want to their SAAS app)- watch out! Those companies products will end up hitting a wall eventually because they will have coded themselves into a corner. Note: this actually because the company you are using didn't use the 0.1x engineer philosophy.
> Let’s not build/deploy that development tool.
Maybe. But it depends. How often is human error affecting your process in a very time-consuming way? You wouldn't say CI is a bad thing would you? What about using an IDE when you've got developers or a development language that best lends itself to an IDE? You would buy that IDE right (unless you're really, really cash-strapped- compare it to the cost of a few days of your developer's time)?
> Let’s not adopt this new technology.
Maybe. How about instead- let's adopt what are solid winners technology-wise that will help us attract new talent and develop features more quickly. And when we do that, we first do in small pieces that are independent to prove it out, then eventually we commit to using it as much as it makes sense so that we don't end up with 3 tech stacks to maintain in ten years.
> Can we achieve the same thing with a technology that the team is already using and familiar with? “The best tool for the job” is a very dangerous phrase.
Sure, mostly. But don't get a shitty open-source IDE instead of paying $600 for a good one, or force developers that use UI tools to use vim because you're too darn cheap either, even if it would do the job. On the other hand, I agree- don't just buy things. Really let your dev teams hash it out and choose appropriate tools- don't dictate anything without getting feedback and adequate buy-in when it comes to tools.
> Let’s not automate this.
Again- what about CI and scripts that can help make developers work consistently, more productively, more efficiently overall, and with fewer errors?
Sure- if you are a one-man team, you might not need continuous deployment yet, but please don't sit there and have devs pulling oars in your wooden sea vessel as the hovercrafts speed past you in the race.
I think the correct definition of a 10x developer includes what you're describing as a 0.1x engineer. It's not that they are simply more prolific, but that they are more prolific, impactful, and efficient.
The best company in the world is one where it has 0 cost, requires 0 effort, and generates billions of dollars in revenue. It doesn't exist, but that's what everyone should strive for.
This whole business of the universe spawning humanity to generate billions of revenue required no effort or cost on its part. All the effort was spent by the life forms it allowed to happen.
What you said reminded me that time I rejected a $10k contract and told my wedding photographer client to signup for a $40 per month product instead, and saved them $9520. I didn't see any of that money, however.
I am profoundly surprised that someone would characterize this text as being even remotely satirical. What gives you this impression? What industry and perspective do you have on the points made?
Are you serious? The whole article seems like a parody - (intentionally?) not understanding what 10x means vs unnecessary bloat and then proceeding on...
I've often joked that 10x programmers were the ones who used multiple cursors. Seriously though, I would argue that writing a lot of code, even if it's not all going to be the next cash-cow for your company, is good for the hackers soul. It also adds intellectual property and infrastructure to your company.
Adding infrastructure for its own sake is a terrible idea. Someone is going to have to care for that infrastructure, its going to be another thing to keep on your mental model of how everything fits together, and in many cases it's going to be another thing that needs changing when the requirements change later.
Obviously just adding more moving pieces for no benefit is a waste of time. However there are many areas that can be improved or even entirely automated with software.
My bigger point was that writing code is not "a bad thing that should be avoided" because I think it helps programmers understand the problem and can add more value than debt. Even if it may change at some unknown point in the future.
Click-bait title, maybe a better title is 'how to be more effective'?
All of the tasks mentioned are valuable assets to the business. Operational support, developing new features, understanding dependencies, building tools, communication - they're all part of the job man.
53 upvotes and these goober comments reminds me that HN is mostly <21 years old; time to move on.
I'll move on to an HN with an older demo, or no HN at all. OP posted a click-bait trash article and people are upvoting; it just makes me wonder if this site has any legitimately talented programmers at all or if they're busy actually doing things in the real world; my guess is the ladder and that real devs would only post a show hn.
Young programmers I guess. Don't mean to hate, but I used to enjoy HN.
Got anything about the article's content you want to complain about or is it just the choice of words?
Just because you got it all down does not mean that the very same topics won't be discussed again and again by the next generation. And you know why? Because YOU (and me) apparently failed to provide the next generation with a "programming bible" that answers all questions once and for all.
Like:
Customer needs a CMS.
Clyde looks at the requirements for the CMS. He sets off to write hundreds of thousands of lines of code by himself, complete with CI, continuous deployment, tests and documentation because he is a very good developer. Through the course of the project he leverages his years of experience and background in CS and engineering to make a well-factored body of software that will be maintainable for years. He did this in only a couple months.
Bob looks at the requirements for the CMS. He thinks "I know, I will use a good application framework and an ORM". Bob writes a couple thousand lines of code with all the tests and stuff that Clyde had. Bob's tests and app code, however, are more focused on the customer's needs, making in maintainable for anyone who can read the documentation of the software he's chosen to use. It takes him a couple weeks.
Alice looks at the requirements for the CMS. She realizes the customer will do just fine with Wordpress with a couple of tweaks. She sets up a hosted blog so nobody has to actually maintain it. She has better shit to do with her time.
Alice did the least work but that doesn't make her less productive. You're solving problems. If you do work to solve those problems, fine, but having more "output" doesn't make you go from a 1x to a 30x engineer.