4 ms·

Things seem to be getting even worse, and as I hate to iterate on all the points often repeated on HN (the loss of older industry best practices, CV-driven deve

by mihaic 5y ago

Things seem to be getting even worse, and as I hate to iterate on all the points often repeated on HN (the loss of older industry best practices, CV-driven development, bloated FAANG departments, the issues of funding OSS, etc.), I just want to notice one thing: Most developers and architects seem to have lower and lower confidence in what is technically achievable without some complex dependency web, and that becomes a self-fulfilling prophecy. As believing something is possible is a pre-requisite to actually approaching it, I expect things to continue getting worse.

PragmaticPulp 5y ago
> Most developers and architects seem to have lower and lower confidence in what is technically achievable without some complex dependency web, and that becomes a self-fulfilling prophecy One of the biggest problems I’ve had with hiring engineers out of big companies is that they’ve developed a sort of learned helplessness. The longer they spend in big, slow companies the more they’ve developed an idea that everything they do must adhere to mountains of process and approvals and documents. It can be a challenge to un-teach these ideas from people after hiring them into a company where they don’t need to put together presentations and seek multiples levels of approval before doing anything. One surprise that I didn’t account for is that many people come to like these process-heavy systems with approvals everywhere and no progress until the rules have been followed. It becomes a safety net to pull as many different people and process into a decision before action is taken. If something goes wrong, no one can blame you because you followed the process and got all of the approvals, right? I think this leads a lot of people down the road of preferring high-process, low-action environments because following the process is a type of low-effort, low-risk work whereas producing something new is high-effort, high-risk.
- morpheos137 5y ago
  Complex process creates more work, sets barriers to entry for competitor workers, and reduces individual responsibility for something that goes wrong. So, from the employee perspective complex process means a lot of work to do (job security), higher pay (even if the domain problem is not too difficult process complication makes it difficult reducing the available supply of qualified labor) and less responsibility if something goes wrong. From the business point of view compexity means, being current, keeping up with the latest tech, signaling you are not a dinosaur. Keeping up with security because the shoddy earlier layers had holes because software engineers do not output a finished work product like other engineers. Even if some dinosaurs may do things cheaper and better. From the customer perspective the incentives are pretty often the same. Many customers want a touch screen instead of a knob or button because the latest tech all has touch screens. They want to use Slack or VS Code because that's what the cool kids do these days. From the outer space perspective it looks like humans are building a new tower of babble with their tech stacks. Ever higher layers of complexity not actually going any place or doing much new. Eventually it might all crumble into a pile of confusion.
- stinkytaco 5y ago
  I've worked in environments like that (in and out of software), and this is almost always driven in reaction to something, which is why it's hard to unteach. In my current office there is a culture of consensus building and feedback. If someone feels they were not given sufficient opportunity to participate in a decision, they will complain, resist or otherwise cause an issue in the future. Sometimes they are correct, which is why it's not as easy as simply firing them. Sometimes the red tape is in response to problems in the past. Policies that were poorly enforced that resulted in negative consequences for customers (support failures or discriminatory behaviors). Sometimes it's there to protect low level staff from accusations of the above or to provide clear guidance when dealing with a high stakes/high stress situation. Sometimes it's to protect customers, such as regular security reviews. So no, I do not think this is about "low effort", though that can be a side-effect. No one sits in an office wanting to find ways to make their coworkers lives difficult. More often than not the policy is a response to pressure to do something to prevent whatever failure prompted the policy. The people who like the process heavy approach, in my experience, anyway, are often remembering a time when failure to follow a procedure resulted in negative consequences for someone.
  - PragmaticPulp 5y ago
    > No one sits in an office wanting to find ways to make their coworkers lives difficult. That’s not exactly what’s happening. It’s not about making coworkers’ lives more difficult. It’s about preferring pseudo-work that looks like progress (meetings, process, consensus-building, planning sessions, endless documents) instead of work that delivers results. Once a project ships, everyone can see whether it was a success or failure. However, if you can keep it in the planning limbo for as long as possible you can avoid that moment of truth. Another round of meetings and refactoring and consensus building is safe because it’s easy to say you’ve followed the process and therefore produce good process-work. Shipping to customers is risky because then the product can actually fail. In companies where someone’s reputation and promotion prospects depend on avoiding project failures, it becomes attractive (and safer) to deal more in the pseudo-work than the actual work.
    - orangeoxidation 5y ago
- redis_mlc 5y ago
  FYI: Marissa Mayer was sidelined at Google because one of the founders was told that the site "couldn't be changed in less tha 2 weeks." In order to avoid outages, too much process was adopted. So he stepped in, and she was put in charge of only contract staff. Then on to Yahoo.

by mihaic 5y ago

PragmaticPulp 5y ago

> Most developers and architects seem to have lower and lower confidence in what is technically achievable without some complex dependency web, and that becomes a self-fulfilling prophecy One of the biggest problems I’ve had with hiring engineers out of big companies is that they’ve developed a sort of learned helplessness. The longer they spend in big, slow companies the more they’ve developed an idea that everything they do must adhere to mountains of process and approvals and documents. It can be a challenge to un-teach these ideas from people after hiring them into a company where they don’t need to put together presentations and seek multiples levels of approval before doing anything. One surprise that I didn’t account for is that many people come to like these process-heavy systems with approvals everywhere and no progress until the rules have been followed. It becomes a safety net to pull as many different people and process into a decision before action is taken. If something goes wrong, no one can blame you because you followed the process and got all of the approvals, right? I think this leads a lot of people down the road of preferring high-process, low-action environments because following the process is a type of low-effort, low-risk work whereas producing something new is high-effort, high-risk.

morpheos137 5y ago
Complex process creates more work, sets barriers to entry for competitor workers, and reduces individual responsibility for something that goes wrong. So, from the employee perspective complex process means a lot of work to do (job security), higher pay (even if the domain problem is not too difficult process complication makes it difficult reducing the available supply of qualified labor) and less responsibility if something goes wrong. From the business point of view compexity means, being current, keeping up with the latest tech, signaling you are not a dinosaur. Keeping up with security because the shoddy earlier layers had holes because software engineers do not output a finished work product like other engineers. Even if some dinosaurs may do things cheaper and better. From the customer perspective the incentives are pretty often the same. Many customers want a touch screen instead of a knob or button because the latest tech all has touch screens. They want to use Slack or VS Code because that's what the cool kids do these days. From the outer space perspective it looks like humans are building a new tower of babble with their tech stacks. Ever higher layers of complexity not actually going any place or doing much new. Eventually it might all crumble into a pile of confusion.
stinkytaco 5y ago
I've worked in environments like that (in and out of software), and this is almost always driven in reaction to something, which is why it's hard to unteach. In my current office there is a culture of consensus building and feedback. If someone feels they were not given sufficient opportunity to participate in a decision, they will complain, resist or otherwise cause an issue in the future. Sometimes they are correct, which is why it's not as easy as simply firing them. Sometimes the red tape is in response to problems in the past. Policies that were poorly enforced that resulted in negative consequences for customers (support failures or discriminatory behaviors). Sometimes it's there to protect low level staff from accusations of the above or to provide clear guidance when dealing with a high stakes/high stress situation. Sometimes it's to protect customers, such as regular security reviews. So no, I do not think this is about "low effort", though that can be a side-effect. No one sits in an office wanting to find ways to make their coworkers lives difficult. More often than not the policy is a response to pressure to do something to prevent whatever failure prompted the policy. The people who like the process heavy approach, in my experience, anyway, are often remembering a time when failure to follow a procedure resulted in negative consequences for someone.
- PragmaticPulp 5y ago
  > No one sits in an office wanting to find ways to make their coworkers lives difficult. That’s not exactly what’s happening. It’s not about making coworkers’ lives more difficult. It’s about preferring pseudo-work that looks like progress (meetings, process, consensus-building, planning sessions, endless documents) instead of work that delivers results. Once a project ships, everyone can see whether it was a success or failure. However, if you can keep it in the planning limbo for as long as possible you can avoid that moment of truth. Another round of meetings and refactoring and consensus building is safe because it’s easy to say you’ve followed the process and therefore produce good process-work. Shipping to customers is risky because then the product can actually fail. In companies where someone’s reputation and promotion prospects depend on avoiding project failures, it becomes attractive (and safer) to deal more in the pseudo-work than the actual work.
  - orangeoxidation 5y ago
redis_mlc 5y ago
FYI: Marissa Mayer was sidelined at Google because one of the founders was told that the site "couldn't be changed in less tha 2 weeks." In order to avoid outages, too much process was adopted. So he stepped in, and she was put in charge of only contract staff. Then on to Yahoo.