Hacker News Reader

Comment by egorfine | Hacker News Reader

I'm a CTO and I have been programming for a couple decades.

I don't care as long as I have the results delivered. I cannot imagine myself doing just a single development project during the week. Sometimes you absolutely have to switch contexts and think of a completely different task, perhaps in a different language/framework. I actually encourage that in a similar way Google encouraged people to work on their personal projects back in the day.

Having said that, it must be clear and transparent to all parties.

View on HN

> as I have the results delivered

And how do you define the results ? What if the employee gradually slows downs working like one hour less per week every month, in a year they can go from 40 hours per week into 28 hours per week with normal work expectations.

And that wouldn't necessarily be a "bad employee trying to get more from you by doing less". For example, maybe your team performance is getting worse. Let's say you have a coworker that is sick and gets normal pay for less quality work, and another coworker that just got a baby and got less time for work. The teams got less focused on work gradually in time and the employee feels "entitled" to work less on you and do something else with his/her time

It boils down to working with people with inner motivation to deliver.

I guess my experience is more relevant to small and highly integrated teams.

Also bear in mind: results of software developers are not defined by hours spent coding.

> less focused on work gradually in time

This might happen. It's a leader's job to keep in touch with the team and watch out for morale.

Saying it's the manager's job to deal with that doesn't solve the issue of helping managers deal with that job. The question remains open.

I gave a specific example where a manager can't "Keep in touch" because the work was gradually slowed each month, in a way that the manager can't see that time spent declined, he can only think that it's the employee's normal productivity

Makes sense. But it's well-known that software delivery estimates have huge error bars.

I frankly would have limited insight if a skilled engineer reduced output by 30% in order to work a part-time job.

Ultimately, the challenge here is that managers and engineering leads just don't have a great ability to know how expensive a project should be, which is sort of bizarre given that for a lot of software the development costs are the primary costs!

I strongly believe that software development estimations are futile.

Right, but my point was that if you can't reliably estimate how long something will take, you can't estimate how long it ought to take, and, by extension, can't estimate if it's taking longer than it should.

So, as a leader, how do you know if someone is over or underperforming?

Unfortunately, there is no algorithmic solution to this. It's like porn: hard to define, but you know it when you see it.

some companies don’t even get you need 2 monitors and you want everyone to be aware?

Reply on news.ycombinator.com