[ActionHank]

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]

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.

[ActionHank]

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]

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.

[jrs235]

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.

[ActionHank]

Wild that you think devs read docs.

[poincaredisk]

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.

[warkdarrior]

> 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.

[yihtserns]

"...combine SDK A with library B, then plug in component C and connect to service D..." is "really like routine factory work"?..

What kind of "routine factory work" you've been doing?

[nine_zeros]

> 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]

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.

[Clubber]

He's role playing the manager role in the article, hopefully sarcastically.

[poincaredisk]

How does "fixing a tough bug for a week" fit into the factory analogy? What about "designing a new feature by drawing abstract diagrams"? These are examples taken from the beginning of the article.

[ActionHank]

If this is the type of work you are doing, your job is 100% going to be replaced by AI.

[atoav]

This is naivity on "cryptobro"-levels.

If security, reliability, performance and maintainability matter (and they do, always) you need to plan your software to be data-centric. I don't see how plugging together a few libraries solve that for you. Btw: external libraries are written by developers as well. And your developers have to not only read that code and documentation, but consider each of those a liability and a future maintenance issue. Most software engineering isn't bolting libraries together, most software engineering is about knowing how data is stored, how it is flowing, how much risk is involved with using which dependencies, who has access to what if they exploit any given section of code, and much, much more. That is why only morons think no-code tools can replace capable developers: the hard bit isn't writing the abstract cryptic text — that is in fact the easy bit — the hard bit is not shooting yourself into the foot as the complexity grows and finding a solution where all the above mentioned qualities are not in conflict with each other.

Do you work in marketing? Cause your stance would make me think your shop is a bottom-of-the-barrel bordering-to-fraud el-cheapo software house that customers instantly regret to having worked with. This is at one level with the infamous "my teenage kid can do graphic design" — which tells you more about what that person thinks about graphic design than about graphic design itself. If you are a manager you'd be wise to realize a serious software project yourself at home, this might teach you a thing or two.

[OutOfHere]

says the person who never devised a clever algorithm in his life