UKC

UKClimbing Ltd is looking for a Senior Software Engineer to help build and improve our app and digital tools for climbers. This fully remote role is a great chance to have a real impact on the climbing community.

Read more

Can anyone tell me why software work is always full time? I have only ever seen two part time workers and one of them lost his job when he wanted to be unavailable when the company arbitrarily wanted him to attend a pointless meeting. 
 

obviously any climbing focused person would want more than flexitime. Who can really maximise  their climbing potential on just shifting hours around?  How about 35 weeks per year and 20 hours a week paid pro rata. I’d think about coming out of  voluntary unemploynent if that were on offer. 

Because maintaining a serious commercial application is a full time job.

Or two half time jobs . Or am I wrong that having two minds on a problem is better than one? 

As much as I support (and also do) a less than full time job - the idea that you could just employ two half-time people forgets about all the overheads, admin, HR, etc. etc. So it's not as simple as half the hours, half the pay.

I do think the Rockfax and UKC guys do work too hard and should go out climbing with me on Thursday's more often (hint hint)

One full time job and someone else, maybe. You need one person's undivided attention to handle the full lifecycle of a commercial product. There needs to be a person that ultimately "owns" the codebase, even if other people work under them.

The idea that x number of programmers will take time t to do x * t amounts of work is akin to expecting 9 pregnancies to result in a baby in 1 month.

I think advertising a full time job is the default for many jobs. It doesn't mean part time wouldn't be available if you asked. In the case of a senior role, taking ownership of a product might be tricky, but lots of employers, especially smaller companies, would prefer the right person to the precise hours.

Still, doesn't have to be 5 days a week! This idea that 5 x 8 (or whatever) is some optimal sweetspot for maximum company efficiency is just outdated dogma. 

Loads of people work 3 or 4 days at my current employer and it doesn't harm the business one bit. In fact, the people who do less hours seem, in general, more focused and more productive. 

As well as agreeing with everything Wil said in the post above yours, I emphatically agree with this.  

I quite agree . There is a whole cohort of older workers who would come back to the industry if there were true flexibility.

This is unusual, Who do you work for please?

Loads is maybe an exaggeration, EDF Renewables. 

Perhaps it's not about the individual and its actually about the team/the company?

Example:  Would a small company (UKC) who all currently attend the office 5x8 (do they?) ... really want a "senior" software engineer on the team who is working a 4x10 schedule? 

• That would mean that the senior software engineer is working 8hrs a week when the rest of the team is not (2hrs per day x 4 days)
• And the rest of the team is working 8hrs a week on day #5 when the senior software engineer isn't working.

(8+8)/40 = 40% of the working work ... the team and the senior software engineer are unavailable to one another.  Is that a optimal way to work?

I work in software engineering ... it's a highly collaborative job.  Agreed in advance - junior devs who are assigned tasks might be able to work like this ... but as seniority grows I imagine it would be incredibly challenging to call yourself a "senior" software engineer and simultaneously make yourself unavailable 40% of the time to your team.

Just a thought ... 

Let's cast our minds back to The Mythical Man Month:

If it takes one man two days to build a wall, two men will build that wall in one day.

If it takes one software engineer two days to write an application, two software engineers will build that application in three days.

this is indeed true, a software engineer man month is largely devoted to making the software elegantly over complex and devoting maximum effort to not document anything thereby rendering the second engineers efforts worthless. Still I don't see why companies will invest heavily in full timer engineers to waste their time recreating what already exists but not in part timers doing the same.

perhaps a part timer would be a bit more focused on delivering value as the elegant over complex pointlessness that gets built is largely a outcome of total boredom of relentless effort from the full timers.

Are you talking about yourself here? Because I absolutely would never employ anyone with that attitude about development.

For the benefit of anyone who hasn't read the mythical man month, one of the many problems is that as you add people the number of possible communication channels increases quadratically, while the theoretical amount of work done only increases linearly.

You rapidly reach a point where increased communication overhead overwhelms increased productivity.

Many management approaches involving sub teams etc. aim to reduce this overhead.  This works to a point, but instead results in Conway's Law, which states that large systems end up resembling the structure of the organisations that created them.

These are basically unavoidable problems and have nothing to do with gold plating, obfuscation or laziness.  All of those are real problems too of course, but nothing to do with giant mutant man moths. 

Thanks for the great explanation. I've seen this happen (communication overwhelming productivity, not giant mutant man moths). It's a double-edged sword working for a startup which grows into a bigger company. Obviously you're happy it's successful, but it inevitably gets slower and more expensive to do anything, which is frustrating.

When I say "unavoidable" I don't mean it can't be mitigated.  There are approaches that allow teams to scale a bit better but they only buy you so much.

LOL or maybe management focus is on time and cost and as a result quality suffers. Doesn’t sound like you work in IT.

You can get loads of climbing and training done with a 35-40 hours a week, Mon-Fri job. Especially if the job is fully remote (which this is) and there’s some scope for flexitime to enable evening climbing. 

Mick Fowler seemed to do okay (!) while being employed full-time as a tax inspector.

Reading mutt's contributions to this thread makes me think he might be quite 'challenging' as a colleague at work...

In London!

I remember choosing to move away from London after 2 years mainly because of the time take to drive to Wales and Scotland. Only benefit for outdoor sports was it was close to the ferry terminal for the alps. 

Are you double accounting the time spent not working the same hours?

Extrapolating your logic, if their worked hours overlapped by only 20 hours, your maths would say they are unavailable the remaining 20 hours each (20+20)/40=100% which they clearly aren’t. 

Whereas actually both team members would be working 32 hours of the week at the same time, therefore (40-32)/40 = 20% of time “unavailable”. 

Monday:

• senior software engineer:  10 hr work day.
• Rest of team:  8 hr work day.
• Result:  Senior engineer works +2 hrs when rest of team is not working.
• Net +2 hrs

Tuesday:

• senior software engineer:  10 hr work day.
• Rest of team:  8 hr work day.
• Result:  Senior engineer works +2 hrs when rest of team is not working. 
• Net +4 hrs

Wednesday:

• senior software engineer:  10 hr work day.
• Rest of team:  8 hr work day.
• Result:  Senior engineer works +2 hrs when rest of team is not working. 
• Net +6 hrs

Thursday:

• senior software engineer:  10 hr work day.
• Rest of team:  8 hr work day.
• Result:  Senior engineer works +2 hrs when rest of team is not working. 
• Net +8 hrs

Friday:

• senior software engineer:  0 hr work day.
• Rest of team:  8 hr work day.
• Result:  Rest of team works +8 hrs when software engineer is not working. 
• Net +16 hrs

Either way ... 16 hrs of the week one side is working when the other side is not and hence they cannot collaborate/work together.

But I see you're point ... perhaps you're saying "it's not 40 hrs on the denominator but 48" - right?  Since 48 unique hrs of the week were worked by both party's combined

In that case:

• (8/48)*100 = 16.6% of the time the senior dev is working when the rest of the team is not.
• (8/48)*100 = 16.6% of the time rest of the team is working when the senior dev is not.
• (16/48)*100 = 33.33% of the time one or other party is unavailable to collaborate.  

Fairer assessment? 

If a team is needing constant access opportunities to a software engineer for the entire working week I can’t see things being very productive.

Such roles benefit from interaction time as much as they benefit from proper focus time.

I’m far from convinced on condensed working patterns for other reasons however.

We’ve been collaborating with others in different time zones around the world for decades.  It can actually work very well, as you can effectively progress high priority work 24 hours a day for most of a week.