5 ms·
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 is
by jondubois 10y ago
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.
- user5994461 10y ago> 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.
- larrik 10y agoA 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.
- user5994461 10y agoMost 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).
- jdbernard 10y agoThe 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.
- larrik 10y agoYour interpretation is indeed what I was aiming for.
- clueless123 10y agoIn my book, the best managers should work for the team, not the other way around.
- cookiecaper 10y agoBe 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.
- jdbernard 10y agoWell, 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.
- cookiecaper 10y agoThe 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.
- lpr22 10y agoWhy 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.
- fuck_google 10y agoIf management would be replaced with motivation, developers would be even more productive.
- lagadu 10y agoAs 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.
- user5994461 10y agoAny 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.
- cookiecaper 10y agoIt 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.
- fuck_google 10y agoMany organizations spend far more resources on empire building and ego stroking than implementing stuff that they actually need. FTFY
- jdbernard 10y ago> 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.