Hot answers tagged


John Carmack The guy that wrote the engine for the Doom games, Wolfenstein, the Quake games, etc. Read Masters of Doom, it is a great history of what he and John Romero have done.


Steve Wozniak pretty much was apple's programming staff for the first bit.


Richard M. Stallman (RMS). While known recently for political rants about closed source software, in his day he was quite the programmer. He single handedly kept up with commercial lisp machine code for quite some time. Emacs and gcc are some of the things he created. There's a great description of him in the book in Hackers by Steven Levy.


Bill Joy - wrote vi as well as csh, rlogin, rsh, and rcp


John Resig, creator of the jQuery javascript framework.


First of all, make use of tools to check as much as you can. Tests (backed up with some reasonable code coverage) will give you some confidence of the correctness of the code. Static analysis tools can catch a lot of best practice things. There will always be issues that you need human eyes on to determine though and you will never do as good a job reviewing ...


Bram Cohen, at least his little project is now causing 50% of all internet traffic[citation needed].


Yukihiro Matsumoto did deliver a lot of Ruby all by himself. Ruby's popular now, and lots of people have contributed to it, but he did single-handedly start the ball rolling.


Oren Eini aka Ayende Rahien, author of Rhino Mocks and other great open source tools. His is some of the best and most elegant code around.


If you use decentralized source control (Mercurial or Git or Bazaar or whatever), you get advantages overs SVN/CVS that makes it easy, useful and powerful to use in cas you're indy : You commit locally : your project dir is your repo with FULL history. So you don't have to have a server, you commit directly in your repo, and you can have several repos in ...


Take a look into the Code Review Stack Exchange site. It is for sharing code from projects you are working on for peer review: Code Review Stack Exchange is a question and answer site for seeking peer review of your code. We're working together to improve the skills of programmers worldwide by taking working code and making it better. If you are ...


Jamie Zawinski (links to one of the most epic stories in the history of computer science)


_why has contributed some cool stuff to the Ruby community : Hpricot , HTML parser Shoes , GUI toolkit Camping , microframework ... and many more :)


I try to always. How many times do you look back and think, "Man what was I doing when I made this change." I do all the time. 30 seconds of writing a message can save you 20 minutes worth of work trying to remember.


Read this article for example, starting twowards the middle at about the place where it says, ... the privately held company Celera appeared on the verge of beating the combined scientific teams of the rest of the world to the goal of sequencing the human genome. Celera's approach was less rigorous but faster than the Human Genome Project's approach, and ...


By doing test-driven development By developing in small sprints By having a lot of contact with the customer I remember reading a thesis about Cowboy Development, that is essentialy Agile for solo developers, but I can't remember where I found it.


If you are enjoying your work and only missing knowledge sharing, consider joining an open source project instead of changing the job. Unless you already know the people you will be working with, you have no idea whether the grass will be greener on the other side.


Well here is one reason: If you suddenly realize something has been broken for the last few hundred commits (possible if you commit at every minor edit, less feasible if you, like me, commit only "stable" snapshots), you can more easily find where you've inserted the bug if you've written clear commit messages, rather than "bugfixes." (A colleague's favorite ...


Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future? Of course. There is a simple good practice that you can use even if you don't have a team right now: create a separated branch for development. The idea is that master branch will contain only released code versions or major ...

Only top voted, non community-wiki answers of a minimum length are eligible