Heisenberg Developers (2014) • Hacker News Board

Re: Heisenberg Developers (2014)

#191

Post by mobiuscog » Fri, Feb 05, 2016, 10:55 AM UTC

gearoidoc wrote: post #156

mobiuscog wrote: post #84

Earlier quoted context omitted.

If businesses didn't make promises before they knew if they could keep them, the deadlines wouldn't be such a problem. If an employee agrees to a deadline, it's fine. If an employee is just told they have to complete a task within a deadline that they're weren't included in estimating, that's not the employee at fault.

Thats not what gyardley is saying though. He's talking about developers who refuse to estimate how long a chunk of work will take.

An interesting point on developers who refuse to estimate, is how often they are then asked "Why ?".

I'm definitely someone who has either refused to give, or given massively exaggerated estimates in the past, for various reasons, the main being "I don't know".

Think about this for a moment - why wouldn't an (experienced) engineer know how long something will take ?

The most likely answer (and in retrospect the only reason I ever did this) was that the project was far too large / complicated to visualise, and needed to be broken down.

By asking an engineer to break the task down into smaller tasks, until they can 'ballpark' estimate each part, is the best way to solve this problem. Maybe more design or investigation will be required to manage the breakdown.

Instead of writing off 'problem' engineers, try to work with them and find the common ground.

Re: Heisenberg Developers (2014)

#192

Post by bb88 » Fri, Feb 05, 2016, 7:38 PM UTC

vinceguidry wrote: post #182

humanrebar wrote: post #178

Earlier quoted context omitted.

> You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job. I agree with that. Don't need to discuss how sausage is made. OP was pointing out that there are circumstances where the sausage making is micromanaged, which puts a kink in this plan.

Wouldn't put a kink in mine. I'd just carry on as usual. When I write code, I don't release it until it's been cleaned and refactored to my satisfaction. If a micromanaging boss wants to know my progress, the answer is simple. It's not done. He wants to know why, I'll tell him. I'm not happy with X class and I'm cleaning up the methods and reorganizing it. Should only take another hour. If he starts getting 1984 on m…

Honestly, I love that attitude. Also, be prepared to be shown the door.

Re: Heisenberg Developers (2014)

#193

Post by bb88 » Fri, Feb 05, 2016, 8:03 PM UTC

vinceguidry wrote: post #116

bb88 wrote: post #74

Earlier quoted context omitted.

> Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests". That's the entire idea of technical debt. It's just like real debt, only that it's cost is development time. And it takes time to pay it down. The only difference is that it's not reported on a balance sheet, so management doesn't care about it.

It's their codebase, they paid for it. If they don't want to maintain it properly, then it's on them. It will just get more and more expensive to maintain until they replace it with newer technology. Developers fetishize their codebases and complain about unpaid technical debt, but not all the bad code I've run across I can push off to management making the wrong decisions. I've seen a lot of bad decisions made by th…

I agree with many of the points you make, I don't agree with your assignment of blame. Good developers can make bad decisions. It's just that it may not be seen for a year or two. In a SaaS platform it's hard to see around a corner a year from now.

The thing about technical debt, is that once you have accrued it, it doesn't really matter how it got there. You either accept it exists and carry the balance or fix it. And typically, it's the role of management to recognize this.