Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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.

share|improve this question

closed as primarily opinion-based by MichaelT, Bart van Ingen Schenau, Kilian Foth, GlenH7, gnat Aug 12 '14 at 2:45

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Wow, that's pretty much the exact opposite of the actual definition of "hacker". – HedgeMage Nov 8 '10 at 5:13
What you're describing isn't a hacker, but a wannabe or a larval stage neophyte. The definition of a "hacker" is quite the opposite: someone who can make the code dance. – greyfade Nov 8 '10 at 5:32
instead of hacker, I think you mean 'slacker' – Casey Nov 8 '10 at 7:06
Very bad definition of hacker, there. – user1249 Nov 8 '10 at 9:29
How about re-titling to "What kind of things can you learn from a guy that only hacks existing code?" (or something along those lines) – Peter Boughton Nov 8 '10 at 10:12

4 Answers 4

up vote 17 down vote accepted

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.

share|improve this answer
Great story thanks for sharing. By hacker I meant more along the lines of someone who can not create something from scratch, they only morf what someone else has done. – Michael Riley - AKA Gunny Nov 8 '10 at 4:14
+1 for inspirational story and good advice – Gary Rowe Nov 8 '10 at 13:23
Agile is not about writing crappy code that sort of works and then improve it. Agile means writing high quality, working software that does just the things you need right now (no more, no less) and then add/refactor new features as they come up. – Martin Wickman Nov 9 '10 at 9:51

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.

share|improve this answer
And understand not just what it's doing but why it is or isn't doing things. Many people have tried to rewrite "bad" code and come unstuck finding that there were reasons it was the way it was. – Jon Hopkins Nov 8 '10 at 17:13

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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.