Hacker News Reader

> 1. Reducing dev friction.

This is so important, my managers who didn't code pretended things weren't too bad and took a "just deal with it" attitude whenever I proposed going for a QoL improvement.

On the flip side I had a manager who had written a lot of the codebase before I joined and had a terrible time allowing anyone to touch his precious baby, regardless of how much his prior ”art” was hurting us, our productivity, and by extension the company.

Yeah... I said it was a "flaming pos" I felt bad about that. But he won't let me add tests so idk whatever. (we prototype software so speed is the main goal but yeah, stuff starts breaking, backtracking, hey... tests)

Also, I'm just fundamentally skeptical you can do a good job of running a team, or hiring, when you don't know how to do the thing the team does. Software development skill requires active use/work to maintain it.

Here here. There are a lot of decisions where there is no real contest between the choices to someone who has tried both options but are difficult to tell apart from a distance. EMs should be in a position where they are trying things in practice.

I'd draw an example of someone who hasn't used git before, making a choice between a git repo and managing code by keeping daily .zip files. Anyone (almost anyone) who is a career coder won't see a choice there.

That example is so basic I think most EM would get that right even if they didn't deal in code but the same dynamic turns up at every level of work. There are situations where there is a right option, the right option is obvious to everyone who is working on it and it is is a drain on the org when management gets confused and thinks that something that isn't an option is viable because they aren't on the ground working on it.

I don't see why you need to be writing code to understand all of this. It can help, but almost everything you said is ascertained from daily syncs

Fewer or shorter daily syncs is a plus

You don’t need to be writing code. But it’s a convenient shortcut to a great many things that otherwise take dedicated effort to understand.

Some managers will do that. Most won’t. Given that, it’s easier to just tell them all to code.

Or just tell them all to regularly communicate/listen to their team? Sounds way more efficient.

Doesn't work, because the team won't always tell you of the issues that block them (normalization of deviance). Sometimes you need to find out yourself.

You can see this when you join a (disfunctional) new team, notice the friction, then suggest improving it.

If a manager communicated with and listened to their team, but their team had written a web service with gaping security holes or disastrous data integrity practices because all their senior engineers were incompetent and/or were hired at a level that was above their ability, would that manager find out just from chatting with them?

I promise you that it's not guaranteed. You need to actually go looking through the code to find everything that's wrong.

I think you can certainly learn a lot by being curious and fishing out anything that smells, yeah.

But agreed that youll find more mistakes, if your manager also happens to be the best IC on the team.

Daily syncs allow the loud, not necessarily the most productive, to dominate. You cannot judge someones actual contributions by what they say.

I didn't say you should be judging performance solely on daily syncs, but you have a myriad of ways of doing that as a manager including simply looking at the big-picture content of PRs, what issues a dev identified and solved, what devs contribute to discussions/technical solutions in slack/meetings, what projects are completed, and how well they turn out etc.

But eh? Doesn't matter how loud you are in a sync, you can very easily go off the actual content of what someone is saying. If someone goes off 5 minutes about how they managed to turn an object into a json string, that doesn't exactly make them look good.

I don’t see how you can understand something without being part of it.

It is like learning stuff from the book vs learning hands on. There is no book that will teach you skiing.

The same for working with the team - it is so much different than listening and trying to understand.

Everyone nags about how MBA graduates ruin everything by thinking that you can manage and it doesn’t matter who and what.

But you are a part of it. You are the manager of the codebase, you should actively be part of the discussions of what's being merged in, what your architecture looks like, what changes are required to complete a new project, what issues are arising, what the blockers are on projects, whats slowing down your team etc. None of that requires you to sit down and code.

If you're really listening and asking the right questions you should be aware of even changes like "Were deciding to use this HTTP client rather than what we currently have". OK why are we doing that? What was the issue? Ask ask ask.

As a manager Id argue you have (or should have) more technical insight into your whole codebase than any IC

How do you do any of that without extensively reading code? Do you consider reading large volumes of code not "sit[ting] down and cod[ing]"? Just because you're not actually producing large volumes of commits does not mean that it's not coding.

I think "coding" is commonly understood as writing code, not reading code, you know like if I say "I coded google jamboard", someone thinks I developed it, not read the source code. But besides, why do you need to extensively read code to understand whats going on?

Assume you read your code base once and understood it. You get a feature, discuss how its going to be done (well add this table, add these endpoints, etc). You should have a damn good idea already what thats going to look like in your codebase. I don't think knowing all the low level details is necessary (most people would call that micromanagement) and besides writing code yourself isnt going to help know all the low level details of all the other projects

After thinking about what you wrote here I have some conclusion:

If someone is "good manager" that does all those things whether he writes the code or not he is going to be a "good manager" anyway. Explicitly writing code might not be best use of time but hey if person feels like he needs it that is on him.

If someone is "bad manager" that doesn't bother to deal with technical details and wants only to do "important management stuff" and thinks he can manage by proxies like counting story points or counting closed tasks, does not care about HTTP client A or B and learning the system, he is going to be a "bad manager" and will never even care about writing code.

Finally "bad manager" and "good manager" - is hard to tell because "bad manager" can be good for the company or a team as much as "good manager" and depending on many other factors it can be that "down to earth, hands dirty, good manager" might be really bad for the company or a team depending on business context.

> or worked on hard problems because of comments and Git blame.

Oh lord we'd better hope they have absolutely IMPECCABLE git fu if they are going to be using this metric. Unfortunately here on HN I've seen people essentially brag that they only know just enough git to get by and "who cares if I don't know all the other commands deeply." In any event, this scenario REQUIRES that a manager know exactly how to determine who originally introduced something, or, exactly where it was significantly improved if they are going to be reading comments and blaming to see "who performs."

The very fact a manager might be doing this has got me a little worked up, mainly as I know great managers who don't do this and who are scared of something as simple as the reflog.

I tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini? My manager can code, used to code, sometimes does code, but they aren't familiar with their team's current work.

Like imagine you were a coding manager 10 years ago with AI experience. Sometime over the last 10 years your team does AI infra. You, as a manager and as an IC, have zero AI experience (you've never trained a model, never used a trained model, never using any of the various AI frameworks). Are you still okay to manage this team or should you be replaced with someone who does have that experience?

> I tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini?

I don't know that much about movie making, but my understanding is that there would be managers and/or leads within each specialty, who are (among other things) managing the interaction between their specialty and the director / producers.

That seems pretty comparable to what's being discussed here.

In any industry, if you want a team to work well, you have to have someone with both authority and hands-on experience who’s responsible for providing day-to-day guidance. Sometimes that person is called a “supervisor” or “tech lead” instead of “manager”, although this typically implies some division of responsibilities as well; no reason the person providing guidance necessarily has to be the same person reporting to leadership or hiring and firing.

Toyota calls it the gemba walk. Managers need to see how the factory is running with their own eyes. Not just live behind a desk and listen to what they hear in meetings.

A movie director can see the sets with their own eyes. But you can't see the state of a software codebase without reading and understanding the code, and the most surefire way to do that is to try to write something, even just documentation.

You don't assess the state of your software by walking around the office and looking at hands on keyboards. You look at the codebase.

> I tend to agree but, playing devil's advocate, is this true for other roles? Does a movie director need to know how to build sets? How to sew costumes? How to use Blender/Maya/Houdini? My manager can code, used to code, sometimes does code, but they aren't familiar with their team's current work.

Many directors started in other roles in the movie industry, typically as writers, PAs, or other subspecialties. Chad Stahelski was a stuntman and stunt coordinator before he started directing John Wick, and it really shows.

I think the clear distinction is between someone who understands a part of the job, and someone who is good at part of the job. If you don't understand how costuming works, as a director, you're going to have a hard time getting good costumes, but by no means does that mean you're able to pinch hit in that role. I personally believe that it's difficult to replace hands on experience as a way to truly understand something.

In software engineering, I think there's a huge gap between managers who worked in some other industry and transferred over, versus having previously been an engineer, even a mediocre one. Knowing how the sausage is made is hard to replace.

Though the fact that directors have certain biases from how they working into the role does also highlight an issue with this kind of effect: when you have technical leads or project managers on a big multi-disciplinary project, they will have a natural tendency to favor the areas they are more familiar with, and bias the decision-making and planning of the project around that. It can be difficult to step back and optimize for the project/system as a whole.

> When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too.

For me a good manager is a facilitator, not a leader. Someone who removes obstacles for us. Whether they themselves are affected or not. Someone only fixing an issue because they have to deal with it too seems like a pretty bad manager to me.

They're not for pushing targets or trying to weed out non-performance, I don't work at a playschool. My manager is there to make sure I can do my job and that I can reach my maximum potential (including making sure I'm in the right job)

When the company tells your manager "we need to cut wood" and you tell your manager "I need to sharpen my axe", these things are in harmony but it's still a balancing act. The manager should trust your judgement, but they may also have a better view of the short-vs-long-term tradeoffs, and sometimes we spend too much time sharpening. Sometimes we don't spend enough.

I think a good manager should be able to take a swing with the axe to get a feel for its sharpness.

Friction can be more of a problem too though. If your manager is objectively better than the team, estimates can get cut short and failing to meet those adds tension.

Obviously a good manager might pitch in, understand their teams capabilities but it's not always a natural transition for senior devs moving to management.

I think every team needs a TL. If the EM isn't filling that role, then another team member should be, and most of what you're talking about falls on the TL (with some sanity checking from the EM by talking to other team members about these things as well)

Well said — completely true in my experience. It’s called Engineering Manager for a reason!

I think it depends on how it is done, and the kind of ICs you have on the team. It can come off as micromanagement, which may work well enough if you have not-so-competent ICs, but will backfire if you have talented ones.

I've found it really helpful to be a support programmer. not someone that takes on big tasks. nothing with a hard deadline. not something that someone else needs to do their work. leftover cleanup. testing. minor refactoring. build.

you need to keep your hand in the game just to understand what's going on with the codebase. but you're not an a-list player here.

> It can come off as micromanagement, which may work well enough if you have not-so-competent ICs, but will backfire if you have talented ones.

Yep agreed - I've seen a couple of managers that were probably fine as developers but struggled (to their extreme detriment) with being pretty average compared to the senior developers that they were managing. Their 'helpful advice' just served to show how superficial their understandings of the systems were.

Just curious have you managed people? At what capacity (tl? Em? Pm?)? How big was your team? What was the company env like in which your team(s) functioned?

just curious what's your ssn, dob and mother's maiden name.

I guess I should have added some context. I have been (and keep swinging between) ic and management roles (including managers) regularly. I love coding and try to sneak in some when I have time (as a manager).

But that a manager should always code is not something i found helping the team or the manager - all the time. One size does not fit all. In startups yes frankly there is hardly a need for a manager and it is TL, TPM, EM role combined into one.

In larger cos though a most managers are innundated with all kinds of non technical work (meetings, alignment, perf management, product discussions etc). While having coded before is a great thing keeping uptodate is actually robbing the manager of time for all other things on the plate (and those actually benefit the team beyond what meets the eye).

Besides at large orgs there is also so much technical (think large scale design and integrations) knowledge that a manager needs to keep track of which also needs time investment.

Then there are various level/career related things that necessitate one or more TLs a manager needs to work with or manage and coding often gets seen as a manager "not doing their job" or worse stealing a junior engineers opportunities.

There's a lot more that is very environmental but hope sets some context.

At the same time, they also tend to start interfering in the solutions proposed by their team. It hard to stave off that temptation.

First: it's not "interference" if they are also part of the team.

Second: If their ass is on the line, then they DO get a bigger say. They are paid for seeing potential problems, guiding the team, among other things.

Man, I wish the manager's ass was ever on the line. The amount of times I've seen a manager's whole team get laid off and the manager get moved to a different team to fuck everything up again is too many times.

I think I've seen a manager get laid off never. And often seen half their team laid off because they were terrible at their job, but the management class takes care of their own.

Yeah if I implemented my manager's ideas, I'd be the one fixing them too. No thanks - if I have to deal with the problems, I'll decide the solutions too.

In practice, many act as an intermediary who can take the credit for the wins while passing down blame for the misses.

It's not a good leadership trait but it's an effective career advancing move.

The entire list on the post reeks of aspirational intermediary that doesn't actually do any of those things as effectively as empowered project/team leads who do contribute to the product. It's fluff and very easy fluff to remove without feeling pain. Of course, mediocre teams will have mediocre developers who won't want responsabilty and will benefit from intermediary "bossy" managers.

How is manager's ass more on the line compared to an IC ?

Managers always have a higher job security compared to an IC from my experience.

Poor managers always use this dumb excuse of 'ass on line' to override good decisions by ICs with their own shitty decisions.