[HN Gopher] Should managers still code?
___________________________________________________________________
Should managers still code?
Author : blah2244
Score : 82 points
Date : 2025-03-04 15:41 UTC (7 hours ago)
(HTM) web link (theengineeringmanager.substack.com)
(TXT) w3m dump (theengineeringmanager.substack.com)
| zusammen wrote:
| Generally, no. There's a risk of unfair competition for work
| (they can delegate the stuff they don't want because they have
| political power) and their code often becomes "untouchable"
| because few will call it out if the code is bad.
|
| A hobby project to keep current isn't a bad idea, though.
| LeafItAlone wrote:
| As an engineering manager, I actually pick up the stuff other
| people don't like to do or stuff I notice that is hanging out
| there. My goal is to move the team forward.
|
| I've also done POCs of work that has been met with resistance
| that I didn't feel was justified in order to actually give it a
| fair shake. That is my coding fun.
| bryanlarsen wrote:
| > I've also done POCs of work that has been met with
| resistance that I didn't feel was justified in order to
| actually give it a fair shake. That is my coding fun.
|
| I've had managers do this to me. What an awful experience.
| Because they're the manager you can't push back against the
| awful design decisions they made. They feel it's almost done
| so don't understand that it takes a lot of time to deal with
| all the side effects they didn't consider.
| LeafItAlone wrote:
| That's very valid feedback.
|
| I hope I don't come across that was and do have some
| evidence (not to be laid out here) supporting that I don't.
|
| I think I've created a team and structure where the
| developers I manage are comfortable telling me I'm wrong or
| what I didn't consider. It happens weekly. We value honest
| feedback highly. We do it with respect, but we do it.
|
| We just have some developers on the team that are resistant
| to ideas that don't follow a pattern until they see it. And
| sometimes my communication around the initial idea is poor
| and the best way I can communicate is an implementation.
| james_marks wrote:
| As with virtually everything in this thread, it matters
| how you do it. Sounds like you did it well.
|
| I'll add one other great edge in building a quick POC
| yourself. Sometimes your idea actually _is_ bad, and
| trying to articulate it in code helps you see it.
| scarface_74 wrote:
| A POC should just be a happy path to prove a concept. I had
| a CTO who would routinely throw together code just to prove
| out an integration or another concept with hard coded
| values everywhere and drop the code in Dropbox for me to
| lead the effort of making it production ready as the
| architect. He would go back and forth with the vendor until
| things worked.
|
| This helped me out by leaps and bounds. I was usually
| swamped with other research. I would then make it ready for
| production or lead the team to and take care of the edge
| cases, integration with our config system, logging and
| alerting, etc.
|
| There is a huge difference between a POC and an MVP. An MVP
| should be properly designed and scaffolding that you can
| build on, a POC doesn't take those things into account.
| evidencetamper wrote:
| > unfair competition for work
|
| That's a very good indicator of a bloated institution. People
| have to compete for work instead of pushing it away or avoiding
| it because they already have their hands full.
|
| But I don't believe there is a general rule that applies here.
|
| Most great managers I had were deeply technical and involved in
| the nitty gritty of the projects, including coding the very
| spiky aspects of a project.
|
| Most mediocre managers I had were very focused on relationship
| building. The kind of manager that would need a hobby project
| to keep current, instead of being the most knowledgeable person
| in the room.
| mandelbrotwurst wrote:
| People might compete for the work they view as relatively
| more attractive for a variety of reasons even when they are
| quite busy.
| SOLAR_FIELDS wrote:
| The author starts off with this statement:
|
| > I think that there is a big difference between being in the
| code and writing code. All managers should be in the code,
| but not all managers should be writing code.
|
| I think it's not possible to be _in_ the code without
| _writing_ code. People can pay lip service to being _in_ the
| code as the author indicates, but as we all know there is no
| substitute for actually sitting down and writing the code
| yourself in terms of understanding the actual pains and
| struggles.
|
| And my anecdotal experience says that if you aren't writing
| at least some of the code, more often than not the disconnect
| between the manager and what the team is doing grows and
| grows.
| nobleach wrote:
| While that is possible, I think a good manager recognizes these
| pitfalls. My philosophy is "everyone has to scrub toilets once
| in awhile - that includes me". You'd have to ask my direct
| reports but, I'd like to say I lean more toward taking the
| "grunt tasks" that I don't think are super helpful for my
| folks' career growth.
|
| Then again, I've been called a bad manager on Hacker News so...
| LeafItAlone wrote:
| That's how I see it myself.
|
| Obviously being a good manager is first and foremost, but
| I've always had more respect for managers that I know can
| (even if they never do) do my job as well as bring a manager.
| Early in my career at a startup I had a manager that was both
| and excellent manager and right there in the trenches with
| you when issues arose or business deadlines were approaching.
| The amount of respect I still have for that individual is
| immeasurable and I'd go work for them again in a heartbeat if
| they asked.
| otherme123 wrote:
| And OTOH, nothing worse than a manager that don't know what
| he wants nor how to do it, but he "will know when it is
| right", and keep you redoing stuff.
| pc86 wrote:
| IMO if an EM is taking the fun stuff, or the high-profile promo
| packet stuff, that's a symptom of a lot of very bad things. My
| boss is an upper-level EM and has at least a few PRs in a
| couple projects every sprint, and it's almost entirely boring-
| but-blocking stuff, or stuff that nobody wants to figure out,
| or stuff that is important but not sexy and not likely to get
| anyone noticed. He's not writing new features or writing UIs
| that are getting put in pitch decks or anything.
|
| If I were an IC and my boss was picking the sexy work I would
| leave. If I was a director and one of my EMs was picking the
| sexy work I would fire them.
| devmor wrote:
| This is a good article, and I find myself agreeing with it almost
| entirely. My current manager is one of the most effective
| development managers I've ever had in my career, and I think a
| good part of that is because he is involved in the codebase, but
| not directly responsible for new features in whole.
|
| I have had managers with no concept of what's going on the
| codebase, and those were dysfunctional development teams that
| produced poor results, despite great communication and productive
| meetings.
|
| I have had managers that were effectively another engineer on the
| team, and those were dysfunctional development teams that
| produced decent results, but had poor interaction with
| stakeholders and no unified direction.
|
| As in many things, the ideal seems to be a happy medium. Someone
| who can read the code, who can write the code, and is interested
| in both, but whose duties are not primarily to do so.
| hermitShell wrote:
| I agree with this sentiment! One way to set up teams is with a
| squad leader who acts as shit shield first, and developer if
| the company is running smoothly. That way if the boss manager
| is a full time shit shield with little time to understand
| product, the team still has a local product owner to guide the
| team's vision and concept of the product, but the power
| imbalance is also less as the team lead could fairly easily be
| deposed by accessing the manager.
| asdev wrote:
| Absolutely not. Nothing like an out of touch manager slowing down
| their engineers with random PR comments and questions. They
| should not go deeper than the design document/architecture level.
| They are not adding any value trying to put their washed skills
| on display.
| kvdveer wrote:
| Tldr: managers should be in the code, but should not code
| themselves.
|
| The article suggests managers should focus several tasks that
| depend on the ability to code, but not produce code themselves. I
| think that's not sustainable. When a manager stops producing
| code, their skills in that area begin to deteriorate. I've seen
| it happen several times. When you stop coding, you'll eventually
| start missing crucial things in code review, make very poor
| estimations of labour involved, and assign the wrong team members
| to tasks. It won't happen immediately, but it will happen within
| 5 years.
|
| I think a better way is to keep producing code, but at a lower
| rate. If the project you're working down doesn't permit low-
| commitment development, start developing tooling or pick up a
| side project. A coach doesn't need to be a top-player in the
| coding field, but they do need to remain fit.
| technojunkie wrote:
| Middle management for software engineering has gone through a
| paradigm shift. The trend for businesses is flatter structures,
| manager roles with more responsibilities and this reality largely
| includes being as deep in the code as direct reports.
|
| Since 2023, most roles I reviewed or interviewed for were
| player/coach roles, often close to 50/50 split. In my last EM
| role, I was hired for exactly this.
|
| I found very few EM roles that are primarily managing with only
| "being in the code"; I can count on my hands out of hundreds of
| Engineering Manager roles. Probably closer to 95% or more EM
| roles require hands-on technical work similar to Tech Lead roles.
| oldandboring wrote:
| I have noticed this as well, and if you're interviewing at a
| startup, it's almost guaranteed to be a highly technical
| position. Either a hybrid EM/Tech Lead role or a hybrid
| EM/architect role.
| peterldowns wrote:
| True in my experience as well -- and I think it's a good thing
| but companies are way behind in preparing people to fill these
| roles.
| williamcotton wrote:
| From the article:
|
| > _It depends on the manager, the team, and the organization. As
| a senior leader, I would rather my managers be in the code as per
| the above list, but not necessarily putting themselves in the
| critical path by writing code, given that they are likely to be
| interrupted more often, have more meetings, and be pulled in more
| directions than their reports._
| righthand wrote:
| I was a manager for about 9 months before being laid off. The
| goal was to attain power but also work on the huge backlog of
| work we had. I wanted to use the power to block outside forces
| that would push my engineers in the wrong direction or remove
| their focus for investigating things like platform bugs.
|
| What ended up happening was that the project work even though
| completed was used to gaslight me for 6 months as breaking the
| platform and causing bugs. Issues that infra team promised to
| "fix later".
|
| Go ahead code when you're a manager it can be effective, but be
| careful when working with outside ineffective teams they will put
| blame on you if they can. Management is political and once you
| start making moves that outshine other teams, opposition will
| come out of the wood work to bring you back to their level of
| unhappiness.
|
| The trick to identifying this is when people start naming you at
| meetings you aren't in. It might be good things they are saying
| but that may shift as the good things well dries up.
| lkrubner wrote:
| "But what does this mean for frontline engineering managers? Is
| the new normal just about writing more code and doing less of the
| other things that peacetime managers would normally do?"
|
| "Should they be able to do code reviews? Yes."
|
| There is no standard answer here. At many companies it is the
| Head Of Product who also oversees the tech team. They may not
| know how to write code, and will not know how to do code reviews.
| Some project managers lead engineering teams without knowing how
| to code. That's especially true outside of the tech industry.
|
| For anyone interested in specific numbers, I interviewed Eric
| Garside about his experience scaling Freshly from 3 engineers to
| almost 80 engineers, see here:
|
| https://respectfulleadership.substack.com/p/eric-garside-as-...
|
| I also surveyed several of the CTOs who I know in New York City,
| about team size and scale and responsibilities, they gave their
| answers here:
|
| https://respectfulleadership.substack.com/p/a-survey-of-ctos...
| giantg2 wrote:
| I've never seen a dual role manager that is actually good. It's
| usually a senior dev that gets stuck with management duties. They
| are usually good technically but then lack finesse and knowledge
| about most managerial issues (budget, employment law, team
| dynamics, etc). You're now at a disadvantage because the stuff
| they are supposed to protect you from or have power to help
| further your career is not developed. If your managers don't have
| enough management work, then flatten your org and expand their
| reach so they do.
| pc86 wrote:
| It really only works in orgs that are large enough to accept a
| bit of bloat, mature enough to have good managerial practices
| and invest in growing managers, and where the new manager has
| only a couple reports (2 is the perfect number). So you take a
| very good, senior IC who wants to be a manager, you cut their
| IC duties by 25-50% and you give them 2, _maybe_ 3 direct
| reports. This is after doing some sort of formal managerial
| training, internal or external, and with the acknowledgement
| from their director /senior manager that they're going to be
| spending more time with them for the next 2-6 months and having
| skip 1:1s to make sure everything is going ok.
|
| How many organizations do you think check all those boxes _and_
| are willing to do that? It 's not many.
| giantg2 wrote:
| Yeah, I've never seen one that checks all that.
| pc86 wrote:
| I've bounced back and forth between IC and EM
| (intentionally) and I've seen some that get very very close
| then completely blow it with one of these. One in
| particular would put people through management training for
| a full day each week for months, give them a very senior
| director, all the "right things" but then cut their IC
| duties by maybe 10-15% at most and give them a team of 12
| people to manage. And they wondered why fully half of new
| managers wanted to go back to IC work after a year or two.
|
| The best realistic thing I've seen, and my current
| workplace, is pretty good with small teams and training and
| all that, but basically doesn't offer any pay increase from
| upper level IC to first-level management and so you have to
| be okay with basically 20% more work for the same money.
| It's not perfect but one benefit is you don't get any
| managers who are only in it for the money.
| peterldowns wrote:
| I don't see your contact info in your HN profile but
| could I get in touch with you to learn more about how
| teams can get this right? My email is in mine.
| robotsquidward wrote:
| My best managers were ex-engineers who didn't touch the codebase.
| They understood how things worked, and could talk architecture &
| concepts, but they didn't expect to be able to sit down and write
| code at our level. Maybe they wished they would have the
| time/opportunity still, but realistically they were focused on
| leading.
| giantg2 wrote:
| This is exactly how it should be in my opinion. This matches my
| experience with who I saw as being good managers.
| fifilura wrote:
| Were they happy with it or did they become miserable after a
| while?
| giantg2 wrote:
| They were happy with it. On the opposite side, almost every
| dual role manager I've known have been miserable. Most of
| the ones I knew dropped out and went back to dev only work.
| A few stuck it out and got promoted into a no-code
| management role.
| mitthrowaway2 wrote:
| My best managers did code! They didn't close tons of tickets
| but they did do small things, and by keeping active in the
| codebase they were very cognizant of the state of documentation
| and technical debt, and could make informed decisions without
| relying on second-hand reports. It kept their understanding of
| the codebase grounded in reality. They knew which features were
| held together with duct tape, what areas needed attention, and
| planned timelines and expectations accordingly.
| lexandstuff wrote:
| This is 100% my experience. I appreciate a manager who can
| jump into the codebase to fix the small stuff: typos, lint
| issues, updating minor dependencies, etc., unblocking devs
| from doing the main work. I like when they have some sense of
| the reality of the codebase, as you put it, and know who is
| actually contributing vs bullshitting.
|
| The worst managers I've ever had were the so-called
| "technical" managers who had never looked at the code. They
| were often involved in technical decisions, but their
| opinions were entirely based on vibes. Since they were a
| manager, people felt obliged to listen to their input, even
| if it made no sense.
|
| Either: a) be completely non-technical, and make sure you
| have a technical leader on the team who you trust, who does
| know the code or b) get involved in the code, enough to
| support and unblock your team.
| only-one1701 wrote:
| In my experience, there's a time limit on how long these kinds
| of people can be good managers from the perspective of
| accurately assessing a) which ICs are contributing what and b)
| how long it it'll take to implement something. The fact of the
| matter is that an engineering manager who can't or won't write
| code will never know as much about his team or indeed the
| product as one who does.
|
| It's a shame that the "maturation" of the tech industry has
| resulted in these non-coding eng managers whose main skillset
| is often bullshitting, managing up, or both.
| bitwize wrote:
| Maybe?
|
| Managers should not be evaluated based on code output -- it's not
| their job. However, writing code here and there -- to evaluate
| new technologies, make a rough prototype, or demonstrate a
| technique to be adopted by individual contributors -- may aid
| them in their management responsibilities and should be embraced
| when it does.
|
| I've seen what happens when a manager is also responsible for
| individual coding duties. He ended up with roughly twice the
| work, shifting between two mutually incompatible mental
| modalities all the time, cranky with his subordinates and making
| a lot of sad phone calls to his fiancee explaining that he'd be
| late home from work, again. Not a good fate for any worker, even
| if the pay and prestige are better.
| kevinventullo wrote:
| One important distinction to make is the difference between a
| manager who started out as an IC on the project (esp. the case
| when they actually built the thing from the ground up) versus a
| manager brought in from the outside. I think the former is more
| likely to be hands-on and generally speaking the expert in the
| room. But, sometimes you need the latter. It can be challenging
| (even counterproductive) for the latter person to try to be
| technically relevant, when they are often the _least_ technically
| knowledgeable person in the room when they join.
|
| I say this as someone who has been in both roles!
| peterldowns wrote:
| I'm curious, how have you seen the "outside" manager build
| trust/confidence/respect with the team without doing at least
| some engineering work?
| kevmo314 wrote:
| > Do code reviews. Don't just skim PRs (sorry, reader!), but
| really dig into them: run the branch locally, test it, think
| critically about the design and the implementation, and provide
| feedback. Record a video of your review to highlight things that
| could be better.
|
| Please no! Most managers want to increase output and engineers
| are aware of that. It is exceptionally frustrating when your
| manager tells you during your 1:1 that they want to help move
| things along and then does quite literally the opposite in a PR.
|
| If you must dive deep into a PR, get the PR unblocked and then
| follow up with the change. Or stop telling your direct reports
| that you want to help unblock them.
| alkonaut wrote:
| Anything that can be done in a follow-up shouldn't have to
| block a PR. But if the architecture is wrong, it's better to
| fix before than after. You are speeding your teams throughput
| by pointing out the problem earlier rather than later.
|
| But I don't think a manager necessarily needs to be at this
| level of detail.
| roenxi wrote:
| > But if the architecture is wrong, it's better to fix before
| than after.
|
| Although this is true; if the manager is thinking about and
| getting involved in architecture _after_ the PR is written it
| does suggest something has gone wrong. If there are
| architectural considerations then it is good to discuss them
| with the coder before they start developing.
|
| PR review is a great time to pick up subtle bugs, do last-
| line sanity checks or get used to someone's style but if they
| are a bad arena for combating most code issues. If they are
| picking up design problems there is probably a process flaw
| to be corrected.
| ein0p wrote:
| Modulo the video, I did exactly this when I ran a team, only
| for what I thought were "important" or "gnarly" PRs. It works.
| I rarely had to spend more than an hour on a PR, because small,
| atomic PRs were all but mandatory on my team, with "atomic"
| taking precedence over "small". I would also review some of the
| PRs post-facto, after they are committed, as I was almost never
| a "formal"/blocking reviewer on them.
|
| Recording a video seems excessive to me. No one has the time or
| desire to watch me bloviate about something that I could say in
| a few PR comments that can be quickly skimmed.
| peterldowns wrote:
| Can I get in touch with you to ask more about your time
| leading teams? No contact info in your HN profile but if
| you're interested, my email is in mine.
| Cthulhu_ wrote:
| If you as a manager have the time to do an in-depth code review
| like that... you're doing micromanagement and you're showing
| that you don't trust your subordinates. And clearly, you don't
| have anything more important to do.
| mp05 wrote:
| > If you mean being the primary implementer of features, then
| probably not.
|
| It's my belief that any engineering manager worth their salt
| should push back on this and argue for a seat at this table,
| every single time. I don't want to work for someone who is
| disinterested in new functionality in codebases under their
| purview.
| scarface_74 wrote:
| I want my manager to _manage_. I need them to play the politics
| to get what I need as far as resources, to set business
| priorities and to make sure I'm aligned with those priorities.
|
| I need them to then trust me to accomplish the objectives
| myself on smaller implementations or to lead the team on larger
| implementations.
| mp05 wrote:
| I can't tell if you're agreeing or not?
|
| I'm not asserting anything about if a manager should code,
| but rather calling out a statement in the article. A good
| engineering manager should never be surprised by some new
| functionality.
| n_u wrote:
| Strong yes for 3 reasons
|
| 1. Reducing dev friction.
|
| 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. If build times went up, deployment
| infrastructure broke or someone's PR broke dev they would roll it
| back immediately. If someone consistently blocks PRs the manager
| noticed the trend and would address it.
|
| 2. You get a much better sense of IC's contributions by writing
| code.
|
| There are ICs who play politics very well and sell themselves but
| that set is not the same as the ICs who deliver. If you are
| writing code you start to notice which ICs have written key
| features, built critical APIs or worked on hard problems because
| of comments and Git blame.
|
| 3. Understanding your codebase.
|
| I hope most managers have solid CS and engineering fundamentals
| but that is a necessary but not sufficient condition to grasping
| the full picture. There's a reason it takes time to ramp up to
| full productivity on a new codebase. If you work in the codebase
| and have had to use that one annoying but critical library or
| dealt with that tech debt from 2 years ago then you know what is
| hard and what isn't. I've found when a codebase has a quirk that
| makes developing certain features hard all of the non-technical
| people keep forgetting why we can't do that thing and all the
| technical people have it burned into their brains.
| x0x0 wrote:
| 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.
| roenxi wrote:
| 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.
| flashgordon wrote:
| 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?
| apwell23 wrote:
| just curious what's your ssn, dob and mother's maiden name.
| flashgordon wrote:
| 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.
| apwell23 wrote:
| At the same time, they also tend to start interfering in the
| solutions proposed by their team. It hard to stave off that
| temptation.
| whstl wrote:
| 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.
| peterldowns wrote:
| Well said -- completely true in my experience. It's called
| _Engineering_ Manager for a reason!
| dietr1ch wrote:
| > 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.
| vrosas wrote:
| 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.
| ge96 wrote:
| 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)
| eevilspock wrote:
| 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.
| convolvatron wrote:
| 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.
| oliwarner wrote:
| 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.
| andoando wrote:
| 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
| dv_dt wrote:
| Fewer or shorter daily syncs is a plus
| Aeolun wrote:
| 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.
| webdever wrote:
| 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?
| theresistor wrote:
| > 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.
| SpicyLemonZest wrote:
| 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.
| mitthrowaway2 wrote:
| 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.
| chasd00 wrote:
| i lead dev teams in the consulting world, I don't code even
| though i really want to. Sometimes I get pulled in for time
| sensitive work or the hard stuff but that's about it. Every time
| I get bored as a manager and reserve some fun stuff for myself a
| crisis happens that needs my attention and then the code falls
| behind schedule. So I guess that's the end of that.
|
| i like the analogy of a sports team coach for being a manager.
| You can motivate, cheer, train, and drive the team to victory but
| you can't step on the field.
| breadwinner wrote:
| Steve Jobs on this topic:
| https://www.youtube.com/watch?v=bVKcxK_tVBM
|
| Summary: Managers who know how to manage, but don't know how to
| do anything are not the best managers. The best managers are the
| great individual contributors who never ever wanna be a manager
| but decide they have to be a manager because no one else is going
| to be able to do as good a job as them.
| TrackerFF wrote:
| Anecdote: This is also how you end up with the "Peter
| principle", unfortunately.
| scarface_74 wrote:
| Managers who didn't want to be managers are the worse ones.
| They don't know how to play politics and compete for resources
| against other managers and make sure their team gets raises and
| promotions.
|
| The skillset you need for management are different from those
| you need as an IC
| breadwinner wrote:
| > _They don't know how to play politics and compete for
| resources against other managers and make sure their team
| gets raises and promotions._
|
| Clearly those are not the skills Steve Jobs valued.
| JustExAWS wrote:
| Yes and Steve Jobs led illegal collusion between most of
| the big tech companies to keep compensation down. He wasn't
| exactly the most employee focused CEO.
|
| https://research.upjohn.org/cgi/viewcontent.cgi?article=134
| 3...
| jedberg wrote:
| This comes from the perspective of someone who manages
| managers. So if you're looking to hire managers, and don't care
| about retention, perhaps this is good advice to follow.
|
| But if you're looking to evaluate _your_ manager, or hire
| managers who can retain great people, maybe not the best
| advice.
| crazygringo wrote:
| There's a third option that's missing from that dichotomy:
| people who are OK individual contributors but who are actually
| really good at managing people.
|
| These are the best managers, because they have the
| disposition/skills to be a good _manager_ , but also aren't
| going to make dumb engineering decisions.
|
| IC's who become reluctant managers are generally _terrible_
| managers because it 's not what they're good at and not what
| they enjoy.
| georgeecollins wrote:
| I once had a lead programmer (who was a great one) who insisted
| that a manager should not have access to the source code of our
| project. I have often worked with engineers who were nervous
| about who could check in code so I kind of understood. And this
| really was a great lead, technically strong and a good leader so
| I said, fine no code access for me.
|
| It was a terrible mistake for me. So much of my value as a
| manager was being understand what the engineers were doing. I am
| not a great programmer but I can do it, and I could usually
| understand what an engineer was trying to do from looking at
| their check ins rather than listening to them in stand ups. I was
| just not that useful. There were times when the team was doing
| things that I knew I had seen done before with much better before
| with different methods, but just talking about it was relatively
| ineffectual.
| inglor_cz wrote:
| Why not a read-only access? This way, the manager cannot break
| anything.
| Vaslo wrote:
| Don't allow your skills to atrophy. If you get to a high
| position, it's much harder to find a job at that level. If you
| can code, you can always find something.
|
| If you can't code, and you can't get a manager role, you're in
| trouble.
| scarface_74 wrote:
| That's why I have one year of expenses in a liquid savings
| account in addition to retirement savings. So I can have the
| runway to get back into coding if necessary.
|
| Are you proposing that they do coding on the side after they
| get off of work? I have a strict policy of "no side work" and I
| have since graduating from college in 1996. When I get off
| work, I don't think about computers again until I go back to
| work the next day.
|
| I'm not a manager. But I am now a "staff software architect"
| working full time at a third party cloud consulting company
| after pivoting from software development and doing a previous
| stint working at AWS in the consulting department (full time
| direct hire - AWS Professional Services).
|
| My specialty is supposedly developing applications using AWS
| services. But as I moved up I find myself doing no coding.
|
| My job is half working with sales and being the first technical
| contact for a customer and writing long and detailed
| requirement documentation and getting the customer to sign the
| contract for us to do the work. The other half is as a tech
| lead coordinating between the customer, project manager, sales,
| and the subject matter experts on our side who lead/implement
| the various "work streams" (development, data, cloud
| architecture, etc).
|
| First issue, when I was looking for a remote job last year and
| the year before as a developer as a plan B job, every opening
| had hundreds of applications and I heard crickets. This has
| never happened to me and I looked for software development jobs
| in 1999, 2008, 2012, 2014, 2016 and 2018. The job at AWS fell
| into my lap in 2020.
|
| It's a shit show out there right now for software development
| jobs especially remotely. Did I mention I was looking for
| regular old enterprise Dev jobs?
|
| On the other hand for differentiated strategic cloud consulting
| jobs, I had no problem getting offers quickly.
| tdeck wrote:
| A lot of what's in the article resonates with me. Specifically,
| I've seen cases where managers unwittingly use coding (a problem
| they feel comfortable with) as a way to escape from facing more
| serious manager responsibilities (problems they don't feel
| comfortable with). When you've got 10 years of experience doing
| X, and you just started doing Y two years ago, it's natural to
| try to play to your strengths by doing X.
|
| But as a manager, there's a whole category of things that only
| you can effectively do, because the social environment and power
| structures are set up that way. In that context, coding is a
| distraction for a manager. Writing code often takes a lot of
| mental energy and stays in your head even when you're not at the
| keyboard.
|
| I don't want my manager getting nerd sniped when they should be
| coaching a struggling colleague, advocating to upper management,
| having a tough conversation with a toxic team member, or reigning
| in the PM.
| peterldowns wrote:
| I'm in favor of managers being engineers but everything you
| wrote is true. I wish I had read this comment a few years ago,
| it would have saved me and my teams some trouble.
| jawns wrote:
| As a manager, I make a point to produce some code that makes it
| into production every quarter, but my reason for that is not
| because I can't help myself from writing code. Rather, I want to
| understand the pain of the sdlc. I want to understand firsthand
| how long it takes to get something deployed and how many steps it
| takes. Being able to empathize, rather than just sympathize, with
| my direct reports has made me a better manager.
| pragma_x wrote:
| Should they be able to? Absolutely. Should they exercise this on
| projects they manage? Probably not.
|
| I ran into this problem years ago. It's not exactly good form to
| be manager that contributes to the team's project, is at the apex
| of code review, and is responsible for team performance reviews,
| all at the same time. It can work, but without other people at
| your level reviewing your work, you'd be asking the team you
| manage to call out your mistakes. That's the kind of thing that a
| lot of people might not be comfortable with, so you're really
| asking for softball and rubber-stamp reviews on your work. This
| makes for poor optics: your work always goes to `main` virtually
| unchallenged, while everyone else has a harder time.
|
| At the same time, you need to be technically competent if you're
| managing a team while in the review loop. To do otherwise is to
| create situations where you will lose face with your team. So,
| sticking to review only is probably the best answer here.
|
| There are workarounds though. It makes sense to maintain a pet
| automation project just to stay sharp while solving real problems
| (e.g. every manager needs better reporting). You can also
| negotiate out cross-team contributions where your work may be
| reviewed by folks that do not report to you.
| dan_can_code wrote:
| To "lose face" with a team shows a lack of trust. I think it's
| fine if you don't have a perfect solution, but require some
| eyes on your work. But you're right, if you don't have people
| your level (or better yet, more experienced) reviewing your
| work, getting an honest code review is challenging.
| scarface_74 wrote:
| A manager should _never_ write any code that is part of the
| critical path of the deliverable.
|
| Every single time without fail that I have had a manager who
| still tries to be an active contributor, one of two things
| happen.
|
| Either they never keep their commitments as a coder because they
| are spending too much time on their management duties including
| meetings, manhole up, and career development for their reports or
| they are horrible managers who don't or can't do what I need from
| them as a manager - get me the resources I need to do my job,
| play politics and manage up and especially fight for raises.
| simonw wrote:
| When I've worked as an engineering manager I've found the advice
| to "stay out of the critical path of getting features into
| production" to be very helpful. It's difficult to commit to
| coding timelines as a manager, and it harms your team if _you_
| are the bottleneck to shipping something.
|
| But... keeping your hands in the mix elsewhere helps you stay
| informed and make better decisions. I found writing things like
| internal debugging tools, documentation, helping out on code
| review and architectural discussions, building example features
| against APIs etc were all good uses of my time.
|
| An interesting trend I've observed over the past couple of years
| is that a lot of my friends who had moved into engineering
| management and stopped coding completely are picking up more
| coding tasks now thanks to LLMs - previously spending ~4 hours
| getting a development environment working and getting back up to
| speed wasn't justifiable, but LLM assistance means they can now
| get something small and useful done in just an hour which is much
| easier to carve out time for.
| peterldowns wrote:
| "Your manager should be able to consistently make small
| contributions" is also a good litmus test for your developer
| env/tool/experience. If it takes more than 20 minutes to get
| set up and start working your team probably has a problem.
| alostpuppy wrote:
| 100%
| gogasca wrote:
| I'm manager and contribute every week for clean up, refactoring,
| add tests, extra e2e testing and overall fixing issues in
| existing development and production environment that are either
| too boring or affecting team operations. Sometimes contribute to
| small features but I make sure Im.not blocker or promise things
| to anyone (mainly work on experiments with no SLO)
| svilen_dobrev wrote:
| it depends. Last ~3 years i was CTO of small company - with a
| software team of 7-10. With the idea of - no-more-coding (TM).
| Just the other 90% - from cleanup repos and jira etc project
| things - to organise proper reviews and workflows - process
| things, etc, to.. pushing infrastructure, hiring and pitching to
| investors/clients. But the codebase was.. not ideal. It was hard
| and tempting but i managed not to touch it directly, only did
| rise architectural-and-similar-level issues, and did (somewhat
| nitpicky) code reviews - like, date-arithmetic IS very important,
| pretty-please. Still, had to build a crawler over the production-
| codebase to visualise the event-flows and map consequences - a
| reverse-engineering live-Documentation, kind-a. Scratching my own
| itch? pfft. (hint: There was no other docs..)
|
| But then there were some small non-essential projects that would
| have been complete distraction for the team.. so i took one, then
| another. In nodejs which isn't my cup of tea - so even better,
| learned some things the hard way. Though.. lucky they were rarely
| needing support, or it would have become a chore.
|
| Then, one day, the company was acquired, and.. i am not a CTO
| anymore, but a (tech and also non-tech) Lead of some future
| greenfield project, ~re-factor with diff.goals. So here we go -
| research, architect, code, hire, discuss, demo, eh.. usual tiny-
| startup thing - except that the politiking and the now-everyday-
| a-new-policy chase me away.
|
| So.. IMO one has to keep _some_ of the programming skills sharp.
| In order to stay relevant. But this applies when you are 1 level
| away from actual coding. If farther.. probably no time, and no
| point. Although.. too long staying hands-off, and there may be no
| coming back - and losing grasp of how-it-feels-like to be in the
| trenches.
| mcherm wrote:
| One important caveat: I recommend that managers take on coding
| tasks that are SMALL and UNIMPORTANT. Leave the key work for the
| front-lune developers (feel free to code review it).
| 999900000999 wrote:
| Yes.
|
| Back at my first salary job, the CTO of the company would
| occasionally jump into the code base to write some code when
| everyone else was busy .
|
| It was a very small startup, but seeing him do that motivated me
| to work harder. It was also just a very awesome thing for him to
| do, since he could have just said no I have to go pick up a pie
| this evening figure it out .
|
| Below him, the best manager I've ever had, was regularly writing
| large amounts of the core code base. In my opinion this is really
| good for team morale. If you want to call yourself a startup,
| this is how things should be done .
|
| When I think about it, I really would only like to work for
| startups with around 50 people or less, or mega corporations. I
| don't particularly like the quasi 1,000 person start up with 800
| rules, and a lack of stable funding.
| ryathal wrote:
| A manager of developers should know how to code, but any formal
| expectation of them coding shouldn't exist. This holds for medium
| to large organizations. The managerial duties should be enough to
| require the vast majority of their attention. Expecting
| development on top of management is a way to add fake capacity to
| a team to help ensure burnout.
| jedberg wrote:
| I'm a good coder, not a great one. I hire great coders to work
| for me so that if I had to write code I would be the worst and
| least productive person on the team.
|
| Therefore it is to everyone's benefit that I don't touch code. I
| do sometimes put on an engineering hat and help with
| brainstorming how we will build new things, or asking questions
| about open issues that no one has asked, but that is the extent I
| will get involved in engineering. I try to only get involved when
| it's something where my decades of experience will add a lot of
| value.
|
| And historically all the best managers I ever had were the same
| -- former engineers who could understand everything we were
| talking about, but did not get involved in coding or code
| reviews.
|
| Your manager should never be a blocker to getting things done.
| bionhoward wrote:
| Isn't one of the best gifts a manager can give to their team, the
| gift of clarity?
|
| A manager able to give their team programmatic tests to pass
| brings a level of precision which makes it much easier for them
| to know when the work is done.
|
| If managers communicate requirements in the form of acceptance
| tests more often, then the problem of projects running over time
| and over budget will occur significantly less often, because
| there will be clear finish lines for dev teams to run towards and
| cross, and reproducible pass/fail outcomes to inspire confidence.
| _hfqa wrote:
| clarity, purpose and a path for career growth
| massung wrote:
| My view - as a manager - is that as I get older (simply put) I'm
| not as good any more as my younger team! While I help them, I
| also learn a lot from them as well. And I love that.
|
| I have experience: project management, real life, edge cases,
| dealing with C-levels and customers, risk mitigation, being calm
| when sh*t hits the fan, mentoring, etc. These are things the team
| benefits from far more than my fingers typing away.
|
| At the same time, if I'm actually doing my job well, I really
| don't have time to code.
|
| I also want my team (senior and junior) to have a feeling of
| ownership. The company has goals and directives, but what's being
| built belongs the team, not me. All the successes are theirs, and
| the failures are mine alone.
|
| When do my fingers hit the keyboard? When there's a time crunch
| (if I'm not willing to work more how can I ask the team to?),
| when the team is having a difficult time with a particular
| problem, or maybe when there's some downtime and I can fix a few
| outstanding bugs or work on something extremely isolated (I never
| want to get halfway through something and then have to hand it
| off to the team).
| MattPalmer1086 wrote:
| Short answer: no.
|
| Background: I used to be a developer and have managed developers.
| Now I work in info sec and manage info sec.
|
| Longer answer: this question has been discussed throughout my
| career.
|
| (1) Does it help for a manager to understand what a team does and
| needs to do? Absolutely yes. Some managers can do this without
| domain experience but it's a lot harder for them and the team.
|
| (2) Should a manager keep doing what their team does? Probably
| not. I can actually do most of what my team does faster and
| better, but they need to learn to do it. I don't scale. I can
| mentor them, and if there's a need for more resource I can get it
| for them.
|
| Edit: I do actually still write code - but just in my own time
| because I enjoy it.
| 2OEH8eoCRo0 wrote:
| Yes but only a little.
|
| I think managers are often out of touch with what the team puts
| up with.
| pklausler wrote:
| If they're directly managing coders, then they absolutely _must_
| be able to build, tweak, and run their product by themselves, and
| articulate the reasoning behind its design decisions.
| tommykins wrote:
| I don't code much anymore, the vast majority is reviews the only
| time I really need to get on the tools is if it's a concept that
| I need to teach someone, or more likely, something has gone quite
| badly wrong and it's 2100 and I don't feel like waking anyone.
| tschellenbach wrote:
| Yes, managers not coding was caused by ZIRP. It's a dumb idea.
|
| - You need to understand the work to evaluate your team
|
| - You need to understand the work to prioritize and rank what's
| important
|
| - You need to understand the work to know which roles to hire for
|
| - Good developers typically don't want to have a non-technical
| engineering manager
|
| - The budget for a non-contributing team member reduces your
| budget for engineers
|
| - It creates a more hierarchical and less flat org chart, which
| creates communication scaling challenges
|
| I would only consider non-technical managers for companies with
| large budgets and a non-technical product. Not only should they
| be technical, they should be excellent.
| iancmceachern wrote:
| Yes, if you can't measure it you can't manage it
| etamponi wrote:
| No. The amount of work that a manager has to handle to do their
| job right is incompatible with coding at a professional rate. If
| you have a manager that codes, then they won't have (enough) time
| to:
|
| - Write and design your packets (if in a corporation), or your
| career path (if in a smaller company)
|
| - Align with other teams, get consensus, shield you from politics
| beyond your level.
|
| - Make long term planning and making sure your team and
| neighboring teams follow it.
|
| - Listen to you and your colleagues and handle conflicts.
|
| EDIT: forgive me for not read TFA first. I won't change my
| comment as it aligns very well to the article. I still think that
| the answer to the "should code" question is no, not maybe...
| Let's not try to make overload and overcomplicate what "coding"
| means.
| option wrote:
| I am a manger and the best I can do is occasionally fix minor
| bugs and improve public docs. I feel like doing that is very
| important to better "stay in touch" with the product.
| etamponi wrote:
| Kudos for that! And lucky :) I think we agree that no much
| time is left a part from minor bug fixes :)
| mrinterweb wrote:
| I've seen manager calendars, and their days are packed with
| meetings. Expecting them to do in depth code reviews, pairing,
| is unrealistic.
|
| I think eng managers should rely on their ICs to inform them of
| what is going on, and the manager should be the advocate for IC
| dev needs. Devs should be able to tell their manager what the
| pain points are engineering is experiencing and the manager
| should advocate on behalf of their team.
| jtonz wrote:
| It has been interesting what both groups of 'yes' and 'no'
| chime in here. Personally I am on the side of 'no' but for a
| rather simple reason. I ask myself the following question:
|
| Why spend time being good at something you don't care about
| being good at any more?
|
| It is purely a personality thing however for me I would like to
| continue moving up the career ladder and you rarely see CTOs,
| VpEng rolling up their sleeves and sifting through CloudWatch
| logs. I want my focus to be on working the skills associated
| with those roles.
|
| As a people manager that works with many incredibly capable
| engineers that are aspiring to be managers, I share with them
| this advice, 'excellent engineers compound their value by
| making other engineers excellent. It's far more difficult to do
| that when you are writing code.'
| bastardoperator wrote:
| Depends, I always took a sprint task, certainly less than the
| team itself, but how do I design a career path if I'm
| blissfully unaware of the work that is being done? How do I
| plan long term if I don't understand the technical complexity
| of the problems being faced? Why would I waste time on conflict
| resolution when I can spend time enabling and building people?
| You want to argue about your colleague, or make do you want to
| advance and make more money?
| bradlys wrote:
| I find a good manager treats me like a peer and not some
| superior. Part of that is being in the trenches and having
| experience with what I'm working on. Maybe they're not taking on
| entire features anymore or doing the same level of code review as
| others but I think for a manager who manages ICs - they should be
| much closer to the code. Maybe this would be the "team lead" in
| some companies or a supervisor type role but I think I prefer
| that kind of person to be my actual manager than some other
| nebulous person who doesn't even interact with me on a daily
| basis.
|
| A big problem I had with some managers who didn't code was that
| they sometimes had wild expectations. They were also not good
| mentors. They couldn't really teach you much of anything because
| their job was so distinctly different from what you were doing.
| ranger207 wrote:
| "Administration" and "technical leadership" are two different
| skill and task sets, and it's a shame they're conflated into one
| position
| pphysch wrote:
| They are not that different.
|
| Conway's Law is real.
|
| Great engineers are not just "pure programmers", they
| understand the scale and organization of their domain. Similar
| for managers.
|
| In joking terms, the 8th OSI layer is "money/politics".
| ChrisMarshallNY wrote:
| I found that coding was important, as it helped me to connect
| better with my employees, and their challenges.
|
| I also found that I could _never_ schedule myself into the
| critical path. Most of my coding was open-source stuff, on my own
| time.
| notepad0x90 wrote:
| Big no! from me.
|
| Anyone in a people leadership role has to have a political
| mindset. You simply cannot be technically oriented and
| politically oriented at the same time. This is not a negative,
| the human brain, generally speaking, can't focus on two unrelated
| priorities at the same time.
|
| I have had a highly negative experience over this. When resolving
| technical conflicts, you expect technical merit and reasoning to
| be used. But managers who also meddle in technical affairs use
| political leverage and tactics to see their desired technical
| outcome. This is a very unpleasant and toxic affair overall.
|
| Imagine trying to solve a bug, but your manager wants a specific
| work around implemented which will result in bigger problems down
| the road. If you disagree with your manager, your performance
| review will suffer, you will be called disagreeable, hard to work
| with,etc.. You are only considering the best course of action
| from a technical perspective. Your technical peers can also
| review your code and reasoning and you can debate in a civilized
| manner over the technical merits of the issue. But as soon as a
| manger is involved, things will get toxic fast. It is nearly
| impossible to avoid micromanagement as well.
|
| Especially if the manager really knows what they're talking
| about. Then they'll really be looking over everyone's shoulders
| and causing drama.
|
| It is such a disorienting thing, having to fight political drama
| over simple and straightforward matters. This is how I learned
| what gaslighting is! I would be reaching out to people I consider
| a lot smarter than myself, asking their opinion on the subject
| (and they'd mostly agree with me), because I legitimately got
| disoriented and doubted everything I knew.
|
| I really hope none of you experience this. At least when someone
| is being mean/toxic for other reasons you can explain it away,
| but when they use their technical expertise, that's a whole new
| level.
|
| The whole concept of your management trusting you with the
| details and expecting you to show result goes out the window this
| way.
| __erik wrote:
| People never discuss company size along with this question.
|
| If you're at a giant company, the answer is likely no, there's
| enough politicing and paperwork where the highest impact thing to
| be done by a manager is likely not coding.
|
| If you're at a startup / smaller more nimble org in a big
| company, the answer is likely yes, if you've gotten to the point
| where you're a manager, in theory you're a very good engineer and
| you should spend your time coding, but on things that aren't on
| critical path. Bug backlog, experimental things with no hard
| deadlines, proof of concepts, all of these are valuable things.
| Leading from the front is also just generally good with smaller
| groups.
|
| Also under discussed by people having these debates (typically
| managers), is not acknowledging how bad most managers are at
| coding, especially if their job hasn't required them to code in a
| while. I see all the time that managers look for any excuse not
| to code, because it would reveal to their team that they're at
| best an L4 level coder after being in management for 5-10 years.
| tschellenbach wrote:
| Keep in mind that many companies don't do non-coding engineering
| leaders anymore. So from a career perspective, if you take a role
| that's non-coding, you are making yourself unemployable for large
| parts of small - medium sized companies, as well as larger
| companies that don't do this.
| spicymaki wrote:
| Reading these arguments are funny to me. By now there should be
| decades worth of research on this topic, all we seem to do is
| give anecdote after anecdote with no conclusion.
|
| Either no is doing this research or no one trusts the
| conclusions.
|
| Other topics like this are WFH or RTO, 4 day WW or 6 day WW. We
| as a profession seem to never come to a consensus.
| zabzonk wrote:
| If you can't code, you should not be managing programmers. How
| much code you write will obviously depend on circumstances.
___________________________________________________________________
(page generated 2025-03-04 23:00 UTC)