logoalt Hacker News

sevenzeroyesterday at 12:46 PM8 repliesview on HN

Guess I must be doing something wrong to never have encountered this issue in my 5 years.


Replies

cscheidyesterday at 2:03 PM

I'm just going to answer this one candidly. Yes, you are doing something wrong. Immediately: the commit history is useful to understand the context in which a bug was introduced, because it's the best context to understand the _reason_ the mistake was maybe, which is a really good way to prevent regressions. But more generally: when an entire industry has arrived at an accepted practice, you the junior developer (sorry, 5 years is _nothing_: you need to be told this too) have a chance to pick up on it.

Have you heard "have you played guitar for 20 years, or have you played guitar 20 times for a year?" Time only helps with accumulating wisdom if you let it.

vlovich123yesterday at 1:59 PM

You can of course choose alternate strategies. It comes up a lot when doing low level systems programming because the bugs can be non-trivial to repro and root cause (particularly for C/C++ where you have segfaults and whatnot). So it’s cheaper and faster to try a bisect to find the regression introduction as an additional clue in the root cause analysis (eg ownership rules changed or there were changes that looked correct regarding threading but when you hyper focus on it you realize what the problem is). Or you’re working on a high performance codebase and there was a performance regression - it can be faster to bisect than it is to try to find the issue with profiling tools (I had this and seen issues where profiling tools would never have told you the issue).

klibertpyesterday at 1:51 PM

I would ignore it if I spotted it once. This is the second time, though, so I probably should point it out: 5 years is a very short time in terms of personal experience and development. While the whole industry moves very fast, it does so thanks to slow, grinding effort parallelized over hundreds of thousands of individuals. For an organization, 5 years is an era. For individuals, it's just 3-6 projects (+/- a few, depending on the context you work in).

TL;DR: "never have encountered in 5 years" is a meaningless data point.

My professional career can legally drink beer since a few years back, yet I'm still regularly hitting "first times" on various things in my day job; I'm also frequently mind-blown reading about others' experiences in domains I never touched. Don't make those "5 years" into a badge to hide behind; use it as a springboard to reach higher.

In this case, try to actively think of uses for the commit history. It's already there; there's an expectation (admittedly, to various degrees depending on context) that it will be maintained. Try to maximize the value you get out of it. Underutilizing a tool you have access to may not be that much of a problem on average, but in some specific circumstances can make a difference between being able to complete a task at all or not. You shouldn't rely on luck to never land in a situation like that: familiarizing yourself with as many potential uses for a tool as possible gives you a better chance of handling it more easily.

EDIT: formatting, last paragraph.

loegyesterday at 2:02 PM

As you get better at engineering and grow into a senior, you'll find this more valuable.

VBprogrammeryesterday at 2:47 PM

It depends on the size of the project (mostly in terms of number of active developers) and how close you are to the running code in production.

On a large project it's probably the first tool I reach for when we find something we have reason to believe was a recently introduced bug. Specifically annotating (git blame) the relevant code and scanning for what lines have been recently modified.

I've worked in startups where there were only 2 backend devs and a frontend guy. There it was almost completely irrelevant and I spent a couple of years at a large software shop, early in my career, where bugs in production code was mostly someone else's problem.

jeltzyesterday at 4:45 PM

Probably, because in my 20 year career I have encountered it plenty except back the first couple of years as a junior developer when I did not know my tools and did not know that I should do this.

ShinTakuyayesterday at 3:02 PM

I'm tempted to suggest you have encountered the issue but your team mates are shielding you from the consequences (with or without their knowledge).

show 1 reply
afavouryesterday at 12:51 PM

You do you. But in my twenty years I’ve leaned on it countless times.