Comment by jondubois | Hacker News Reader

Comment by jondubois | Hacker News Reader

Parent Full thread

I think calling a developer 'awful' is rarely accurate.

If that developer has only ever made two contributions to the project, then obviously that developer isn't in the right mindset to make useful contributions. I find that when I switch to part-time on a project, my performance degrades. Producing good code requires that you understand the existing code REALLY well (and that implies that you have to spend a lot of time just reading it) - If you don't understand the existing code really well, then you cannot produce good work.

One of the worst things I keep witnessing is managers rushing new employees into finishing tasks quickly - This is really bad because new employees don't understand enough about the code to be productive; when you rush them, you essentially force them to implement dirty hacks which will end up costing way more in the medium and long term.

Most managers don't like to pay engineers to lean/understand stuff - They want to pay for code that works. Engineers should be treated more like managers and less like office cattle.

I've seen so many horrible managers in this industry and they always get away with it by blaming the engineers.

> I've seen so many horrible managers in this industry and they always get away with it by blaming the engineers.

Same. Been there, seen that. Seen good managers, seen bad managers, seen place without managers.

I don't understand why there are managers in this industry.

A good manager minimizes the amount of time a developer has to spend on stuff that isn't developing.

In the right situations, a good manager can make a team of a few devs far more productive than if you added another dev in place of that manager.

Bad managers, of course, can be disastrous, though.

Most stuff isn't developing.

Designing, planning, architecturing, reviewing, developing, testing, delivering, maintaining, presenting...

That's all a developer's jobs. I don't think that they should be strictly limited to "that guy who's got a special job title" (architect, managers, lead, whatever).

The way I interpreted larrik's comment, he meant things like interfacing with other layers in the company, interfacing with other managers about the team's capacity for support, etc. Most of the things you mention I would include in "development". What you seem to call development I would specifically call implementation.

Although, it can be beneficial to have different people for a lot of the things you mention, especially as a project grows in size and scope. And you need at least two people if you include review; reviewing one's own work is far less effective. Same with testing. Plenty of great devs are not great or don't like presenting, etc.

If you do go the route of splitting responsibilities, you're going to be more efficient if you have someone coordinating their efforts, reducing the communication overhead for the whole team by being a central point of synchronization. That's one of the responsibilities of a good manager.

Your interpretation is indeed what I was aiming for.

In my book, the best managers should work for the team, not the other way around.

Be careful with this. It's usually a sign of a political double-talker. The manager hasn't forgotten who he works for, even if he wishes you would.

Well, it depends. I've been in healthy situations where this was true. One company in particular where this was mostly true from the very top down.

Of course, yes, there are plenty of situations where it is just double-talk.

The manager isn't a good politician if you don't believe his bullshit.

If the manager himself is a founder, former programmer, or otherwise both intimately familiar with and committed to the process that actually produces the outcome, he may understand the importance of the work and really be working to ensure his team has what it needs so they can do a good job for the company. He's still working for the company, but he appreciates and understands engineering, and since you're working together for common goals from a common understanding, your interests are aligned.

You can almost always expect people to consider their field of expertise the nexus of the company's lifeblood, the critical component that everything will die without. Everything else will be considered tertiary. In the case of most managers, their expertise is schmoozing, and that's going to be their primary focus. To the extent that good engineering jeopardizes schmoozing, you can and should expect the manager to strongly prefer schmoozes.

Why skip secondary and jump straight to tertiary?

I've worked with a lot of really good managers who understand the role their group plays without having to delude themselves into thinking their team or function is primary. I think that's something that's really important regardless of the industry.

The most enjoyable jobs I've had have been those where there was good, self-aware management. While bad management is obviously a horrible time all-around, I've also had very bad experiences in the so called flat, self-managed models. For those to work, the greater majority of the team need to actually be self-aware, good (at least self) managers.

I'm not talking about the group or the team. I'm talking about the contribution that each person considers their primary value-add to the company. Every worker will say of their own class of workers "this company would fall apart immediately without us", exposing at least an implied, though it's often explicit, belief that the class of contributions they are personally making are the most valuable.

The issue is not "My engineering group is most important". The issue, rather, is "My engineering group, and consequently the company, would cease to exist if I stopped performing my core competency".

In the case of managers, this core competency is schmoozing. Thus, when the engineering management must choose between engineers who advocate a better/safer/more effective engineering path and their bosses who advocate not that, they will choose to schmooze and give their bosses good news that generates tingly feelings rather than bad news that generates angry feelings.

This is where the manager puts his craft into play. The goal is to manipulate the engineering team into a set of compromises that will allow the manager to generate good feelings for the bosses. Because the manager is not an engineer himself, he doesn't understand the ramifications of these compromises and/or whether it's actually the correct and wise way to proceed. Yet, he will still feel that he has saved the company (and possibly his team's paycheck) for exercising his core competency: manipulating subordinates into taking uncomfortable shortcuts while keeping the bosses satisfied. Middle management is a massive distorter.

As someone with a fantastic manager: it's great. He handles the planning and resource allocation for projects and makes sure that I have everything I need to be able to develop, this includes making sure that any external dependencies (like people not on our team) do their stuff and that the team as a whole is maximizing our time.

Whenever for some reason something is blocking me that isn't directly code related, he's the best point of contact to get stuff moving again.

Any senior or lead could handle the planning and the resources.

We both agree that there is something to be done. I personally noticed that it doesn't have to be assigned to an full time manager position.

It really depends on the corporate structure. The unfortunate fact of the matter is that, at least in some dosage, middle management is a practical necessity. Many organizations implement far more than they need for the sake of empire building and ego stroking.

> We both agree that there is something to be done.

Right, and if there is enough of that to be done it makes more sense to hire someone to do it specifically, so that the senior/lead developer's time can be spent more effectively.

> I personally noticed that it doesn't have to be assigned to an full time manager position.

In my experience it's much more about the quality of the manager. Unless you're in a company of only 10 people or so there are almost always more things a good manager can find to help with.

On the other hand, even having every member of the dev team being swamped with management/coordination work is better than putting a bad manager over them.

In my case he's also a project manager for a couple projects (though none that I'm involved in).

Often, the team lead or senior dev is only aware of their own project, but not of the status of other projects and how they fit into the whole scheme for the company.

Management has a higher level view and often more experience to make the right decisions for the company, that a dev might not be able to make.

Reply on news.ycombinator.com