Hacker News Reader

Comment by librish | Hacker News Reader

I think that assumes that you have reasonably self-motivating employees and work that is often interesting which definitely isn't always the case.

How do you suggest a non-technical manager tells slacking apart from when things just take unexpectedly longer?

View on HN

There are hard metrics, with time you see who fixes bugs and codes new stuff. For those who do less, you can still measure their engagement - how many questions and ideas they have, how they interact with their mentors, what are they motivated to do next… After some times, a pattern is clearly identifiable. And if someone slacks and still bring results, then what is to worry about? What’s sure if that people output varies, so don’t jump to conclusions too early (which goes back to my statement “after some time”…). Someone might just be tired or overworked. Which goes to the last point - for the people I know, they all seem to work more from home, not less. I think when people go back to the office and the happy hour and the commute, there’s going to be a fun drop in productivity.

A non-technical manager who can somehow do his tech job unburdened by having to understand technology to me sounds just like a non-administrative programmer who can somehow do his tech job unburdened by any administrative tasks such as issue tracking or planning.

How does that even work? How can one be 'non-technical' when they are managing people who produce technical output? Is it not key to managing this situation that one understands what is being done to at least some degree? And if one understands to some degree then one is not 'non-technical' I would say. If understanding is lacking; it can be learned.

It's not like it's magic!

Things don't take unexpectedly longer all the time. No, you can not make this judgement based on a single week, or even a single month. That's true whether the employee is remote or not.

I agree completely and that's my point. Evaluation is hard.

Separately from that, many people believe having people be in office leads to a higher chance of them doing work because the alternatives are much less enticing.

Yes. Evaluation is hard. That has never been at dispute. So... your point is pointless?

Things take as long as they take. Certainly, they will take longer if a “non technical manager” is cracking the whip on the team.

Hire good people, managers included. Keep trust high. Keep motivation high and keep autonomy high and I assure you software will get produced at a high quality.

Software development is a high leverage creative field. You want to maximize for developer flow, creativity and comfort.

Not everyone can afford or attract top level developers. Saying Keep motivation high and keep autonomy high and I assure you software will get produced at a high quality. is handwaving some extremely hard problems, especially if you're not working on an exciting problem and can't afford $200K salaries.

You didn't really answer the question. Say I'm a non-technical manager and I suspect one of my employees is slacking off, they just respond with "oh, the load router was misconfigured, luckily I caught it in time. I'll need to hot patch it, it will probably take another 2 weeks" what do I do?

If you can’t afford to pay for good developers, then you shouldn’t expect good software to be written quickly. That’s something only good developers can accomplish.

I think what you want is not possible. More process, monitoring… is only going to slow down your development.

I also think if a developer manager is going to be non-technical that they should be able to demonstrate extraordinary developer relation skills. Otherwise, what are you paying them for?

If you require good developers and managers with "extraordinary developer relation skills", and do manage to hire them out of wherever they worked before and fire all that don't satisfy that requirement, where do all the average developers and average managers work? Picking out only the best people is something that a particular company can choose to do, but it can't be a recommendation for the whole industry - what do we do with the other half of the tech workforce? We need reasonable processes that work somewhat well for most developers and most managers.

I would argue that software is too complex to be created by non-experts. This is why so much of the software ever created is garbage. There is no magic wand or process that will ever turn an average team into a unit that can produce great software.

The real answer of course is to pay more to hire better developers. You may even need to pay “hazard pay” if your software is boring enough.

From the perspective of the whole industry there's no such thing as "hire better developers" - if one company does that, then all it means that the "better developer" moves from company A to company B, and an "average developer" moves from company B to company A. It's an almost-zero-sum game - it's an appropriate mechanism to assign better(more expensive) developers to more important jobs and average or weaker developers to less important jobs, but it doesn't influence (in the short term) the total quantity of "better developers" available, that's achieved only by education and training (and immigration, and overseas outsourcing). "Hazard pay" means that you attract a developer to work on your boring software, but they quit working on someone else's boring software. It's not satisfactory to answer questions of "how should developers work" and "how should developers be managed" just with respect to top developers working in top places, they need to be answered with respect to median developers working on median tasks.

Your answer, including "The real answer of course is to pay more to hire better developers" and "software is too complex to be created by non-experts" is essentially saying that only a portion of the current developers should be writing code at all. Okay, so let's assume all the companies hire only "better developers" and everyone else gets pushed out of the industry - but there's not enough developers as is, so what do we do with half as many developers? Writing half as much software is not really an option.

I think we continue doing what we always do: write mountains of terrible code. My argument is that it would be less terrible if you at least put yourself in the mindset of good development, and to me that means not obsessing over “catching someone slacking off”.

I also will believe we have a real developer shortage when dev pay and exec pay are more closely aligned. As it is, I see a lot of room to pull from exec salaries to pay for devs (which would be required if there was a shortage).

I think you have a very idealized picture of the software industry. There are absolutely cases where more process helps keep things on track and increase overall productivity.

Reply on news.ycombinator.com