Ask HN: How does the 10x coder overcome configuration headaches?

It's funny how common wisdom in the software industry is "reuse, don't rebuild", but if you look at projects that are actually successful and developers that are highly regarded, they all have a massive case of NIH syndrome. Google and Microsoft both build all their own software. Mozilla completely reimplemented COM for Gecko. John Resig just got criticized recently because TestSwarm duplicates a lot of the functionality of Selenium Grid. Linus Torvalds wrote his own OS instead of hacking MINIX, and then wrote his own VCS rather than use Subversion or CVS. Chuck Moore wrote everything himself, down to the hardware, which he designed with CAD software he wrote himself in Forth, a language he wrote himself.

If you look at it by numbers, this makes perfect sense. The average library is, by definition, average, so a coder who is way above average can undoubtedly write something better given enough attention to the problem. Plus, many of these super-coders got their reputation by writing lots of code in the first place, which you don't do if you just reuse third-party libraries.

Unfortunately, everyone thinks they're above average, which is why we get such a profusion of libraries in the first place. ;-)

I am a 10x coder, although I prefer when people just refer to me as someone who gets stuff done.

The answer to your question is simple: Yes, we are faster because we overcome these challenges, because we are as much sysadmins as we are developers.

The secret sauce is to realize that the world does not end at the borders of your VM.

If you refuse to acknowledge that your webapp needs an operating system, a webserver, a cache and a database to operate and if you push the lowly "grunt-work" of setting these up to someone else then you'll never be a 10x developer. Because in that case you're depriving yourself of acquiring the magic systems knowledge that leads to all the little "ah, this could be easier"-moments.

However, the 1x coder ignores the problem, or declares it unsolvable. Inevitably, he waits for the 10x coder to fix it. The 10x rule holds.

10x coding is as much about willpower as it is about technical competence and experience.

One rule I use is that when I pick something up, I make sure that I can google help whenever I need it. If Joe-Bob's awesome language or widget set has only 47 people using it, and you have to put up with abuse on an IRC channel or buy 15 books just to get respect from the community -- forget it.

Wise choice of tools also means your cognitive load decreases. You simply don't have to remember so much crap anymore. Problem remembering how to attach events to an element in Javascript? Ten seconds with Google and you've got your answer. There's a certain tipping point that products reach. Be careful using stuff before acceptance grows to that point.

That's _platform-ish_ stuff. Tools, widgets, languages and such. For whatever you're actually doing, consider rolling your own stuff. Most times you only need a small subset of functionality, and if you're a good coder it's as easy to write it as use somebody else's. Plus, you understand what's going on. Many times I've used stuff with open source code only to spend hours plugging through their code trying to figure out what the heck they were trying to do. That hurts. Don't do that if you can help it. Sure it's great to modify OSS, but it's probably just as easy to spend that time learning more about the technical problem domain.

For instance, I'm playing around with the idea of writing another web app. I took a look at YUI -- I really like it. But at the end of the day, so far at least, it does a whole lot of stuff that I don't need, and payload size is important to me. So I'm just going to roll my own stuff. You're always weighing future hassle against productivity. Sometimes, like with learning functional programming or picking up COM or something, the rewards may be much greater than the hassle. But for most stuff, like version control, project planning, configuration, deployment, setup, etc -- you don't have the luxury of taking 3 days to figure some of these tools out. So don't.

Rewriting the same functions yourself in a better and more efficient way teaches you a lot, especially about 1) how to spot good libraries, and 2) when not to write it yourself.

If you look at the code of really effective hackers, the one thing they have in common is how small the code is compared to what it does. Look at web.py, or bret taylor's datastore built on top of mysql: http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Inexperienced troubleshooters often enter the work with pre-concieved notions of how the system works and hold on to them for too long. Always doubt your knowledge.

I think it usually takes 1-2 days with a system until you start to get our bearings. Before that, you are just collecting data, random tidbits of how the system works.

I second the recommendation to use recommended libraries, and I love github for the code network analysis. Back when I did a lot of java development there was often a java library available which solved the problem available on the internet even for a specialized problem, but more often than not it turned out to be a completely shit implementation that needed to be replaced. Of course there are good java libraries, the trick is to know someone you can trust who can recommend libraries.

OTOH for some rails tasks that can be resolved by just adding a plugin the quality of the code doesn't matter much, since it's just a few lines of code configuration. Still a good library is much better than a bad. I wish there was some kind of leaderboard, or official plugin list for rails, it can be very hard to judge plugins for a newbie.

Also, there is something that has to be said for compromise. Get libraries for the language you know best and you will more productive than if you used a high-performance library for a language you don't know. Start small, and worry about scaling or "going big" later.

Experience makes a huge difference - simply because you've seen this problem before, or at least seen this kind of problem before, or maybe you saw the solution to this problem a year ago when you were googling the solution to some other problem and tucked it away in a cavity in your brain.

With experience, you happen to know that there are certain kinds of many-to-many relationships Hibernate can't map in a legacy schema where the foreign key is a subset of a composite primary key. So when you encounter that on your next project you drop right down to SQL, to the wonder and bewilderment of your new colleagues whom you've just converted to an ORM tool because it "abstracts away all that sql stuff".

With experience, you know the kinds of ways certain systems go wrong, the kinds of solutions and workarounds to apply, and most importantly the kinds of things to google for when hunting for the solution.

Even scanning search results pages - to a novice they're homogeneous, but after some time you start ignoring whole classes of results. For example, you're trying to find what some annoying ActiveRecord exception is about, and you realise half of your search results are pointers to subversion log messages mirrored in a thousand places all over the internet. And they don't have the information you're looking for.

As some other commenters observed, you have to push and solve those problems that seem impossible, because the next time around, you'll find the answer a little faster. Keep up the head-banging. It eventually turns into supernatural powers. Just be careful with the wall.

Here are mistakes I see people make that I try to avoid: 1) Making decisions on technology before they have actually tried it. 2) Upgrading to the latest version of products too often. For every problem it fixes... 3) Fail to give developers system administrator access rights. Nothing worse than not being able to install stuff, but it happens all the time.

I've been using the same toolchain for a decade now. I don't have to futz with the configuration: I learned it 10 years ago.

There's a balance there, between keeping on top of technology and focusing on solving problems.

It's been interesting for me doing a little Ruby of late because coming from mostly C++ (with bits of Java and Perl) I find myself fighting with the interpreter a lot. It's not that C++ doesn't have its quirks, it's just that I've known them all for so long that I work around them intuitively.

After having built software in different languages for different targets on different systems a few times, you start recognizing patterns.

One of the strategies I use to become comfortable with new environments is to build a piece of software (usually a prototype) using only the core language, standard library and maybe one or two 'mature' pieces of third-party library code.

This takes a bit of time and I usually end up with a codebase that is a bit crufty (especially when I'm learning the language as I go). However, this usually gets me to the prototype stage with a lot of newly acquired knowledge about performance of the language, best-practices, etc. As well as a lot of testing code.

After that I'll start looking into third-party libraries and start factoring out my own code with third-party libs where appropriate.

For Java, for example, I've found that a lot of the language helper/util code I write can be replaced with code from org.apache.commons.

For interacting with crufty stuff like webservices in all their non-standard glory, I usually build a few classes in Ruby with breakpoints so I can interactively analyze and poke at them. Much, much faster than going through the 'change code'-save-recompile-run cycle with breakpoints in C# and Java.

When dealing with loads of XML config files, I'll quickly do a git init and also keep all the files open in vim buffers. (Vim and Emacs are excellent tools for working your way through XML junk). Then I'll put print (or equivalent) statements in the code so I can run the app from the command line and filter the output through grep or even some custom scripts that'll filter the output for me and provide some basic analysis or correlation points.

The list goes on and on.

You have to realize that apart from the code that operates solely within your codebase (and not even then), you are always dealing with third-party code. The OS, compiler, the VM, the windowing routines, the threading model, etc.

As you go on you have to learn techniques to handle this. And one of the first things you already seem to have learned is that you should never be quick to voluntarily add to the pile of third-party software you're already dealing with.

And that 10x programmer working opposite you who generates mod_rewrite configs like there's no tomorrow? Yeah, that person spent about 3 days getting to the bottom of that engine and testing the hell out of various configs a few years ago. There's not much of a short-cut for these kind of things.

* Not invented here syndrome: 10x coder may code small things himself that many times is faster then learning other stuff.

* Selection of the tools to use: it will use Ruby instead of Java, for example, and for a reason. In general he'll try to figure the fastest path to solve the problem so will try a lot less.