Best practices for remote software engineering • Hacker News Board

Re: Best practices for remote software engineering

#181

Post by morelisp » Tue, Apr 27, 2021, 3:58 PM UTC

solosoyokaze wrote: post #176

morelisp wrote: post #133

Earlier quoted context omitted.

There's a wide range between "burn out" and "had to do something I didn't want to at work today", just like there's a wide range between "my manager's bugging me every 30 seconds on slack" and "why can't I just write the whole feature from my one-sentence description heads-down for 3 weeks and then put up 5k lines at once for code review?" A lot of otherwise-competent developers will do the latter if you don't force…

I respect your opinion but have a different philosophy. > why can't I just write the whole feature from my one-sentence description heads-down for 3 weeks and then put up 5k lines at once for code review?" A lot of otherwise-competent developers will do the latter if you don't force them otherwise. (Way more common even among developers skilled at time management: Getting caught up in a bug for X days and not asking…

"Embracing their creativity and productivity" is hell for the rest of the team who now has to do 5k line code reviews or the feature is forever siloed to that one dev. Most work is not inspiring; when it is it's usually because someone else is spending their time eating shit to give you room to get inspired.

> The vast majority of “deadlines” are completely artificial

IDK, to me it sounds like you have worked in a half dozen B2C startups in a US urban region, all with plenty of money to burn and still seeking "product-market fit". Most development work doesn't go that way. If we don't have A, B, and C ready by the end of the year contracts get breached and people get laid off.

Re: Best practices for remote software engineering

#182

Post by paisleypepper » Tue, Apr 27, 2021, 4:01 PM UTC

yoz-y wrote: post #163

collaborative wrote: post #40

Lots of whiteboards. Clean, tidy desk. No visible cables. Sunlight. Fresh air. Caffeine

> No visible cables I've been looking into this for a while and I'm always kind of jealous of people who manage to hide all their cables. When looking at tutorials, even advanced, on cable management, the people's setups are often so minimal to start with... Do you have any resources on how to properly cable manage a setup that is not trivial?

From my experience doing desktop support at a large hospital: a bulk roll of self-gripping velcro tie, clips to mount the cables under the desk, cables that are long enough to run the route, some creativity, a headlamp and a good amount of patience and scuba gear so you can stay under the desk longer to do the job well.

Re: Best practices for remote software engineering

#183

Post by solosoyokaze » Tue, Apr 27, 2021, 4:23 PM UTC

morelisp wrote: post #181

solosoyokaze wrote: post #176

Earlier quoted context omitted.

I respect your opinion but have a different philosophy. > why can't I just write the whole feature from my one-sentence description heads-down for 3 weeks and then put up 5k lines at once for code review?" A lot of otherwise-competent developers will do the latter if you don't force them otherwise. (Way more common even among developers skilled at time management: Getting caught up in a bug for X days and not asking…

"Embracing their creativity and productivity" is hell for the rest of the team who now has to do 5k line code reviews or the feature is forever siloed to that one dev. Most work is not inspiring; when it is it's usually because someone else is spending their time eating shit to give you room to get inspired. > The vast majority of “deadlines” are completely artificial IDK, to me it sounds like you have worked in a ha…

> "Embracing their creativity and productivity" is hell for the rest of the team who now has to do 5k line code reviews or the feature is forever siloed to that one dev. Most work is not inspiring; when it is it's usually because someone else is spending their time eating shit to give you room to get inspired.

I actually think it's ok to silo projects to a single dev if you design your architecture correctly so that their zone has well defined APIs. I've definitely seen this work better than design/dev by committee.

> IDK, to me it sounds like you have worked in a half dozen B2C startups in a US urban region, all with plenty of money to burn and still seeking "product-market fit".

It's true! (except for the seeking product market fit part, they have had it). I definitely enjoy this type of development better, I also think it leads to the best results and the highest quality software if done right (alongside open source).

> Most development work doesn't go that way. If we don't have A, B, and C ready by the end of the year contracts get breached and people get laid off.

I'm 100% sure you're correct, but I don't think this is developer friendly or a good thing. Part of making great software is having the proper business infrastructure around it. That includes sales, which definitely shouldn't have contract deadlines for unshipped features imho.

Re: Best practices for remote software engineering

#184

Post by beckingz » Tue, Apr 27, 2021, 4:51 PM UTC

lostcolony wrote: post #179

beckingz wrote: post #178

Earlier quoted context omitted.

I had a manager who would ask "is that all you're working on?" if you mentioned working on less than 3-4 unique tasks. This incentivized breaking everything up into tiny tasks and getting things out the door instead of getting the right things done. It was not a good workplace.

So, first, let me say that, yes, that sounds like a bad workplace. Second, just to point out (I'm sure you realize, but just in the spirit of the parent comment), no agile workplace cares about the load of tasks dev has. Are they busy doing valuable work? If not, is there valuable work they could be doing? That's it. If yes to the first, no problem. If no to the first, and yes to the second, no problem, "hey, I've go…

I agree that a True Agile workplace would not care about making sure that everyone looks busy. So far 2 for 3 of the scrums I've been involved with have degenerated into micromanagement and pointed questions if there wasn't constant process, even if that came at the cost of overall velocity.

Maybe just bad luck and bad workplaces, but I am increasing skeptical that there are any true 'Agile' workplaces.

Re: Best practices for remote software engineering

#185

Post by cruano » Tue, Apr 27, 2021, 4:55 PM UTC

adverbly wrote: post #111

collaborative wrote: post #40

Lots of whiteboards. Clean, tidy desk. No visible cables. Sunlight. Fresh air. Caffeine

This is a common list. So common it makes me wonder how unusual it is that I have no trouble focusing with visual distractions. I'm using the basement bar as a gigantic standing desk with tons of monitors, a desktop, and cables everywhere. Streaming setup stuff adds a lot well with the mic, lighting, camera stuff, etc... Its literally chaos. I don't drink any caffeine. I do have 2 whiteboards in the basement, plus an…

Sounds like so much chaos just turns into background noise

Re: Best practices for remote software engineering

#186

Post by angrais » Tue, Apr 27, 2021, 4:55 PM UTC

bregma wrote: post #169

ectopod wrote: post #53

Earlier quoted context omitted.

There would be far more experienced software engineers than brand new ones if the field was stable, but it has been growing exponentially for years. The answer to the original question depends on the rate of growth, how you define more experienced, etc. So it's not obviously true or false.

> it has been growing exponentially for years Hardly. At best it can be described by a second-order differential equation. An experienced engineer would avoid the inappropriate term 'exponential' to describe the phenomenon. The rest is true.

You're missing one point though: experienced in team does not equate to experience in skills or being managed.

Re: Best practices for remote software engineering

#187

Post by noisem4ker » Tue, Apr 27, 2021, 5:12 PM UTC

arvinsim wrote: post #128

mandeepj wrote: post #73

Earlier quoted context omitted.

> avoid 3 hours of writing unit tests Why? Unit tests are our closest allies

Just because something is important doesn't mean it is enjoyable.

Maybe not enjoyable, but also not anxiety-inducing like certain foundational design tasks can be. For procrastinators, writing a small unit test can be a near-mindless, easy activity to get going.

Re: Best practices for remote software engineering

#188

Post by oaw-bct-ar-bamf » Tue, Apr 27, 2021, 5:28 PM UTC

alberth wrote: post #108

Async communication = email overload? Now I’m the first to say I find synchronous communication (eg Slack) to cause massive productivity loss for an organization & can also cause employee burnout … but how do companies that have a culture of async communication not fall into a similar bad issue of email overload?

My gut feeling tells me that as of late I am not able to stay on top of my inbox.

The past 3 years I was able to leave for the day with no unread messages.

The last few months I am unable to keep up. ~20 unread messages and several unanswered Skype chats each day.

Other team members also noticed an increase in the amount of mails.

Re: Best practices for remote software engineering

#189

Post by mandeepj » Tue, Apr 27, 2021, 6:03 PM UTC

arvinsim wrote: post #128

mandeepj wrote: post #73

Earlier quoted context omitted.

> avoid 3 hours of writing unit tests Why? Unit tests are our closest allies

Just because something is important doesn't mean it is enjoyable.

I consider Unit tests to be essential. People who don't like them, maybe they never tried to drive a value from them.

I also use-to consider them not important, but they have saved my as* so many times.

How would you drive a big refactor, without introducing new bugs - without unit tests?

With a solid test coverage, via a button click, you can conclude - how functional is your code base. Of course, not on the basis of weak tests.

Re: Best practices for remote software engineering

#190

Post by npsimons » Tue, Apr 27, 2021, 7:06 PM UTC

barbazoo wrote: post #72

dboreham wrote: post #27

* Shower first * Put on clothes * Deliver tangible things often

Midday showers are one of my favorite things about WFH.

I've run the numbers, and unless the PVs are putting out above approximately 4KW, it's cheapest to take my shower before 8AM. Thankfully I live where it's sunny almost all the time and I often get 6KW between 1100 and 1300, but in the Winter and cloudy days, it's best to get that shower in early.