Hacker News Reader

Yes, I was reading that blog and trying to hear the voice of the frustrated junior dev who is blamed for everybody else's poor communication, who is not being supported and who is used as a scapegoat for the company's wider problems (structure, feedback, planning). Someone who spends their days wondering where it went wrong, why no-one is willing to work with them and thinking about how fast can they get out of there.

This article reeks of bullying, passing the buck and misplaced egos, imo. The solution provided is focused on how to avoid hiring 'problem' employees, unfortunately nothing about how to cope with the situation once it has arisen. People can change after the hiring process due to personal reasons, death, divorce, all sorts of things. The author's company does not sound like a good place to work staffed with nice people.

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.

> let them go

Erm, that isn't how corporations work. First, team lead doesn't mean manager, and even then in some companies, first and second line have very little to say. HR needs to be involved, etc. Which creates more work. There are the people who simply don't care. Contractors on a gravy train or outsourced people. I've been there, there is nothing you can do in this case.

I think it's fair to say from your resume/LinkedIn that you have been shielded from such effects for most of your career. Consider that a blessing, but don't assume you always have so much control over your environment. A lot of us are more like mercenaries, making good money out of bad situations while we can.

That's a valid point of course, thanks for pointing this out! I assumed that the organization in which you work is at least partially functional and that management has an interest in ensuring good working conditions, which as you say is not always the case.

But even if you're not in a position to do hiring/firing decisions there is still a lot you can do to make it harder for other people to do bad work. One of the easiest things is to agree on a standard for your codebase with the other developers, and create a process through which you monitor this standard (e.g. through code reviews).

If that's not possible due to resistance from management or a dysfunctional organization, you should consider leaving that position as soon as possible as it is not a good environment to work in (and as the author says, luckily there are enough opportunities for good programmers these days). But again, the problem here would not be the single bad programmer, but the setup of the whole organization, which is unfortunately much harder to fix.

I agree. Funny story with the code review, we had that. But several devs kept submitting broken/bad code, so they could tell their manager "oh, I'm waiting on a code review". The loss of productivity due to other devs trying to do constructive code reviews was staggering.

One guy was asked to leave a project after he submitted 17 updates to the same commit, and all of them failed basic (and luckily automated) linting. Another contractor titled all his commit messages a single word: "update". I've even worked on a project where the build system was "maintained" by contractors - talk about a conflict of interest. You can imagine how transparent it was.

In the bad/broken code it again sounds like poor management - instituting the 'bums in seat' checklist of was present for a code review, versus the qualitative check of 'had done work that was worth reviewing'.

Sure, but any metric or process put in place is vulnerable to be gamed. In some way, I respect individuals who do this. Just don't bother my team.

But managers aren't intrinsically bad people, they just have different motivations. And they have their own problems caused by politics. Ideally devs would have tools to combat this problem directly. But life isn't always fair.

Of course there are developers who bring problems to projects.

However, many of the problems are organizational: I have seen some projects place sizeable incentives on any bug fixes (e.g., highly value number of such submissions / week), which encourages people to do quick fixes for simple things, not important ones and does not penalize for poor performing software and convoluted code. If one finds itself in this environment, IMO it is best to run away.

I wonder why such organizational behavior is very difficult to change -- I have seen, twice, smart people brought in to clean up a project stuck in this state. They were given freedom to run it the way they saw fit (upper management knew the project is failing) and both times they failed to change it.

> I wonder why such organizational behavior is very difficult to change -- I have seen, twice, smart people brought in to clean up a project stuck in this state. They were given freedom to run it the way they saw fit (upper management knew the project is failing) and both times they failed to change it.

It's a good question. I think it's often a hard sell, that the change, while more work in the short run is less effort in the long run. Why should I care? I'm still getting paid the same. Of course, that's a facile argument and easy to refute: professional development.

In my experience organisational behaviour has a root cause. You have to find that and understand it to change it, you can't just change the organisational behaviour but leave the root cause. To an outsider, the root cause probably isn't obvious. Heck, sometimes by the time you understand it yourself, you've been there so long you might as well move on. But often, it's also the devs who refuse to get political. Who understands the system better, and why should somebody else fix it? But then the obvious excuses happen. "Too busy", "Not my problem", "Nothing I can do". Devs start leaving the project or the company. Now, it's never going to get changed. Apathy is the worst symptom.

>I assumed that the organization in which you work is at least partially functional and that management has an interest in ensuring good working conditions, which as you say is not always the case.

I would say this is quite rarely the case. It's amazing how many companies are able to slog through with completely braindead personnel practices. It seems most places are either far too reluctant or far too quick to terminate employees.

I know of a company that refused to fire someone who not only destroyed a production database but, on a separate occasion, accidentally facilitated an ongoing leak of the source code of all web applications (which was only discovered when it was revealed to the CEO by a script kiddie with a guilty conscience). Because this guy is well-connected, he lives to imperil the company another day (usually in slightly less dramatic ways).

I also know of a company that fires otherwise good programmers for not being at their desks by 9:05 a few times per year. Those people are terrible.

It seems that a company that is actually reasonable about its personnel practices is very rare indeed.

>If that's not possible due to resistance from management or a dysfunctional organization, you should consider leaving that position as soon as possible as it is not a good environment to work in (and as the author says, luckily there are enough opportunities for good programmers these days). But again, the problem here would not be the single bad programmer, but the setup of the whole organization, which is unfortunately much harder to fix.

You're right that often you can't fire someone for legal or political reasons, which is unfortunately all too common. However, I must oppose your proposal to just leave the org.

As discussed above, there are not many sanely-run companies out there. In my career, I used to take the "just leave" advice, but I've found this really stunts your ability to grow, personally and professionally, along multiple axes.

Unreasonable people are, unfortunately, a fact of life. I used to think a smart company could mostly avoid having them in the ranks. I still believe a smart one could more or less do this, and that damage from the stragglers can be mitigated, but I now just believe smart companies are unicorns and you should never expect to be working at one. This is a safe/important assumption because "smart companies" can turn dumb real quick, especially when/as visionary leadership is replaced by conventional business school cogs.

One must become a politician, which will enable one to flourish in the chaos, especially if passable political craft is combined with actual technical skill and good judgment.

If you're stuck with bad talent that can't be fired, you should redirect them into a side channel where the amount of damage they do is mitigated. There's actually a lot of bad employees who are perfectly OK with this. Most of them are primarily interested in security, since they know it's difficult to find new employers with their limited skillsets. Giving them their own little irrelevant kingdom will help with that and also keep the high-level bosses happy because they don't have to fire their cousin and make Thanksgiving awkward for the rest of eternity, or deal with a lawsuit from an employee who has already threatened to take the company to the cleaners.

> I've been there, there is nothing you can do in this case.

You can leave. You can become the contractor that doesn't care but racks in €1000 a day.

There are always options.

These are all long term solutions, and good ones. But life isn't always that simple. Why let one bad dev ruin it for everybody else? It's a bit like one person being rude. Would you leave for that? I meant it more in a "accept it and move on" way. To be honest, if you're in a similar situation at MegaCorp Inc, you already have to put up with many things out of your control.

But should we as professionals an answer to this problem? Or is it a management problem? (Although that's a cop-out, because that's still part of our profession). Is it human nature? Do other professions suffer from similar situations? These are interesting questions, to which I have no answer yet.

I have dealt with the "negative work" conundrum myself and just wanted to give some insight from my point of view on your comment.

1) It isn't always junior level programmers causing the negative work. When it is a junior level programmer, you are 100% correct that part of the blame (or MOST of the blame) falls on the lead/senior programmer. The lead/senior failed the junior without the appropriate structure, code review, etc to make their code maintainable and "healthy". Happened to me just this year and I let down one of the junior engineers on the team in a massive way and it showed.

2) What happens in the scenario that a senior/lead person is the one creating the negative work? Adding more oversight/tighter feedback loops constrains this person and will make them worse off than not. Anyone can make the argument that this person should not be a lead or a senior, but due to any number of business alterations (organizational changes, leadership changes, culture changes, etc) it is 100% a plausible scenario. What do you do then? How do you manage this piece of the puzzle?

Scenario 2 is where I have seen the most "negative work" created without finding optimal paths for fixing the issues at hand.

Bonus points if the senior/lead in scenario 2 really, really likes coding, and adds technical debt, bugs and ugly code at a rate faster than the other members can catch up with.

You are right but I also can understand his 'influential developer' negativity effect. In my place there's this one influential developer (the Team Lead) that can veto every decisions even though the others juniors/seniors under him already have consensus. He doesn't want the existing process to be altered. Now he's alone as everyone is leaving.

Had that happen, too. Had two tech leads over me who didn't want to learn anything new. One guy was in love with Apache Camel, the other, was just a J2EE guy from like the early 2000s. Frustrating.

You would think someone would be aware enough to do a code review of a newly hired junior developer pushing production code for the first time.

Yes, and this book epitomizes your point:

https://www.amazon.ca/Extreme-Ownership-U-S-Navy-SEALs/dp/12...

I recommend the read to anyone working within teams of people.

> ask yourself how you can build a process that makes it really hard for individual programmers to do bad work

That is a very constructive way at looking at things; I think I'll try this out with my team :)

Have you ever had to deal with a bad worker, though? In one company where I was a tech lead we had a guy who did nothing. When I assigned him work, he turned in garbage that someone else had to re-do (often me, working at home). He would go out to his car after lunch and get stoned and then come back in and fall asleep at his desk!

On paper, the team had four developers, in reality, there was only three. It was a huge headache trying to explain to PMs and other managers why our team didn't really have the bandwidth it appeared to have.

I therefore complained to our manager about this guy. The response was long in coming and when it finally arrived, we were to place the non-worker on an "improvement plan" which was mandated by HR. That means I had to work even harder now because I had to put together said plan and basically try to micro-manage this guy while also re-doing all his code. The improvement plan didn't work. His output was just as bad as always. This went on and on for months. Mercifully, the guy was finally let go after almost a year of dicking around.

All of this somehow reflected badly on me, however! My manager didn't like that I "made waves" in the company by requiring this guy to do work. He also didn't like having to smooth over all the ruffled feathers among the other teams who couldn't understand why we were always behind schedule.

Stupid, bad management is to blame, not me.