80% of programmers are NOT happy… why? - YouTube

Hey I'll have you know I create tech debt all the time ... Oh you said cool

Thank you for writing this. You make me feel better about my lack of writing code.

never given the time to do it

It's easier to ask for forgiveness than to get permission.

It's easier to fix bugs that you just introduced to be able to cover that KPI, too 🌚

TFW half my development time is stolen by helping this guy who I strongly suspect is just an interface for chat gpt.

... as in fuck off into the woods and farm chickens?

A software dev co-op would be sick 👀

Yes

I'm hoping for a 4-day 6-hour work week in my lifetime, but it seems the world isn't ready for that quite yet, even though I'm 100% convinced productivity would not be impacted in any significant way, at least when it comes to software dev.

I think that would depend on the skill of the developers and the resources they are given.

A lot of us are only ever taught to be code monkeys and those would probably not naturally gravitate towards true agile practices (which most, I would argue, have never actually seen in a real project).

Another problem is a lack of access to domain experts, which is also crucial.

However, my current project doesn't have any managers, or even business analysts, there's only the developers and the Product Owner. We have access to some domain experts and we work with them to build the right thing.

It's going great and the only problems we are facing are a lack of access to the right domain experts sometimes, as well as some mismanagement in the company around things we can't do ourselves (like the company Sonarqube not working and us not being allowed to host our own due to budget constraints).

In conclusion, I think part of the problem is educating software developers - what true agile is and what the industry best practices are (some mentioned in my previous comment). Then you give them full access to domain experts. Then you let them self-organize. Basically, make sure you have great devs, then follow the 12 Principles of the Agile Manifesto to the letter and you've got a recipe for success.

Otherwise, results may vary a bit, as I think many would tend to continue doing the Fake Agile they were taught and continue producing the poor quality, untested code they were taught to produce.

You point to Valve as a success story, but the "pick the work you want" also lead to less deliverables and focus and they had to refocus that approach. Free pick and experimentation is fine until you get to a point where you want to get something out the door - when it's a bigger thing, and you need more and focused people, to bring it to the finish line.

I can't speak how it would be elsewhere and everywhere, but I can speak from personal experience how my workplace is set up.

We're relatively small, work for various customers, some continuous and some contract-scoped. Developers work and speak either directly to and with customers, or have at most one person "in between" that is part of usually our team.

We have an agile and collaborative mindset, and often guide our customers into productive workflows.

Being on relatively small teams, with opportunity for high personal impact, and with agency, I was able to take initiative and work in a way I am very satisfied with. I am able to prioritize myself, collaborate with my customer to understand their needs, understandings, and priorities, and then make my decisions - explicitly or implicitly. Two-week plannings give good checkpoints to review and reassess intended priorities - which are only guides. Stuff comes up that takes priority anyway, be it from the customer, or improving code when you stumble upon it.

I'm glad to be on my current team where the customer pays monthly for how much we worked, so no repeated contract work estimation. I can and do decide on what makes sense, and we communicate on priorities, planning, and consequences. Either I decide or we discuss whether one or another solution makes more sense considering effort, significance, and degree of solution or acceptableness. One person from the customer is our direct gate to them, participates in meetings, planning, tickets, prioritization. They block all of their requests to us, and communicate to and with us on what they deem important enough. And they are our gateway to asking the customers roles and people regarding usage, functionality, needs, etc.

For me, this environment is perfect. It allows me to collaborate with the customers to match their long term needs.

I think it needs good enough developers though. There's those that are mindful and actively invested, but also people who are not. Some become great productive workers with guidance and experience, but it doesn't always fit. I feel like a lack of proactive good development given the environment and agency isn't a given, but I don't think "management" improves that. You're putting a manager on top in hopes they're a person like that. But why couldn't that be a team member in the first place?

Managers and more strict role splitting becomes more necessary or efficient the bigger you scale. I feel like smaller projects and teams are more efficient and satisfactory. You have less people and communication interfaces. And as a developer, you probably know that interfaces [between systems] are one of the biggest issue causers.

For context, I am Lead Developer (became when we introduced those roles explicitly), and our team size was 2 for a long time, but has now been 4 for a while, and is now 3 developers +1 now in semi-retirement working only half of the year.

It would probably start to look a lot like Lisp programming, as in how Crash Bandicoot was made.

Again, I used to work doing actual electrical engineering, working at an architecture firm designing bridges and buildings, and what you're describing as "actual engineering" is the whole reason I went into software.

Because if the actual engineering you're doing is just combining a lot of well defined parts to fit certain acceptance criteria, then you don't really need a person doing that, software can do it.

Yeah, it was a great feeling when I had it for the first year and a bit of my career working on architecture software. I had it again recently when working on back end auth systems for a major automotive company but then we lost the contract and I had to rotate off. Now I work building software that is necessary, but the parts that are prioritized for development aren't the parts that make the average workers' life easier (which would increase overall efficiency when measured on a time basis) but the parts that enrich management because that's easier to sell.

I haven't had one in programming yet