5 ms·

Yeah, it's a strange article. They seem to miss the underlying point that in a business, generally speaking, writing the code is relatively easy. It's working o

by remus 4y ago

Yeah, it's a strange article. They seem to miss the underlying point that in a business, generally speaking, writing the code is relatively easy. It's working out what problem you're trying to solve and who you're solving it for that is the hard part (an the bit that requires you to spend time talking to other people). Of course you write more code working on your side project, because you know exactly what you want to do with it and there's usually no consequences if it goes wrong.

blowski 4y ago
The problem with the article is that it's the perspective of an engineer who hasn't had to think about higher-level problems. If I had to summarise their perspective it's "if engineers are writing code, that's a good thing, and anything else they do is probably a waste of time". But what if engineers are writing bad code? What if their code doesn't solve any customer problems? What if the other thing they're doing is helping them write better code? Or scaling the company so they can hire other engineers who do write better code?
- sirwhinesalot 4y ago
  We've figured out 20 years ago that writing code, showing the resulting program to customers and getting feedback was the most effective way to find out if you're actually solving customer problems. Some group of people wrote about it in something called the "Agile Manifesto" or some such.
  - blowski 4y ago
    How do you think an author of the Agile Manifesto would respond to the original article?
    - sirwhinesalot 4y ago
      Considering how companies are implementing the "Half-Arsed Agile Manifesto" rather than the actual "Agile Manifesto", I think reading this article might be what pushes them to jump off a bridge. 20 years of companies failing to understand your 4 line text, and using it to justify things that are utterly antithetical to what it stood for, has got to hurt. It's so simple: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan Sounds like an environment the author of the post would like, he even describes such an environment later on, one that he enjoys so much he overworks for no extra pay. Then there's the twelve principles, one of which is: "Working software is the primary measure of progress." Another one is: "The best architectures, requirements, and designs emerge from self-organizing teams." Another is: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." Following bullshit company processes and pointless meetings is the opposite of the above. The one that might be contentious is: "Business people and developers must work together daily throughout the project." This sounds a lot like meetings, but that's the smallbrained take on it. Here's an easy alternative: Continuous Deployment in a staging area and a Slack/Teams channel for business people to comment on changes they feel are necessary. Not only does the request get recorded (often nothing gets documented in meetings) but the communication is asynchronous and doesn't require booking the entire team for hours. The discussion is also a lot more actionable because it is about something concrete. Given the above, what do you think about how an author of the manifesto would respond?
      - blowski 4y ago
        I imagine the author of the original article works in a company which is prioritising the right hand of the principles over the left. We've all worked there, we've all hated it. I did, so I set up my own company where we'd do agile right. Hired my own team of devs. Got no revenue, velocity was low. Ended up annoying all the devs by trying to push them to spend more on the right-hand side of the manifesto than they thought was necessary so I could figure out why nothing was getting done. Still got no revenue. Eventually gave up. I think the authors of the agile manifesto would say that building complex software requires the business to adopt agile (real agile, not half-arsed agile) with the tech team subsequently following it. The engineers also need to deliver on their side of the bargain. That means continous value, and not just fiddling with shiny new tech and fancy design patterns. When both sides of that operation work well together, you get good software. If you've got enough good people that already know how to do this, it bodes well. But how do you find and pay for all these good people? That's why you get people that merely think they're good, but are at least much cheaper. The engineering tendency when given freedom is to over-engineer everything, leading to disappointed clients, and a fragile system that's buggy and can't be fixed. It's one of the big reasons so many tech-led startups fail, and also why bigger businesses end up putting all these bullshit processes in place. And that's my take on the OP. Lots of "managers bad" without recognising the faults of engineers in that process.
        sirwhinesalot 4y ago
        I'm sorry to hear that, indeed, the engineers have to follow through on their end as well. That means "working" software, minimally functional, has to be delivered ASAP, at least to be able to gouge customer engagement. "Design Patterns" and the latest "Web Framework" fad are the opposite of delivering working software. How you find people with the right mentality? I'm not sure. Low-level game devs tend to have that "make it work" mentality but they like to reinvent the wheel a little too much because the existing wheel is 0.1% slower than their custom made one. Web devs are the opposite, they seem to think the wheel has manifested itself from the ether. They probably don't even know about half of the 50 wheels they brought into the project, and they'll replace them with newer, shinier wheels in a week. I think hiring a good team lead with the right priorities is key. Not a "manager", but the team member everyone else looks up to and follows out of their own volition. It might be worth wasting a lot of money and time on finding and hiring that person at the very beginning. If you do, the rest should fall into place, as they'll hire people who work well with them, meaning same priorities. Look at the impact someone like Jim Keller had on the companies he worked for, as an example.
    - UK-AL 4y ago
      Pretty well since he at VFX company he seems to working closely as a team and with his customers.

by remus 4y ago

blowski 4y ago

The problem with the article is that it's the perspective of an engineer who hasn't had to think about higher-level problems. If I had to summarise their perspective it's "if engineers are writing code, that's a good thing, and anything else they do is probably a waste of time". But what if engineers are writing bad code? What if their code doesn't solve any customer problems? What if the other thing they're doing is helping them write better code? Or scaling the company so they can hire other engineers who do write better code?

sirwhinesalot 4y ago
We've figured out 20 years ago that writing code, showing the resulting program to customers and getting feedback was the most effective way to find out if you're actually solving customer problems. Some group of people wrote about it in something called the "Agile Manifesto" or some such.
- blowski 4y ago
  How do you think an author of the Agile Manifesto would respond to the original article?
  - sirwhinesalot 4y ago
    Considering how companies are implementing the "Half-Arsed Agile Manifesto" rather than the actual "Agile Manifesto", I think reading this article might be what pushes them to jump off a bridge. 20 years of companies failing to understand your 4 line text, and using it to justify things that are utterly antithetical to what it stood for, has got to hurt. It's so simple: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan Sounds like an environment the author of the post would like, he even describes such an environment later on, one that he enjoys so much he overworks for no extra pay. Then there's the twelve principles, one of which is: "Working software is the primary measure of progress." Another one is: "The best architectures, requirements, and designs emerge from self-organizing teams." Another is: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." Following bullshit company processes and pointless meetings is the opposite of the above. The one that might be contentious is: "Business people and developers must work together daily throughout the project." This sounds a lot like meetings, but that's the smallbrained take on it. Here's an easy alternative: Continuous Deployment in a staging area and a Slack/Teams channel for business people to comment on changes they feel are necessary. Not only does the request get recorded (often nothing gets documented in meetings) but the communication is asynchronous and doesn't require booking the entire team for hours. The discussion is also a lot more actionable because it is about something concrete. Given the above, what do you think about how an author of the manifesto would respond?
    - blowski 4y ago
      I imagine the author of the original article works in a company which is prioritising the right hand of the principles over the left. We've all worked there, we've all hated it. I did, so I set up my own company where we'd do agile right. Hired my own team of devs. Got no revenue, velocity was low. Ended up annoying all the devs by trying to push them to spend more on the right-hand side of the manifesto than they thought was necessary so I could figure out why nothing was getting done. Still got no revenue. Eventually gave up. I think the authors of the agile manifesto would say that building complex software requires the business to adopt agile (real agile, not half-arsed agile) with the tech team subsequently following it. The engineers also need to deliver on their side of the bargain. That means continous value, and not just fiddling with shiny new tech and fancy design patterns. When both sides of that operation work well together, you get good software. If you've got enough good people that already know how to do this, it bodes well. But how do you find and pay for all these good people? That's why you get people that merely think they're good, but are at least much cheaper. The engineering tendency when given freedom is to over-engineer everything, leading to disappointed clients, and a fragile system that's buggy and can't be fixed. It's one of the big reasons so many tech-led startups fail, and also why bigger businesses end up putting all these bullshit processes in place. And that's my take on the OP. Lots of "managers bad" without recognising the faults of engineers in that process.
      - sirwhinesalot 4y ago
        I'm sorry to hear that, indeed, the engineers have to follow through on their end as well. That means "working" software, minimally functional, has to be delivered ASAP, at least to be able to gouge customer engagement. "Design Patterns" and the latest "Web Framework" fad are the opposite of delivering working software. How you find people with the right mentality? I'm not sure. Low-level game devs tend to have that "make it work" mentality but they like to reinvent the wheel a little too much because the existing wheel is 0.1% slower than their custom made one. Web devs are the opposite, they seem to think the wheel has manifested itself from the ether. They probably don't even know about half of the 50 wheels they brought into the project, and they'll replace them with newer, shinier wheels in a week. I think hiring a good team lead with the right priorities is key. Not a "manager", but the team member everyone else looks up to and follows out of their own volition. It might be worth wasting a lot of money and time on finding and hiring that person at the very beginning. If you do, the rest should fall into place, as they'll hire people who work well with them, meaning same priorities. Look at the impact someone like Jim Keller had on the companies he worked for, as an example.
  - UK-AL 4y ago
    Pretty well since he at VFX company he seems to working closely as a team and with his customers.