Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

hirvox: Sep 8, 2009

And do the remaining 5% have the inline documention out of sync with the code?

# ¿ Feb 7, 2016 16:51

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 07:19

hirvox: Sep 8, 2009

Illegal Move posted:

How many of you have to log your time on JIRA or something similar? Where I work, everybody is expected to log all working hours on the tasks they work on, and I'm wondering how common it is.

We have custom timesheet web application which is complex enough that filling out a timesheet usually warrants a separate entry on it. Work is logged at 30-minute precision for a specific task on a specific project with a specific modifier (overtime, being on standby etc). Vacations and flextime also have their separate entries. Time entry comments can show up on customers' invoices and data from the application gets sent directly into payroll, so middle management routinely sends reminders to fill them out before specific deadlines (usually end of the month).

Illegal Move posted:

I feel like nobody at my office actually honestly works for 8 hours every day, but if you don't log all the hours, you get angry e-mails from management. I definitely have some days that are less productive than others, so sometimes I end up logging 2 hours on a task that really probably only should have taken 30 minutes. I'm starting to feel really guilty about this, and I keep thinking that somebody will question me about it and I'll get fired, but in reality, my team seems to be really happy with my work. Am I an rear end in a top hat for sometimes stretching the time I log?

As always, it depends. Some project managers stress about everything, especially if the contract was a result of very tense negotiations with the client. But in general, people understand that everyone has good days and bad days, and will pad cost/time estimates accordingly. My personal issue is that either my personal estimates don't include that leeway or aren't directly applicable to other people. So when I err on those estimates to the side of caution, there can be pushback from sales who want to present as low estimates as possible to the customer. And once the project goes over those trimmed estimates, they're off the hook and already working on other sales cases.

# ¿ Mar 7, 2016 09:36

hirvox: Sep 8, 2009

Bruegels Fuckbooks posted:

This is sadly rhetorical, but why is this a technology problem? Why not roll back the changesets of people who do this and fire people who don't look at the things they check in? Nope, clearly the answer is branches and unit test guidelines with code coverage percent thresholds, instead of just not hiring morons.

Technology bandaids are better than nothing when senior developers have been reassigned according to the Peter principle and there's nobody left in the project to care about things the customer didn't explicitly ask for. The non-technical project manager and the junior developers left can still ignore CI test results until the project goes insolvent due to technical debt, but at least we get a timeline on how it happened. In theory, that could be helpful in making the next project less of a disaster.

# ¿ Jul 21, 2016 14:12

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.