199

The advantages are mostly the same as for groups of developers. By using an always release-ready master branch, and feature branches for developing new features, you can always release off the master. Find an important bug while working on a feature? Switch branch, fix, release, switch back and continue developing. Or maybe this is a hobby project and you ...


148

The later you test, the more it costs to write tests. The longer a bug lives, the more expensive it is to fix. The law of diminishing returns ensures you can test yourself into oblivion trying to ensure there are no bugs. Buddha taught the wisdom of the middle path. Tests are good. There is such a thing as too much of a good thing. The key is being ...


112

I agree with the rest of the answers but to answer the what is the time difference question directly. Roy Osherove in his book The Art of Unit Testing, Second Edition page 200 did a case study of implementing similarly sized projects with similar teams (skill wise) for two different clients where one team did testing while the other one did not. His ...


92

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 ...


63

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 ...


57

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 ...


53

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.


52

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.


43

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 ...


42

Long running development Branching for a single person team would be useful for a long-running development feature that otherwise does not fit into your release cycle. You can take a branch for your multi-month spanning change and still be able to push whatever day-to-day bug fixes or changes from your main branch at regular intervals. This has the ...


36

The goal of Agile is to... minimize all feedback loops as much as possible minimize project overhead in terms of documents/forms produced and replace it with much higher bandwidth medium, which is real-time (preferably face-to-face) communications among team members. If you do more research about agile, a lot of it will talk about teams and the interaction ...


35

Yes. You never know when more people might be brought on to the project. Also, repos allow you to rollback when you accidentally add something that doesn't work. You could use git for version control on your own machine without the need for a centralized repo. However, as long as you're using git, you might as well set up a repo on on GitHub. It only ...


33

Advice: Don't be afraid of learning new things - you made a good First Step in acknowledging that you could do better and then made the effort to learn how you could do better. Yes, it takes more time up front, but the payoff is usually worth it in the long run. Now that you know CodeIgniter, you can use it for the next future project(s). You can put it on ...


30

There is only one study I know of which studied this in a "real-world setting": Realizing quality improvement through test driven development: results and experiences of four industrial teams. It is expensive to do this in a sensible way, since it basically means you need to develop the same software twice (or ideally even more often) with similar teams, and ...


29

I've developed several totally different persons in my head. One of them is not even a programmer! We're chatting, discussing latest news and reviewing each other's code. I strongly recommend my approach. ps He is not kidding.


24

You are missing a lot. I'm solo too, in a way. I commit every time a make a significant change, or before I start a significant one so I can go back if I screw things up, and every now and then even if I'm not making anything big. Not everyday really, but close. Sometimes a few times a day. What I get is that I can go back anytime I want. Which is a lot. ...


24

Done well, developing with unit tests can be faster even without considering the benefits of extras bugs being caught. The fact is, I'm not a good enough coder to simply have my code work as soon as it compiles. When I write/modify code, I have to run the code to make sure it does what I thought it does. At one project, this tended to end up looking like: ...


22

I agree whit jk-s opinion that single-person review is not as efficient as 2 person review. however you can try to make the best of it: short term review (shortly after the code was produced) I am using git as a local repository. Whenever I have finished a feature or fixed a bug I transfer the changes to the repository. Before i check in I compare what I ...


22

While it's entirely reasonable and possible to use git locally, it's better to have backup. You can arbitrarily push repos to basically anywhere. Github just happens to be easy hosting and collaboration. There are other options such as using Google Drive or Dropbox if you want remote storage.


21

What you are going through sounds quite normal to me. This is how we work on our craft and get better and better at what we do.


20

Do you honestly believe that the overhead of typing around 40 to 80 characters in plain english is significant overhead for a commit, or are you looking for an excuse to be lazy? Pehaps you problem is expressing in plain english why you made the change, in which case, you may need to the review the purpose of the change, even to the point of asking ...


20

Despite there being a lot of answers already, they are somewhat repetitive and I would like to take a different tack. Unit tests are valuable, if and only if, they increase business value. Testing for testing's sake (trivial or tautological tests), or to hit some arbitrary metric (like code coverage), is cargo-cult programming. Tests are costly, not only in ...


19

Actually, there is little reason NOT to use a code repository. Just the fact that I can easily roll back to any prior version has covered my rear end so many times when I accidentally introduced regression bugs - despite my automated tests. If you need a recommendation - try Mercurial. It's really simple, yet very powerful. I would avoid Git because of its ...


19

As a lone developer, what can/should I do to make sure I am learning, There are books you can read. There are user-groups/meetups where you can talk with other developers. There is a code review site here where you can post code (that isn't vital/identifyable to your company) to get feedback. These are all fine, but no substitute for good practice. In ...


18

You should commit often. You should certainly commit after reaching some logical milestone. If that takes longer than a day, you should at least commit at the end of your work day, or better yet, break up your work into smaller chunks. There are many reasons for doing that. For example, what if your computer crashes? It is much better to lose only a day'...


18

First, set your code aside for as long as practical. Work on something else, some other piece of code. Even after a day, you will be amazed at what you will find. Second, document your code. Many programmers hate to document their code, but make yourself sit down and write out documentation, how to use the code and how it works. By looking at your code in a ...


17

There's no right answer to this question because it depends on each person. If you use an iPad to do all your dev work and your clients are happy with you, you have no reason to change at all. If, however, I were in your position, I would strongly enforce the following: A version control system - While you may think an image-based development system does ...


16

Version control is an absolute must for any programmer even a lone one. It means you can recover simply and quickly from deleted files and complex changes that are just wrong. Basically it saves you from the stupid shit you do when you go to work hung over.


16

If you are working solo. Here are the advices: Do as little low-level work as possible. Use as much library and tools as you possibly can including things you think you can easily code (don't do it, just use the library). Take the top-down approach. Only code things that you really need. When you see a problem in abstract term, search on google and use ...


16

I use it for critical website maintenance. I'm the sole developer yet I have a master, develop and issue branches. My work process for site setup looks like this: Make workable master branch. Do initial commit. Checkout develop branch. Don't do anything, develop functions as a test buffer for merging into master. Checkout issue branch. Code your issue, ...


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