State of the Market

[willendure]

I've stopped applying for myworkday stuff - I can't get past the algo. Noir - I never hear back although there's plenty of evidence they are legit. I haven't had many cold calls from recruiters except for the maggots promising contracts with great rates but they'll only forward you with references. Also the moment you make yourself phoneable on Indeed you get a tonne of scam calls. CV Library is much better anyway. JobServe could be good but the site seemingly hasn't been updated since 2000.

Thanks for the recomendations - CV library turned up some stuff. Noir? it only seemed to have 1 listing on it.

I don't get put off by Jobserve website being ancient, its still a busy site with plenty stuff on it.

I get a daily email from total jobs too, main issue with that is that the email subscription cannot be filtered to just contracts, so the email is 90% perm roles.

Any more good recomendations welcome.

Personally, I am still in the goldilocks zone - relevant skillset, some cash in hand and not working. So I can afford to take it easy and see if something interesting turns up.

[SchumiStars]

One thing is for sure, I'm a lot fitter and stronger now

Going gym, Friday night at it's best.

[oliverson]

One thing is for sure, I'm a lot fitter and stronger now

Going gym, Friday night at it's best.

Unlike your bank balance (and mine)!

[Fraidycat]

Meta announced that will lay off roughly 600 employees within it's AI unit next month.

Meta's chief AI officer, Alexandr Wang wrote:
"By reducing the size of our team, fewer conversations will be required to make a decision, and each person will be more load-bearing and have more scope and impact"


'Load bearing', thats what tech employees have been reduced to, like brick walls in a house.

[willendure]

Meta announced that will lay off roughly 600 employees within it's AI unit next month.

Meta's chief AI officer, Alexandr Wang wrote:
"By reducing the size of our team, fewer conversations will be required to make a decision, and each person will be more load-bearing and have more scope and impact"


'Load bearing', thats what tech employees have been reduced to, like brick walls in a house.

Teams are faster though, if they shed the dead weight. Last bunch of clowns I was working with, all off-shore, honestly I could have done the job quicker just by myself. They seemed to spend at least 80% of the time arguing with the delivery manager about why they had not completed their work. The "mythical man month", I believe it is called.

[SchumiStars]

Teams are faster though, if they shed the dead weight. Last bunch of clowns I was working with, all off-shore, honestly I could have done the job quicker just by myself. They seemed to spend at least 80% of the time arguing with the delivery manager about why they had not completed their work. The "mythical man month", I believe it is called.

I agree. SCRUM/XP has changed things considerably. There is less wastage in a teams effort to deliver quality software.

It does mean that developers, testers are working harder in smaller, manageable, measurable chunks of work. Effieciency has increased and there is no hiding if you are a sub par contractor.

Although I prefer it the other way round, the new way of working is here to stay.

[Jaws]

Effieciency has increased and there is no hiding if you are a sub par contractor.

I think that depends completely on the team. My last contract sure had its share of "sub par" developers. Sprint planning ends up with small tasks given increased story points, developers not necessarily picking up anything new when finishing said tasks early and daily standup a consisting of people saying "still working on X" even if it's gone over. Everyone accepts it implicitly because barely anyone is paying attention in these meetings anyway.

The amount of items completed in a sprint decrease naturally with team performance and some projects just take forever. Especially when you consider the additional time spent in meetings to communicate and coordinate it all.

[willendure]

I think that depends completely on the team. My last contract sure had its share of "sub par" developers. Sprint planning ends up with small tasks given increased story points, developers not necessarily picking up anything new when finishing said tasks early and daily standup a consisting of people saying "still working on X" even if it's gone over. Everyone accepts it implicitly because barely anyone is paying attention in these meetings anyway.

The amount of items completed in a sprint decrease naturally with team performance and some projects just take forever. Especially when you consider the additional time spent in meetings to communicate and coordinate it all.

Its so true!

I have only really had one very positive experience working in a scrum team, versus about 8 or 10 mediocre or terrible ones. And that was all down to the particular scrum master that we had who would never have accepted an answer like "still working on X". If the team was so much as a single story point behind his burn down chart he would go into hyper-mode and chase down where his missing point was. We hit every sprint goal, adapted how we worked as we went along, kept the stakeholders in the loop with regular demos etc etc. It was a lot of work and I did not always enjoy the process due to the amount of meetings, but ultimately came away with a good deal of respect for our scrum master - who also was an ex-dev and still a competent engineer, I should add.

The rest of the time, scrum was done in a half-assed way, led by non-technicals, just played lip service to the ideas etc.

Went to an interesting talk by Martin Fowler around the dotcom era time - he talked about a study carried out by IBM on the "mythical man month" where they put together various teams to solve the same problem. Their conclusion? The biggest factor affecting team performance was how well the team members got on with each other! I definitely agree. If you get stuck with a bunch of free loaders, or narcisistic personalities, or off-shore workers that you will never meet or give a tulip about, its usually terrible. Good bunch of UK workers that enjoy working together and go out for a drink occasionally - much better.

[vwdan]

Is contracting essentially dead? Feels like it to me - I'm lucky enough to be in a fairly comfy permietractor role, inside IR35 so whatever, but whenever I have a moach about there just doesn't seem to be anything to find. Not that I put huge effort in at the mo, but I can't remember the last time I got a recruiter phone call - when I first started contracting I'd have several a day, most days.

[oliverson]

I agree. SCRUM/XP has changed things considerably. There is less wastage in a teams effort to deliver quality software.

It does mean that developers, testers are working harder in smaller, manageable, measurable chunks of work. Effieciency has increased and there is no hiding if you are a sub par contractor.

Although I prefer it the other way round, the new way of working is here to stay.

I'm afraid I don't agree with that. My involvement with 'agile/scrum' has been since 2008 after reading the article 'Scrum and XP from the Trenches'. Seemed like a good idea on paper versus 3 years of speccing out the system in an waterfall world, but reality is it's the biggest drain on resources imaginable. And 'waterfall' doesn't necessarily have to be this massive speccing up at the outset, depending I guess on the size of projects you're working on.

There's just too much pissing about and not enough doing with agile, planning meetings, retrospectives (repeated fortnightly maybe = overhead) daily standups (micromanagement in disguise), etc. Mega bloat. What started out as some lightweight idea has been industrialised by the consultancies and pushed into big business. It's anything but agile! Big business has been 'leaned on'.

Just looking at my contract history spanning 20+ years and 15 projects, around half of which have featured agile, by far the most successful outcomes did not use it. What was there instead was some kind of documentation / design document, drawn up either by the project 'visionary', including screen mocks, or documentation that has been created by devs in conjunction with the visionary's vision. To me, those succeeded because some upfront thought, analysis and design had taken place and it was quite clear what the developer(s) were required to deliver, and what the testers were required to test. Contrast that with a bunch of 'agile professionals' (PM's who can't get a traditional PM role and have had to market themselves as agile specialists), a bunch of devs who aren't really interested in 'as a [foo] user, I want to [blah, blah, blah] so that [blah, blah, blah]' kindergarten type, painting by numbers templates, with noddy notion of effort in the form of 'story points'. Utter nonsense. The business wants to know when something will be delivered, not this nerdy abstract notion of effort that maps to **** all in the real world. And don't get me started on TDD or BDD FFS!

Rant over.