7 ms·

Thank you. Agreed completely I see software as a form of literacy, and it both amuses and saddens me to hear things like "I used to write code, but since I mo

Thank you. Agreed completely I see software as a form of literacy, and it both amuses and saddens me to hear things like "I used to write code, but since I moved to management I have stopped" We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" It seems sad to note that this "move to management" is now also becoming the "move to senior engineering". This indicates to me some problem with job title inflation - like there are not enough manager slots so the management layer is moving down a rung to senior engineer. Edit: of course Linus Torvalds wrote more emails than code. Which tends to indicate something.

urthor 4y ago
Moving senior engineers into management is the smart thing sadly. My experience with F500 companies, doing anything causes an incredible amount of grief. The most productive thing for seniors IS stopping coding. Going to meetings is the only way to deploy ANY code to production. The problem isn't even software. The problem is "new software" represents change.
- ozim 4y ago
  Sadly it is a smart thing. But not only to get any code to prod. From my perspective it is to stop loads of stupid code/stupid solutions even way before it is written down as a task on your favorite task tracking tool. That is what meetings are for as well.
  - marcosdumay 4y ago
    You seem to be arguing into promoting seniors into architects. The GP is arguing into promoting them to management. If the one hard problem your place has is organizing all the easy problems so they add to each other, turning your seniors into architects makes a lot of sense. And that's a very common situation. But the GP's motivation for moving them into management is basically that the organization is dysfunctional. That's not a good reason, although it may be the only thing you can do.
    - ozim 4y ago
      I am mostly thinking about technical team lead role which is not an architect and not managerial role. Team lead does not have time to code most of the time but does code reviews and attends meetings with architects and others and works on aligning stars so things happen. Then also has to stop stupid ideas or propose how to better solve a problem for a customer. But as I read GP post again it seems he might mean actual management.
      - urthor 4y ago
        I'm unfamiliar with the term GP. However, what you've said is exactly right. A tech lead codes less, but they directly contribute to producing the engineering artifact. They are an "actual contributor with direct responsibility." However, all meetings that the tech lead has with people OUTSIDE the team, is communication overhead to be minimized. So a tech lead combines code review, external communication, and direct work on the engineering artifact. Communication overhead is the problem. Architects, people managers, are all overhead roles. They don't "actually contribute" to the product. The more strictly define it, it's not actually about the "fulltime role." Maybe the senior engineer doesn't change their job title, but their schedule becomes less about coding, more about communicating. It's about minimizing the amount of external communication that needs to take place per code deployment.
        lifeisstillgood 4y ago
        might i suggest it's automating the communication (tests, other)
    - urthor 4y ago
      Management and architecture roles are essentially interchangeable. "People who go to meetings and don't directly contribute to the product." Aka communication overhead. I don't think it's about job titles. It's simply that, senior engineers who COULD do direct work on the product, instead devote time to communication overhead.
usrn 4y ago
>We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" Lots of people say they stopped reading books after highschool. It's also sad.
grog454 4y ago
> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" Maybe we do. Wouldn't a better analogy be professional writers moving toward an editor/director role?
- JackMorgan 4y ago
  You're right! An editor probably reads more than all their authors combined, and provides feedback on what isn't up to standard. My engineering managers were expected to do the same. An engineering manager who does not read all the code and PRs is as helpless as an editor who cannot read. They cannot know who is performing well, who needs coaching, who is all talk but makes a mess, etc. The idea that engineering managers can be excellent but code illiterate keeps showing up, but makes no sense at all.
  - beckingz 4y ago
    The sentiment I've seen is that a great people manager who trusts their engineers despite not knowing much about software can still be an above average manager. Given that the median manager seems to be throughly mediocre, an above average manager even if they can't code or read code seems desirable.
    - kqr 4y ago
      I remember reading about an actual observational study on this -- I think on HBR -- and the conclusion was basically that managers that are technically skilled have much happier employees on average. Another finding from the same study was that the statements "I feel like my manager can do my job" and "I am not looking for new work" were strongly correlated. (This sounds like the same thing but isn't.) In other words, you have to be one he'll of a people person to make up for cards stacked against you.
      - icedchai 4y ago
        I think either end of the spectrum is fine: highly skilled / can do your job if needed, or not technically skilled at all / honest about it / tracks schedule / delegates all technical authority. The messy middle is where the problems happen.
cupofpython 4y ago
"I used to lay bricks and now im a general contractor"
- MathMonkeyMan 4y ago
  thank you
overgrownzygote 4y ago
> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" I had to chuckle a bit at this one given how some VP+ folks write emails.
camjohnson26 4y ago
I see it more as leverage, the senior who understands good coding style and performance implications is far more useful when they can drive decisions across the whole codebase, instead of narrowly on one small feature. I’ll still take small features occasionally, but it’s more of a way to show juniors best practices so that they can improve the code they write, which is a win win for everyone.
corrral 4y ago
Consider the manager who tries to put in a couple hours a week helping with filing (as in, organizing paper files). Let's say the filing system is very busy and constantly evolving to meet new needs. Odds are they're just going to mess things up and annoy the people who do it as a major component of their job. Now, it may still be worth it, to keep the manager somewhat aware of how workers are doing their jobs, but it's not going to be helpful. You need literacy to work on filing, as you need programming ability to do software development, but in either case it's not sufficient. If you're just dipping in here and there, you'll likely be screwing things up more than you're helping. There's too much context required. Reading, writing, and programming may be forms of literacy, but if you try to jump in with tiny and inconsistent efforts to help someone write a novel—and I mean the actual writing, not helping them with organization or sales or something—you're probably doing more harm than good. Collaboration is possible even on novel-writing, of course, but very part-time efforts aren't likely to improve anything. Programming is the same, and that's why once someone gets past about half-coding-half-managing it gets harder to keep helping with the coding, productively. It's not about literacy—the person trying to help with an hour or two of novel-writing a week is literate, after all—it's about context.
- jghn 4y ago
  Exactly. I've been a manager for a while and don't do much day to day hands on keyboard coding. I'm still able to help, sometimes quite a bit, but it depends on what the problem is. If someone on the team is struggling with the gnarly domain specific application logic portions, I will usually direct them to a more senior teammate. I'm more likely to add confusion than reduce it. I'm not in those weeds enough to know how things are changing on a day to day basis. I understand the broad strokes, the roadmap, and where the senior devs are taking things. But I might not be able to tell a dev what the gotchas of their idea really are. Where I find myself most effective is when I can leverage my experience as a developer in general. I can help them with pros and cons of technology X vs Y, pattern A vs B. I can point out things they might not have been aware of in terms of peculiarities of the tech stack and how it might change things - for instance bugs that are only clear if one understands the details of that standard library call. How to diagnose and debug a problem in an effective manner. How to research a problem. tl;dr I can and do still talk code and help out my team. But the further one gets from being able to rely on my general experience instead of being embroiled in their day to day back and forth, the less effective I am at it
BlargMcLarg 4y ago
I'd argue more people severely overestimate the need of communication quantity and management roles/responsibilities have inflated everything as a result. Worse, people who want to primarily talk are going to advocate for others to talk more. Regardless, whoever brings up what GP does is frequently bombarded with the old "communication important" or "soft skills matter" spiel in an attempt to validate the explosion of communicational requirements.
- jseban 4y ago
- kqr 4y ago
  Many big modern organisations are built by bureaucrats whose specialisation it is to create more bureaucracy. Thus they spend a lot of time thinking up ways to measure the work performed from various angles, create reports for their superiors, and find other ways to ride on the work of others to earn their salary instead of doing actual work. This propagates downward and soon everyone (but perhaps the most junior contributors) is working in politics about meta-work, rather than doing the actual work. It takes rebel managers to go "no, I won't participate in this seventh time allocation study" and instead do actual work to break the cycle.
  - jiggawatts 4y ago
    Precisely this. I've seen every size and type of organisation from single digit employee count up to tens of thousands in huge bureaucracies. Inevitably, the paperwork becomes the goal, and no amount of pleading with middle-managers will convince them that their job is unnecessary. If they were to believe us, they'd have to quit and become unemployed. Even in my relatively small consulting org I have to actively fight against the rising tide of overhead. Just recently I tried to explain to a manager that status reports are not the most important deliverable. That the actual product is, and reporting about it is secondary. They were aghast.
    - kqr 4y ago
silisili 4y ago
Good analogy. Imagine Swift writing a few ideas...guy sees land of giants, land of little people, add some pirates, etc and handing it off to some highschool kid to write! (I don't know why that's the first book to come to mind) In my career, my most rewarding, fun, but also frustrating times are being handed problems I don't know how to solve, even moreso when it seems nobody had tried to solve it before. Where would we be if people like Bellard just wrote general ideas, but never any code? Without ffmpeg and qemu, probably.
jseban 4y ago
I don't understand this, this is the way every hierarchy work, and how every single job/management role is functioning. It's to solve the problem of communication overhead growing exponentially with larger groups of people. Why does this make you sad? And is it better to have a dysfunctional organisation where people float in and out of poorly defined roles and everyone tries to do everything? Does that really make you more happy? I don't get this emotional take on specialisation.
- watwut 4y ago
  It is sad, because the hierarchy is not solving that problem, instead the problem is moving down the hierarchy.
- kqr 4y ago
  It is better to have a functional organisation where people float in and out of roles defined by the expectations of others and everyone is capable of judging basic business tradeoffs, yes. That, in my experience, makes people happier. They get to focus on important problems, help people they know, and develop their well-roundedness as human beings. I think you might be underestimating the amount of overhead that is added by a heavy bureaucratic hierarchy.
  - rocqua 4y ago
    That sounds incredibly amazing. Utopian. But I doubt it is possible even if all humans involved are incredible. You still need coordination.
    - jseban 4y ago
      Yeah this annoys me to no end how tech people pretend that they have casually invented peace on earth, and act like it's the most obvious thing in the world. "Of course large groups of people simply just get along perfectly and efficiently without any coordination" Yeah right. It's the people who are dysfunctional who thrive in these environments because they don't have to be accountable, so their issues just disappear, and people who actually function and take their job seriously will burn out and go insane in the chaos.
jackblemming 4y ago
“Code is a liability” “Don’t solve problems with code that can be solved in other ways” “Code is grunt work, I’m an architect” “Projects fail from people problems, not technical problems” There’s truth to all of these, and yet the people who repeat them dogmatically are often programmers or managers with ultra inflated titles who write blog posts or emails all day ;) They probably didn’t even like programming and saw it as a fast track to management. I’ll take the real programmers who get stuff done, thanks.
- ozim 4y ago
  If you get developers who get stuff done well - sales people have so many stupid ideas that implementing these would hurt my brain. Imagine implementing everything that pushy sales people throw at developers. I only agree that "code is a grunt work" is wrong simplification but picking out which code is really valuable to write is still in my opinion much more important than just slinging out code. My idea is that there is no "work smart or work hard" - first you have to make sure code to be written is valuable and then you work hard to code it.
- zelphirkalt 4y ago
  My impression as well. My thoughts then are usually something like the following questions: "Oh? Have you really sought out all the good resources and learned from them? Multiple different paradigms? Countless projects exploring ideas? Many different languages, learning their concepts? How come you stopped liking to code? What made you lose liking to make the computer do your bidding? Did you ever really like it? If you did not, did you really go all the way you were able to, in order to explore all the things? Do you really know as much as you claim to know? Or have you been 10 years in the same <you all know what lang here> mainstream OOP job and only feel like your time spent doing the same thing over and over again warants you a senior title and you should move on to management, because 'there is nothing more to explore'?" I do not usually ask these questions. I rather observe and might indirectly poke for some knowledge. When I do ask some of those questions, I usually get a reply like "Meh, programming language does not matter, it is all the same." -- The usual "I don't want to have to learn more." type of response. There are many variations of this response, for paradigms, concepts, programming languages, you name it. Usually there is some overly broad generalization in it, overloooking benefits, that one approach might have over another, because they never tried or learned that approach and have no experience with it. When I hear that kind of response then I know what I am dealing with. The person is free to show by their words and actions, that they actually _do_ have that knowledge. Otherwise I will just accept, that this person does not love coding the way I do and that they do not have a drive to go all the way of exploring so many different concepts and things. That's totally fine, coding might not be for them, or they might not like it to the same degree (and they do not have to), or they might not have been as lucky as I was and did get continuously in touch with new exciting things to learn about. Maybe they did get stuck in that <you all know what lang here> OOP drudge and did really not see anything new any longer. Whatever it is, I just hope people don't simply assume, that just because "they have been coding a in the past for x years", their experience is the same I have. I do not mean in experience quantity levels (years), there surely are many people longer in this hustle than me, but in individual experiences and concepts one gets in touch with, when exploring off the main road. There is so so much to explore and learn about. One can probably learn ones whole life and not have seen it all.
jacobolus 4y ago
> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" You surely would hear things like “I used to write research papers but since I moved to management I have stopped” or “I used to write fiction stories but since I moved to management I have stopped” or “I used to write legal briefs but since I moved to management I have stopped” etc. if you talked to people in fields where people’s focused work is writing.
- lifeisstillgood 4y ago
  "I used to write fiction stories.." yes but they have not stopped reading and writing english on the job. In fact I bet that reading and writing english is still the job. Things I think software management should be doing (besides fighting politics that again should not exist but does because corruption) - review of reviews (how is the code review process going, i'm on problems, common wins) - code analysis - hot spots, changing idioms, - keeping up with rest if company - what code issues / infrastructure / operational / metrics are coming, how do we adjust
jollybean 4y ago
Not sure if it's a fair analogy. A construction manager doesn't use hammers. The degree to which software is solving problems, your analogy is valid. The degree to which it's mechanical, I have a point. I'm managing a team right now that's making a simple mobile app. 100% off-the-shelf everything. There is not a single 'algorithm'. Flutter and Django by the book. With Django, the whole thing is a giant 'convention' - it's like, there is no 'code'. Just 'templates'. I can't communicate how much confidence this gives me. In the areas where the team has to make decisions ... that's where all the problems are. So for most of our activities, we design features, work out the UI, give it to the designer, review, and hand it off to the devs to actually 'do'. The code is mundane. This kind of scenario is quite common in software, perhaps more common than not.

urthor 4y ago

Moving senior engineers into management is the smart thing sadly. My experience with F500 companies, doing anything causes an incredible amount of grief. The most productive thing for seniors IS stopping coding. Going to meetings is the only way to deploy ANY code to production. The problem isn't even software. The problem is "new software" represents change.

ozim 4y ago
Sadly it is a smart thing. But not only to get any code to prod. From my perspective it is to stop loads of stupid code/stupid solutions even way before it is written down as a task on your favorite task tracking tool. That is what meetings are for as well.
- marcosdumay 4y ago
  You seem to be arguing into promoting seniors into architects. The GP is arguing into promoting them to management. If the one hard problem your place has is organizing all the easy problems so they add to each other, turning your seniors into architects makes a lot of sense. And that's a very common situation. But the GP's motivation for moving them into management is basically that the organization is dysfunctional. That's not a good reason, although it may be the only thing you can do.
  - ozim 4y ago
    I am mostly thinking about technical team lead role which is not an architect and not managerial role. Team lead does not have time to code most of the time but does code reviews and attends meetings with architects and others and works on aligning stars so things happen. Then also has to stop stupid ideas or propose how to better solve a problem for a customer. But as I read GP post again it seems he might mean actual management.
    - urthor 4y ago
      I'm unfamiliar with the term GP. However, what you've said is exactly right. A tech lead codes less, but they directly contribute to producing the engineering artifact. They are an "actual contributor with direct responsibility." However, all meetings that the tech lead has with people OUTSIDE the team, is communication overhead to be minimized. So a tech lead combines code review, external communication, and direct work on the engineering artifact. Communication overhead is the problem. Architects, people managers, are all overhead roles. They don't "actually contribute" to the product. The more strictly define it, it's not actually about the "fulltime role." Maybe the senior engineer doesn't change their job title, but their schedule becomes less about coding, more about communicating. It's about minimizing the amount of external communication that needs to take place per code deployment.
      - lifeisstillgood 4y ago
        might i suggest it's automating the communication (tests, other)
  - urthor 4y ago
    Management and architecture roles are essentially interchangeable. "People who go to meetings and don't directly contribute to the product." Aka communication overhead. I don't think it's about job titles. It's simply that, senior engineers who COULD do direct work on the product, instead devote time to communication overhead.

usrn 4y ago

>We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" Lots of people say they stopped reading books after highschool. It's also sad.

grog454 4y ago

> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" Maybe we do. Wouldn't a better analogy be professional writers moving toward an editor/director role?

JackMorgan 4y ago
You're right! An editor probably reads more than all their authors combined, and provides feedback on what isn't up to standard. My engineering managers were expected to do the same. An engineering manager who does not read all the code and PRs is as helpless as an editor who cannot read. They cannot know who is performing well, who needs coaching, who is all talk but makes a mess, etc. The idea that engineering managers can be excellent but code illiterate keeps showing up, but makes no sense at all.
- beckingz 4y ago
  The sentiment I've seen is that a great people manager who trusts their engineers despite not knowing much about software can still be an above average manager. Given that the median manager seems to be throughly mediocre, an above average manager even if they can't code or read code seems desirable.
  - kqr 4y ago
    I remember reading about an actual observational study on this -- I think on HBR -- and the conclusion was basically that managers that are technically skilled have much happier employees on average. Another finding from the same study was that the statements "I feel like my manager can do my job" and "I am not looking for new work" were strongly correlated. (This sounds like the same thing but isn't.) In other words, you have to be one he'll of a people person to make up for cards stacked against you.
    - icedchai 4y ago
      I think either end of the spectrum is fine: highly skilled / can do your job if needed, or not technically skilled at all / honest about it / tracks schedule / delegates all technical authority. The messy middle is where the problems happen.

cupofpython 4y ago

"I used to lay bricks and now im a general contractor"

MathMonkeyMan 4y ago
thank you

overgrownzygote 4y ago

> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" I had to chuckle a bit at this one given how some VP+ folks write emails.

camjohnson26 4y ago

I see it more as leverage, the senior who understands good coding style and performance implications is far more useful when they can drive decisions across the whole codebase, instead of narrowly on one small feature. I’ll still take small features occasionally, but it’s more of a way to show juniors best practices so that they can improve the code they write, which is a win win for everyone.

corrral 4y ago

Consider the manager who tries to put in a couple hours a week helping with filing (as in, organizing paper files). Let's say the filing system is very busy and constantly evolving to meet new needs. Odds are they're just going to mess things up and annoy the people who do it as a major component of their job. Now, it may still be worth it, to keep the manager somewhat aware of how workers are doing their jobs, but it's not going to be helpful. You need literacy to work on filing, as you need programming ability to do software development, but in either case it's not sufficient. If you're just dipping in here and there, you'll likely be screwing things up more than you're helping. There's too much context required. Reading, writing, and programming may be forms of literacy, but if you try to jump in with tiny and inconsistent efforts to help someone write a novel—and I mean the actual writing, not helping them with organization or sales or something—you're probably doing more harm than good. Collaboration is possible even on novel-writing, of course, but very part-time efforts aren't likely to improve anything. Programming is the same, and that's why once someone gets past about half-coding-half-managing it gets harder to keep helping with the coding, productively. It's not about literacy—the person trying to help with an hour or two of novel-writing a week is literate, after all—it's about context.

jghn 4y ago
Exactly. I've been a manager for a while and don't do much day to day hands on keyboard coding. I'm still able to help, sometimes quite a bit, but it depends on what the problem is. If someone on the team is struggling with the gnarly domain specific application logic portions, I will usually direct them to a more senior teammate. I'm more likely to add confusion than reduce it. I'm not in those weeds enough to know how things are changing on a day to day basis. I understand the broad strokes, the roadmap, and where the senior devs are taking things. But I might not be able to tell a dev what the gotchas of their idea really are. Where I find myself most effective is when I can leverage my experience as a developer in general. I can help them with pros and cons of technology X vs Y, pattern A vs B. I can point out things they might not have been aware of in terms of peculiarities of the tech stack and how it might change things - for instance bugs that are only clear if one understands the details of that standard library call. How to diagnose and debug a problem in an effective manner. How to research a problem. tl;dr I can and do still talk code and help out my team. But the further one gets from being able to rely on my general experience instead of being embroiled in their day to day back and forth, the less effective I am at it

BlargMcLarg 4y ago

I'd argue more people severely overestimate the need of communication quantity and management roles/responsibilities have inflated everything as a result. Worse, people who want to primarily talk are going to advocate for others to talk more. Regardless, whoever brings up what GP does is frequently bombarded with the old "communication important" or "soft skills matter" spiel in an attempt to validate the explosion of communicational requirements.

jseban 4y ago
kqr 4y ago
Many big modern organisations are built by bureaucrats whose specialisation it is to create more bureaucracy. Thus they spend a lot of time thinking up ways to measure the work performed from various angles, create reports for their superiors, and find other ways to ride on the work of others to earn their salary instead of doing actual work. This propagates downward and soon everyone (but perhaps the most junior contributors) is working in politics about meta-work, rather than doing the actual work. It takes rebel managers to go "no, I won't participate in this seventh time allocation study" and instead do actual work to break the cycle.
- jiggawatts 4y ago
  Precisely this. I've seen every size and type of organisation from single digit employee count up to tens of thousands in huge bureaucracies. Inevitably, the paperwork becomes the goal, and no amount of pleading with middle-managers will convince them that their job is unnecessary. If they were to believe us, they'd have to quit and become unemployed. Even in my relatively small consulting org I have to actively fight against the rising tide of overhead. Just recently I tried to explain to a manager that status reports are not the most important deliverable. That the actual product is, and reporting about it is secondary. They were aghast.
  - kqr 4y ago

silisili 4y ago

Good analogy. Imagine Swift writing a few ideas...guy sees land of giants, land of little people, add some pirates, etc and handing it off to some highschool kid to write! (I don't know why that's the first book to come to mind) In my career, my most rewarding, fun, but also frustrating times are being handed problems I don't know how to solve, even moreso when it seems nobody had tried to solve it before. Where would we be if people like Bellard just wrote general ideas, but never any code? Without ffmpeg and qemu, probably.

jseban 4y ago

I don't understand this, this is the way every hierarchy work, and how every single job/management role is functioning. It's to solve the problem of communication overhead growing exponentially with larger groups of people. Why does this make you sad? And is it better to have a dysfunctional organisation where people float in and out of poorly defined roles and everyone tries to do everything? Does that really make you more happy? I don't get this emotional take on specialisation.

watwut 4y ago
It is sad, because the hierarchy is not solving that problem, instead the problem is moving down the hierarchy.
kqr 4y ago
It is better to have a functional organisation where people float in and out of roles defined by the expectations of others and everyone is capable of judging basic business tradeoffs, yes. That, in my experience, makes people happier. They get to focus on important problems, help people they know, and develop their well-roundedness as human beings. I think you might be underestimating the amount of overhead that is added by a heavy bureaucratic hierarchy.
- rocqua 4y ago
  That sounds incredibly amazing. Utopian. But I doubt it is possible even if all humans involved are incredible. You still need coordination.
  - jseban 4y ago
    Yeah this annoys me to no end how tech people pretend that they have casually invented peace on earth, and act like it's the most obvious thing in the world. "Of course large groups of people simply just get along perfectly and efficiently without any coordination" Yeah right. It's the people who are dysfunctional who thrive in these environments because they don't have to be accountable, so their issues just disappear, and people who actually function and take their job seriously will burn out and go insane in the chaos.

jackblemming 4y ago

“Code is a liability” “Don’t solve problems with code that can be solved in other ways” “Code is grunt work, I’m an architect” “Projects fail from people problems, not technical problems” There’s truth to all of these, and yet the people who repeat them dogmatically are often programmers or managers with ultra inflated titles who write blog posts or emails all day ;) They probably didn’t even like programming and saw it as a fast track to management. I’ll take the real programmers who get stuff done, thanks.

ozim 4y ago
If you get developers who get stuff done well - sales people have so many stupid ideas that implementing these would hurt my brain. Imagine implementing everything that pushy sales people throw at developers. I only agree that "code is a grunt work" is wrong simplification but picking out which code is really valuable to write is still in my opinion much more important than just slinging out code. My idea is that there is no "work smart or work hard" - first you have to make sure code to be written is valuable and then you work hard to code it.
zelphirkalt 4y ago
My impression as well. My thoughts then are usually something like the following questions: "Oh? Have you really sought out all the good resources and learned from them? Multiple different paradigms? Countless projects exploring ideas? Many different languages, learning their concepts? How come you stopped liking to code? What made you lose liking to make the computer do your bidding? Did you ever really like it? If you did not, did you really go all the way you were able to, in order to explore all the things? Do you really know as much as you claim to know? Or have you been 10 years in the same <you all know what lang here> mainstream OOP job and only feel like your time spent doing the same thing over and over again warants you a senior title and you should move on to management, because 'there is nothing more to explore'?" I do not usually ask these questions. I rather observe and might indirectly poke for some knowledge. When I do ask some of those questions, I usually get a reply like "Meh, programming language does not matter, it is all the same." -- The usual "I don't want to have to learn more." type of response. There are many variations of this response, for paradigms, concepts, programming languages, you name it. Usually there is some overly broad generalization in it, overloooking benefits, that one approach might have over another, because they never tried or learned that approach and have no experience with it. When I hear that kind of response then I know what I am dealing with. The person is free to show by their words and actions, that they actually _do_ have that knowledge. Otherwise I will just accept, that this person does not love coding the way I do and that they do not have a drive to go all the way of exploring so many different concepts and things. That's totally fine, coding might not be for them, or they might not like it to the same degree (and they do not have to), or they might not have been as lucky as I was and did get continuously in touch with new exciting things to learn about. Maybe they did get stuck in that <you all know what lang here> OOP drudge and did really not see anything new any longer. Whatever it is, I just hope people don't simply assume, that just because "they have been coding a in the past for x years", their experience is the same I have. I do not mean in experience quantity levels (years), there surely are many people longer in this hustle than me, but in individual experiences and concepts one gets in touch with, when exploring off the main road. There is so so much to explore and learn about. One can probably learn ones whole life and not have seen it all.

jacobolus 4y ago

> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" You surely would hear things like “I used to write research papers but since I moved to management I have stopped” or “I used to write fiction stories but since I moved to management I have stopped” or “I used to write legal briefs but since I moved to management I have stopped” etc. if you talked to people in fields where people’s focused work is writing.

lifeisstillgood 4y ago
"I used to write fiction stories.." yes but they have not stopped reading and writing english on the job. In fact I bet that reading and writing english is still the job. Things I think software management should be doing (besides fighting politics that again should not exist but does because corruption) - review of reviews (how is the code review process going, i'm on problems, common wins) - code analysis - hot spots, changing idioms, - keeping up with rest if company - what code issues / infrastructure / operational / metrics are coming, how do we adjust

jollybean 4y ago

Not sure if it's a fair analogy. A construction manager doesn't use hammers. The degree to which software is solving problems, your analogy is valid. The degree to which it's mechanical, I have a point. I'm managing a team right now that's making a simple mobile app. 100% off-the-shelf everything. There is not a single 'algorithm'. Flutter and Django by the book. With Django, the whole thing is a giant 'convention' - it's like, there is no 'code'. Just 'templates'. I can't communicate how much confidence this gives me. In the areas where the team has to make decisions ... that's where all the problems are. So for most of our activities, we design features, work out the UI, give it to the designer, review, and hand it off to the devs to actually 'do'. The code is mundane. This kind of scenario is quite common in software, perhaps more common than not.