4 ms·

No. (Normal yes, OK No) A longtime ago I had 40 developers under me and frankly hated it. Went and got a contract as an individual contributor, wrote some FO

No. (Normal yes, OK No) A longtime ago I had 40 developers under me and frankly hated it. Went and got a contract as an individual contributor, wrote some FOSS found I was happier. Every few years I have to decide between the no coding daily route and the coding daily route. It frustrates me that there has to be a choice. Let me explain. I am (honest) writing a book about software literacy where I conjecture that software is a new form of literacy unlike the other analogies like driving a car is a lifelong skill and importantly will force society into massive meaningful change. So let's rephrase the question : "I used to write English everyday, but now I am going to become an executive and will stop writing English and instead set guidelines for other people to write English" It's not you. It's that we (all) work for software illiterate organisations. Getting promoted should not mean stopping writing code. It should be part of a natural day to day work. Why is it ok that an executive should spend a day buried in a spreadsheet but not buried in pandas code? At a certain point the whole organisation should push to the CEOs repo. At that sort of level I can imagine they won't write production code, but they should damn well read it, approve it and write their own for their own (executive) purposes You won't fix this. But fight back against it. Somewhere there is a project at your company that presents important data in a web form, and maybe has a download in excel button, but has no API, and worse only allows downloads by human SSO not machine tokens. Every time you can make "programmatic access" a first class citizen. It's a start. Others may think of other ways to start

tdeck 5y ago
I disagree here as someone who writes code for a living. In my experience, managers who write code often do so at the expense of something that's a more important part of their job that they don't want to be doing. Many managers are promoted engineers who feel more comfortable with code than people management. So when they don't want to hold 1:1s, don't want to deal with an interpersonal problem on the team, don't feel comfortable escalating an issue to management, etc... they instead pick up tickets and start writing code as a way to kind of procrastinate. This is bad because the organizational structure is such that the manager is often much better equipped to deal with such issues than the dev team, so they can go unaddressed.
- lifeisstillgood 5y ago
  I agree that a "manager" doing the work of one of their "employees" is clearly wrong. What I am trying (badly) to convey is that we should build software-driven organisations - where the processes and policies, the back-office if you like, is software driven and so if you "the executive" want to chnage the company you do it through explicitly changing the code.
  - pjbeam 5y ago
    That's a cool idea but I think something important is lost without that human "fudge factor" so to speak. I do a lot of things for my team that maybe aren't explicated in policy or would be very difficult to legislate through code related to morale and fending off burnout. Humans need wiggle room, for lack of a better word. Robots don't make all things better.
    - lifeisstillgood 5y ago
      We have the same idea in human society - we have very explicit criminal laws abs the jury system to handle the fudge factor. The difference here is openness. What your argument means to me is a need for democracy and openness in companies.
- nine_zeros 5y ago
  I agree. Managers (especially higher they go) should get out of production code. That said, they should be technically very skilled to be able to make tough calls, people and technical. Companies should have two ladders. IC ladder and management ladder. Where companies fail is that they make the IC ladder less about actual work and more about documents, RFCs and 1-pagers and other nonsense. They start measuring productivity by these docs instead of actually building something, thus setting perverse incentives for a promotion. Docs, RFCs, designs are all means to an end, not an end unto itself.
- heisenbit 5y ago
  Imagine a bad manager spending 30% of the time coding. Now imagine the same manager giving up coding, investing the 30% in making more bad decisions. And don't expect things going better but expect them getting worse due to total lack of grounding in facts and loosing his technical network to back him up.
jedimastert 5y ago
I think your issues are orthogonal. The issue is certainly not specific to computer science. Heck, there's even a small monolouge about it from William Shatner in Star Trek Generations[0]. The more responsibility you have, the more there is to do, the more you have to delegate because you can't do it yourself. That being said, I don't think it's wrong to step back and look at the bigger picture. Just because it's not for you doesn't mean there aren't people who love it, or even prefer it! After all, coding is just a tool. A very finely set tool, but just a tool and nothing more. Then again, you can have situations like Linux, where Linus still looks at every bit that comes into the kernel, so who knows. [0]: https://www.youtube.com/watch?v=r2mC4k9Rghs?t=2m04s https://www.youtube.com/watch?v=r2mC4k9Rghs?t=2m04s
rmk 5y ago
This is a poor analogy. Writing code is a technical discipline or a craft, as is technical writing. "Writing English" is not, for any place where English is the business language. From there, the analogy breaks down. If you want a better analogy, it's like the distinction between a reporter vs a newspaper editor. If you make someone who's never been a reporter a newspaper editor, you will likely fare disastrously. But insisting that the newspaper editor should cover a beat? It's just not the same job, so it's doubtful whether that's a good use of the editor's time. The editor is concerned with what is covered, what is being followed up on, and such. If the CEO is spending a day buried in spreadsheets, then he's likely spending time the wrong way, or is operating a very small business where he can afford to do such things. Again, the idea of "pushing to the CEOs repo" is actually crazy for all but the smallest shops. There should be no "CEO's repo". There should be "org x" repo or "product y" repo. I agree with your sentiment that a working knowledge of programming should become something like a working knowledge of Arithmetic. Every educated person is expected to know basic addition, multiplication and so on, and also be able to use a calculator to perform these tasks. Similarly, every person should be taught the concept of a Von Neumann computer and writing programs in a simple programming language. However, building software product vs. writing a basic computer program are, again, two very different things.
- lifeisstillgood 5y ago
  >>> Writing English" is not Honestly writing English is a technical craft. It's just one that 99% of the country has been practising this craft daily since age two. There is literally nothing else we are all so well trained at. Maybe washing?

tdeck 5y ago

I disagree here as someone who writes code for a living. In my experience, managers who write code often do so at the expense of something that's a more important part of their job that they don't want to be doing. Many managers are promoted engineers who feel more comfortable with code than people management. So when they don't want to hold 1:1s, don't want to deal with an interpersonal problem on the team, don't feel comfortable escalating an issue to management, etc... they instead pick up tickets and start writing code as a way to kind of procrastinate. This is bad because the organizational structure is such that the manager is often much better equipped to deal with such issues than the dev team, so they can go unaddressed.

lifeisstillgood 5y ago
I agree that a "manager" doing the work of one of their "employees" is clearly wrong. What I am trying (badly) to convey is that we should build software-driven organisations - where the processes and policies, the back-office if you like, is software driven and so if you "the executive" want to chnage the company you do it through explicitly changing the code.
- pjbeam 5y ago
  That's a cool idea but I think something important is lost without that human "fudge factor" so to speak. I do a lot of things for my team that maybe aren't explicated in policy or would be very difficult to legislate through code related to morale and fending off burnout. Humans need wiggle room, for lack of a better word. Robots don't make all things better.
  - lifeisstillgood 5y ago
    We have the same idea in human society - we have very explicit criminal laws abs the jury system to handle the fudge factor. The difference here is openness. What your argument means to me is a need for democracy and openness in companies.
nine_zeros 5y ago
I agree. Managers (especially higher they go) should get out of production code. That said, they should be technically very skilled to be able to make tough calls, people and technical. Companies should have two ladders. IC ladder and management ladder. Where companies fail is that they make the IC ladder less about actual work and more about documents, RFCs and 1-pagers and other nonsense. They start measuring productivity by these docs instead of actually building something, thus setting perverse incentives for a promotion. Docs, RFCs, designs are all means to an end, not an end unto itself.
heisenbit 5y ago
Imagine a bad manager spending 30% of the time coding. Now imagine the same manager giving up coding, investing the 30% in making more bad decisions. And don't expect things going better but expect them getting worse due to total lack of grounding in facts and loosing his technical network to back him up.

jedimastert 5y ago

I think your issues are orthogonal. The issue is certainly not specific to computer science. Heck, there's even a small monolouge about it from William Shatner in Star Trek Generations[0]. The more responsibility you have, the more there is to do, the more you have to delegate because you can't do it yourself. That being said, I don't think it's wrong to step back and look at the bigger picture. Just because it's not for you doesn't mean there aren't people who love it, or even prefer it! After all, coding is just a tool. A very finely set tool, but just a tool and nothing more. Then again, you can have situations like Linux, where Linus still looks at every bit that comes into the kernel, so who knows. [0]: https://www.youtube.com/watch?v=r2mC4k9Rghs?t=2m04s https://www.youtube.com/watch?v=r2mC4k9Rghs?t=2m04s

rmk 5y ago

This is a poor analogy. Writing code is a technical discipline or a craft, as is technical writing. "Writing English" is not, for any place where English is the business language. From there, the analogy breaks down. If you want a better analogy, it's like the distinction between a reporter vs a newspaper editor. If you make someone who's never been a reporter a newspaper editor, you will likely fare disastrously. But insisting that the newspaper editor should cover a beat? It's just not the same job, so it's doubtful whether that's a good use of the editor's time. The editor is concerned with what is covered, what is being followed up on, and such. If the CEO is spending a day buried in spreadsheets, then he's likely spending time the wrong way, or is operating a very small business where he can afford to do such things. Again, the idea of "pushing to the CEOs repo" is actually crazy for all but the smallest shops. There should be no "CEO's repo". There should be "org x" repo or "product y" repo. I agree with your sentiment that a working knowledge of programming should become something like a working knowledge of Arithmetic. Every educated person is expected to know basic addition, multiplication and so on, and also be able to use a calculator to perform these tasks. Similarly, every person should be taught the concept of a Von Neumann computer and writing programs in a simple programming language. However, building software product vs. writing a basic computer program are, again, two very different things.

lifeisstillgood 5y ago
>>> Writing English" is not Honestly writing English is a technical craft. It's just one that 99% of the country has been practising this craft daily since age two. There is literally nothing else we are all so well trained at. Maybe washing?