4 ms·

Wow, I'm lucky to get 8 hours on a new code base before I have to ship a bugfix. << spotted your problem. If you're constantly working in completely unfamiliar

Wow, I'm lucky to get 8 hours on a new code base before I have to ship a bugfix. << spotted your problem. If you're constantly working in completely unfamiliar code with at best an 8 hour lead time to get a fix in, you're being setup for failure. Yeah, sometimes you have to just get a fix fast, but spending your whole life coding like that is going to burn you out. I only have my own anecdotal evidence to go by, but I'm inclined to think your experience is not the only way.

gizmo686 12y ago
Most teams I have worked with deliberatly introduced new members to their code base by: A) Making sure they can compile it, and showing them where the various locations for documentation are. B) Giving them simple bugs to work on while they get familiar with the codebase. 8 hours is more than enough time for a competent developer to fix many simple bugs. You also have situations where the nature of the problem dictates that you fairly often need to make changes in unfamiliar code-bases. For example, at my previous job I was developing an Android fork. Android has a fair amount of its own code, but also includes a large number of external projects. It was a fairly common occurrence where I would have to fix a bug in one of those projects that I have never seen before (and will likely never see again).
shadowmint 12y ago
The point is, if you need months to become familiar with a code base, something is seriously wrong. These 'here is some generic pointless advice; got some useful advice? Leave it in the comments!' posts are social media posturing and lazy writing. Certainly not everyone dives into different code bases every day / every week; but everyone does it sooner or later; and being immediately productive is hard. This article could have been an interesting collection of tips on how to do that... but the author couldn't be bothered researching the subject.

gizmo686 12y ago

Most teams I have worked with deliberatly introduced new members to their code base by: A) Making sure they can compile it, and showing them where the various locations for documentation are. B) Giving them simple bugs to work on while they get familiar with the codebase. 8 hours is more than enough time for a competent developer to fix many simple bugs. You also have situations where the nature of the problem dictates that you fairly often need to make changes in unfamiliar code-bases. For example, at my previous job I was developing an Android fork. Android has a fair amount of its own code, but also includes a large number of external projects. It was a fairly common occurrence where I would have to fix a bug in one of those projects that I have never seen before (and will likely never see again).

shadowmint 12y ago

The point is, if you need months to become familiar with a code base, something is seriously wrong. These 'here is some generic pointless advice; got some useful advice? Leave it in the comments!' posts are social media posturing and lazy writing. Certainly not everyone dives into different code bases every day / every week; but everyone does it sooner or later; and being immediately productive is hard. This article could have been an interesting collection of tips on how to do that... but the author couldn't be bothered researching the subject.