[andrewla]

Your company has been captured. It's over -- if you are quietly competent you will either have your coworkers and technical managers create a shield around you or you will find yourself outcompeted by developers who spend all of their time creating proof of work instead of doing work, and creating heavily documented CRUD apps with predictable milestones rather than challenging work where the solution is not known.

Join them if you can; dumb down your work and focus on predictable things rather than interesting work. Try to move closer to a profit center instead of a cost center because you'll get proof in the pudding there. And start quietly sending out resumes.

If you have a good manager who understands your contribution and can deal with the politics and constant demands for progress reports from do-nothing middle managers who need to send progress reports to their managers then you can probably do well until they get pushed out.

[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

[thankyou102424]

I just wanted to say thank you. As I was reading this, I cringed at the thought of even coding in an environment like this. I would like to think of myself as an extremely productive programmer, I got lots of stuff done. Lots of things built. I code in sessions, 4+ hour blocks of focus. I at least get one good session done a day, sometimes I can do a few if I feel inspired. Some of my best sessions have been at 3AM after telling the computer to go fuck itself and banging my keyboard.

This code system (in article) for someone like me is hell - but I like to build stuff. I hate fixing bugs, etc. But in "maintenance mode" or "bug fixing mode" a system like this is kind of necessary.

"The simplest and probably most widespread metric used to measure developers is how many pull requests they’re merging."

I suppose it's good practice to "backup my work" at the end of the day - I mostly don't though. If I need to fine. But I mainly push to a repo when I want to demo live, or working with a dev and we need to share. Big teams with lots of moving pieces, pushing repos each day is necessary I suppose? Or is this just bad codebase architecture? ...Small teams are more effective IMHO on smaller "modular" codebases/microservices/components/modules...etc.

[jay_kyburz]

I don't think its unreasonable for somebody to be able to demonstrate they they worked the 8 hours they said they worked. Especially when a lot of the work is just "thinking".

Have you folks never worked with somebody who literally does nothing all day?

Have you folks ever paid programmers out of your own pocket?

I know agile is unpopular these days, but I've always liked daily stand-ups so I can describe what I "thought about" all day. What problems I faced. What was challenging about the design. What I discovered in my research.

Companies do have people who just burn out, get bored, or just stop working. How are you supposed to find those people if nobody ever has anything to show?

[andrewla]

Yes, we've all worked with people like that. They are easy to identify, regardless of what kind of metrics they throw out. All you have to do is use your subjective powers of observation, and have the courage to believe this instead of trying to justify it through metrics. If you are not able to do this then no amount of process or fake metrics is going to save your development team.

In particular, if you are measuring the number of hours people work as a way to measure productivity, then you are in deep, deep, deep shit.

[atoav]

Yeah I have worked with someone like that, but as someone who does actual work I don't see why because of that moron I have to document every step I am taking. Feel free to come in once a day and let me describe to you what I am doing, the rest is in the commit messages.

The guy I worked with was thrown out recently. Unless you work in complete isolation your peers know you are not doing your job, and once that pisses them off enough it will be more widely known.

[rstuart4133]

It's also comforting to remember not all managers are so short sighted. There is this purported quote from Henry Ford https://www.goodreads.com/quotes/6872338-henry-ford-s-reacti...

    Henry Ford’s reaction to a consultant who questioned why he paid $50,000 a year to someone who spent most of his time with his feet on his desk. “Because a few years ago that man came up with something that saved me $2,000,000,” he replied. “And when he had that idea his feet were exactly where they are now.

[flashgordon]

At this point you might as well consider switching careers to product management!