What kind of things can you learn from a guy who only hacks existing code?

Question

At my previous job I was the lead programmer and I worked with this guy who was a self-admitted hacker. We respected each other and had a great relationship. The company was much better off because we blended our talents.

I would tend to look for an elegant, graceful solution that we could add to our code library. He would tend to find, tweak, and fit some strange piece of code into a solution.

One of the most valuable lessons I learned from him was you don't always have to build the solution from scratch, there's a ton of code out there you can borrow from.

What kind of things have you learned from a hacker?

Edit - Added My Definition of Hacker
By hacker I mean someone who for the most part, cannot create something from scratch. However they are very good at morphing code that others have written.

Answer 1

Do what works - improve if necessary

Based on the way you worked your question, here's what I'm assuming you mean by "hacker": the pragmatic type who doesn't spend too much effort too soon but knows what tradeoffs are being made and can make something more elegant if necessary. (As opposed to someone who's blindly copying and pasting and doesn't know why the code sucks.)

That approach is really the foundation of agile development. And I've seen a great example of that, which has helped me tremendously.

I watched my good friend, who is an excellent developer, create a product in a brand new niche which he guessed was about to explode in popularity. He built his product quick and dirty to grab market share. His mantra was "do the simplest thing that works," and initially, it didn't work that great. But it was better than nothing, which was his competition at the time, and hour by hour he was improving it, based not on his guesses but on actual user feedback.

I would have been paralyzed about launching his initial version because it wasn't awesome. But he wisely chose what was "good enough for now" and went with it. If the project had utterly failed to attract users, he wouldn't have wasted much effort.

As it turned out, it was very popular. He has invested hundreds of hours of effort, and has refactored several times in order to allow new features and make the code more maintainable. He has a solid architecture, and more important, a great product with TONS of users.

This is agile development, and it's what I learned from watching a "hacker" succeed. In a sense, it's the old lesson: "don't optimize prematurely." Whether for speed or for clean architecture, the time to optimize is when 1) you can see that you need to and 2) you've got real-world data to know what to fix. Until then, you're just guessing.

Answer 2

Understand the meaning of every line of existing code

If the code was written (and had evolved) in a certain way and had been in a production system for years, one must hold some respect for the code. Questions can be asked; the logic can be challenged; but don't assume the code is wrong just because it seems so.

When you do plan to rewrite the code, seek advice from the senior hackers first.

Answer 3

I'd be very surprised if someone who was genuinely good at maintaining and changing existing code couldn't code something from scratch.

As often as not it's harder and more work to understand someone else's code than it is to start over from scratch which is why developers reinvent the wheel so often. The issue with writing the really nice routine for the library is that the next guy probably won't bother working out what you've done (and spent all that time on) any more than you spent time understanding the last guy's code and the investment will be wasted.

Two things you can learn:

1) There are often very good reasons why code is the way it is. You may view it as bad or strange but there are normally reasons why it's been done that way - they may be bad reasons (that the project was on tight timescales and it was hacked) or good (that it's dealing with an edge case you're not aware of and didn't consider when you rewrote it).

2) The more you change the more you can break. Particularly in large projects you often find routines that use another piece of code that become dependent on it's errors or odd behaviour. Particularly in older systems where no automated tests exist change things you don't understand 100% at your peril.

Answer 4

I've learned plenty of things, namely from an aspect of security, and how unfortunate it is that it is often an after thought from an application.

Additionally he really pushed me to learn and understand the open source community, and how valuable it is. I suppose that goes along the same lines of not always needing to build an application from scratch. Sometimes lipstick on a pig is all that is really needed.