3 ms·

This resonates so hard with me. Reading the article I was agasp at the lunacy. "Prove your worth", "Publish your notes", these are the ravings of someone who h

This resonates so hard with me. Reading the article I was agasp at the lunacy. "Prove your worth", "Publish your notes", these are the ravings of someone who has convinced themselves that it is ok for someone who has no idea what you do or how anything works to determine the value of your contribution. I have for the longest time believed that you shouldn't be "working in tech" if you never "worked in tech". Before I'm accused of being exclusionary or elitist, I mean that you should build something or at the very least have studied in the field. Knowing how to run a factory does not mean you know how to run a tech company. Treating devs like they are on a production line building cars is backward toilet sitting behaviour.

krapp 2y ago
It is OK. That's the system. That's how capitalist hierarchies work, at just about every company, everywhere. You're an asset. Even if you make six figures, get catered lunches and unlimited PTO, you're a cog in someone else's money machine. Everybody complains that their managers don't understand how their jobs actually work. There's no reason why tech should be unique in this regard.
- poincaredisk 2y ago
  I don't feel like a cog in a money making machine. Maybe because my company doesn't earn any money (I work in public sector, improving IT security in my country and doing R&D). There are other options than corporations. Another way out is making your own company, of course.
- ActionHank 2y ago
  Yes and no. The key point is that if you do work for a week to track down a showstopper only to have that thrown in your face and the only reasonable response is to "cover your ass" you are doubling your work. That manager should be fired for halving the productivity of their devs.
  - fgeiger 2y ago
    The main point of the article is that by "covering your ass" you are actually becoming a better developer, because the prose you write is plans and documentation and gives your thoughts structure. Hence, your personal productivity (measured by what metric?) might suffer for this one task. However, in the long run you and your team gain productivity because of existing explicit documentation and plans.
    - ActionHank 2y ago
      Wild that you think devs read docs.
    - jrs235 2y ago
      A lot of plans and thinking goes into how to transition from the old to the new. Valuable for the "brief" period of transition but generally worth less once complete. This also doubles the time to deliver. Additionally, many times research and code analysis/review is needed to flesh out what needs to be done. Often times it's faster to make the changes when discovered rather than having to document what needs to be changed then getting the go ahead to change it. ("What did I change?" It's in the code commits and repo! Why do I need to translate it to English? Oh because my boss can't do my job...) This can drastically reduce delivery time. "What if there's a bug?!" What if there is a bug. We'll deal with it.
warkdarrior 2y ago
> Treating devs like they are on a production line building cars is backward toilet sitting behaviour. Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such.
- OutOfHere 2y ago
  says the person who never devised a clever algorithm in his life
- nine_zeros 2y ago
  > Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such. Citation needed.
  - RHSeeger 2y ago
    This was my first thought. I don't think I've ever worked in anything "ground breaking", but I've never had work that was just "connect A to B with no thought". I mean, even if it _is_ connect A to B, you still need to consider - Is the client (internal, external, whatever) asking for what they really want? - Is the client asking for what they really need? - Am I correctly understanding what the client is asking for? - Does building this make sense for the product as a whole? - What As and Bs can accomplish what I'm looking for (assumes they exist, per the initial assumption) - Of those As and Bs, which ones won't run into conflicts with the project - Of those As and Bs, which ones are well supported - Of those As and Bs, which ones are likely to continue to be supported (long enough for our needs) - Of those As and Bs, which ones mesh well with the current coding/development style of the project (maintainability) - How can I best use A and B in a way that is easy to understand (maintainability) - How can I best use A and B in a way that I can test my code without having to write 1000 lines of mock (maintainability) - and the list goes on and on and on Unless you're a VERY low level developer, most software development requires a large amount of thought, both analysis and planning. It is very much _not_ like routine factory work. Heck, I spend a fair amount of my day not even looking at my screen, as I ponder how best to solve "easy" problems.

krapp 2y ago

It is OK. That's the system. That's how capitalist hierarchies work, at just about every company, everywhere. You're an asset. Even if you make six figures, get catered lunches and unlimited PTO, you're a cog in someone else's money machine. Everybody complains that their managers don't understand how their jobs actually work. There's no reason why tech should be unique in this regard.

poincaredisk 2y ago
I don't feel like a cog in a money making machine. Maybe because my company doesn't earn any money (I work in public sector, improving IT security in my country and doing R&D). There are other options than corporations. Another way out is making your own company, of course.
ActionHank 2y ago
Yes and no. The key point is that if you do work for a week to track down a showstopper only to have that thrown in your face and the only reasonable response is to "cover your ass" you are doubling your work. That manager should be fired for halving the productivity of their devs.
- fgeiger 2y ago
  The main point of the article is that by "covering your ass" you are actually becoming a better developer, because the prose you write is plans and documentation and gives your thoughts structure. Hence, your personal productivity (measured by what metric?) might suffer for this one task. However, in the long run you and your team gain productivity because of existing explicit documentation and plans.
  - ActionHank 2y ago
    Wild that you think devs read docs.
  - jrs235 2y ago
    A lot of plans and thinking goes into how to transition from the old to the new. Valuable for the "brief" period of transition but generally worth less once complete. This also doubles the time to deliver. Additionally, many times research and code analysis/review is needed to flesh out what needs to be done. Often times it's faster to make the changes when discovered rather than having to document what needs to be changed then getting the go ahead to change it. ("What did I change?" It's in the code commits and repo! Why do I need to translate it to English? Oh because my boss can't do my job...) This can drastically reduce delivery time. "What if there's a bug?!" What if there is a bug. We'll deal with it.

warkdarrior 2y ago

> Treating devs like they are on a production line building cars is backward toilet sitting behaviour. Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such.

OutOfHere 2y ago
says the person who never devised a clever algorithm in his life
nine_zeros 2y ago
> Citation needed. At this point in time, unless you are doing groundbreaking work writing/using new software, most software engineering is really like routine factory work ("combine SDK A with library B, then plug in component C and connect to service D") and should be measured as such. Citation needed.
- RHSeeger 2y ago
  This was my first thought. I don't think I've ever worked in anything "ground breaking", but I've never had work that was just "connect A to B with no thought". I mean, even if it _is_ connect A to B, you still need to consider - Is the client (internal, external, whatever) asking for what they really want? - Is the client asking for what they really need? - Am I correctly understanding what the client is asking for? - Does building this make sense for the product as a whole? - What As and Bs can accomplish what I'm looking for (assumes they exist, per the initial assumption) - Of those As and Bs, which ones won't run into conflicts with the project - Of those As and Bs, which ones are well supported - Of those As and Bs, which ones are likely to continue to be supported (long enough for our needs) - Of those As and Bs, which ones mesh well with the current coding/development style of the project (maintainability) - How can I best use A and B in a way that is easy to understand (maintainability) - How can I best use A and B in a way that I can test my code without having to write 1000 lines of mock (maintainability) - and the list goes on and on and on Unless you're a VERY low level developer, most software development requires a large amount of thought, both analysis and planning. It is very much _not_ like routine factory work. Heck, I spend a fair amount of my day not even looking at my screen, as I ponder how best to solve "easy" problems.