undefined | Better HN

0 pointsBigJono6y ago0 comments

The problem is 100% with the way software is developed these days. Every company trains their staff to be as unproductive as possible with open plan offices, all the productivity is coming from quantity over quality, with every hire and every hour of training reflecting that.

Working from home is great if you have autonomy and can build a chunk of software with minimal oversight. But if your dev process revolves solely around collaboration in an open plan office then it's not going to translate well to WFH at all. You simply can't have 3 non-tech people for every dev that all need to be kept in the loop and are continuously making decisions when you're not physically there to keep the conversation grounded. Every big business job I've had has tons of these people that go out of their way to keep everything from the devs until the very last moment because "they're too busy" (with the last huge chunk of pointless work their decisions generated that could have been prevented with a 20 second conversation instead of 18 hours of bikeshedding meetings).

And devs are as guilty of this as everyone else. Right now things like code reviews and unit tests are the shit hot trend. "Agile" and "scrum" and whatever else are also red hot. The combination of both means the "default" way to build software is to break everything down into chunks that take hours, and run all the trendy processes on that time scale. If you're breaking every 45 minutes to do a code review, you're going to lose a huge part of the benefit of WFH, whereas in a hotdesking office environment you probably weren't going to build much momentum anyway so it's a much smaller sacrifice. The reason people are losing so much productivity is because before they probably palmed those tasks off to their in-office days so the 1 or 2 WFH days a week were highly productive (at least I know mine were). With 5 WFH days a week that's not an option.

The way to run a dev team remote is to give people more autonomy and bigger chunks of work, and tear down communication channels. Start measuring in weeks or months, let the engineers make the decisions and use their judgement on when to loop someone into a conversation. Teams need to be smaller, with 2/3rds devs and roles like product owner and BA providing support, instead of running the show. These roles need to be domain experts with a thorough understanding of what the business requires and an understanding of how software can meet that need. They should be a fountain of knowledge for the devs to access at their own pace, not just mindless machines that shit out JIRA cards with too much boilerplate. And devs need to take on more responsibility, broaden their non-technical skillset, and focus their tech capabilities more on the fundamentals (quality code that produces for the business), and less on setting up elaborate structures that require constant upkeep and communication within the team (huge test suites, elaborate cross-project CI/CD setups, ridiculous webpack configs, constant code reviews, endless NPM dependencies and convoluted patterns that restrict creativity and increase mental load).

If you want to be productive from home, you need to create an environment where you can just sit down for a few hours, get in the rythym, and produce quality software. If I think of any great software from the past, or the engineers that produced it, none of them were doing it in anything that looked remotely like the dev environments we have today. Shit, most of them did it from home, or from offices that were so cozy and personal they may as well have been home.

I think we've spent the last decade trying to distill software development down into some finely tuned machine that any old cog can drive, and counterintuitively, the further it goes the shittier the software becomes. When I flip through older books like Peopleware, it makes me cringe at how many of the lessons in there still aren't followed, and the amount of problems that were pointed out in the 80s and 90s that aren't only unresolved today, but have seen negative progress.

I see covid-19 as a chance to try something different. Most companies are going to continue to make the same mistakes, and mass WFH will never see adoption as long as they do. So you can pretty much put that dream to rest. But I'm going to be working from home a lot in the future, and try doing things another way for a change.

0 comments

3 comments · 2 top-level

hiram1126y ago· 1 in thread

> And devs need to take on more responsibility, broaden their non-technical skillset,

I've been trying to obtain more non-tech skills within various companies for years now, but I get nothing but more JIRA issues. At this point, I've come to the conclusion that the non-technical workers who deal with the business requirements, revenue, customer interaction, etc. do not want the tech folks to have any control over their domain.

What would they be needed for if we could do both the business functions and also write the code they depend on?

BigJonoOP6y ago

That's true. I think they're still needed in some capacity though, just in lesser quantities than is usual, and with more focus on supporting development and more of a quality over quantity approach. The devs shouldn't be doing everything (unless it's a really small team or a startup), but I find there's a strong tendency to go too far in the other direction. Managers love overhiring, either to mitigate risk, because of budget fuckery, or just because they've been conditioned towards a certain team make-up.

So what ends up happening is instead of having one designer that helps design the look and feel of the app, and sets the direction for the devs if they need help aligning their work to it; instead you have 3 or 4 designers that get pedantic about every pixel on the screen and insert themselves into every stage of development. It's not the designer's fault, there's basically nothing else they can do to fill out 40 hours a week.

This is the huge problem with overhiring, it's so easy to just generate more work to fill out your work week, and work begets more work (especially for the devs, who are usually the only ones actually 'producing' on the team, so work flows down to them). So what happens is as soon as your team goes above capacity in a certain area, it affects development. And once somebody is on the team, it's really hard to remove them from the team. That's just human nature. Which is why it's so important to grow a team slowly and naturally, measuring the effect on the team and gauging team member's opinions at each step of the process.

When I start a project I want to start it with 1-3 people, and do not just the high level planning, but establish roles within the team at a low level. What will we be delivering day to day and what is our capacity? Then once you've got that you can hire conservatively around that. The 'usual' way of forming a team within a big business is complete bullshit. You're making all the decisions up front and trying to read the tea leaves about what your project is going to look like in 6, 12 or 18 months.

snow_mac6y ago

Easy solution to this problem; find a new company to work for that does remote working well

j / k navigate · click thread line to collapse