>> I like to do minor refactoring as part of any given new feature (even if unrelated). It helps take bites out of the larger pieces over time.

This hits the mark.

I don't think developers should even necessarily explain that this is what they are doing, because then they have to ask permission to do it.

I'm constantly thanking "myself from the past" when I go to implement some new feature and find that the surrounding code is clean and well organised and ready for that new feature to be easily implemented.

> I don't think developers should even necessarily explain that this is what they are doing, because then they have to ask permission to do it.

In my experience, it pays to be open with product managers and QA about what you are working on, how you are implementing it, what the risks and benefits are, etc. For example, it helps QA to focus their testing efforts on the areas that are most likely to be broken by a refactor. And having some understanding of how an app is built and where the problem points in the code lie helps product managers to develop a sense of how much effort a certain change might take, and reduces the chance that they will be surprised by some behavior in the app as the result of a change.

And if someone on the team wants to question me about the cost/benefits of a certain refactor and discuss alternatives, I think that is totally fair game. Same way that if I want to ask a question about the cost/benefits of a new feature and discuss alternatives, I feel empowered to do so. It's not about asking permission so much as it is about developing a shared understanding of the costs and benefits of the decisions that we make, and working together to optimize them.

You make good points and I tend to agree with you.

On the other hand I remember on some projects there being real (HUGE) pushback from the client about doing anything that wasn't implementing features exactly as they define and "are paying for".

As soon as you declare that you are doing something "optional", it gets political, people start talking about it, it escalates to project manager, their bosses boss etc and the shitfight starts. Ugh.

Yup I guess what I was describing was more of an ideal software development environment, but fully recognize that there are many cases where being too transparent can cause issues. Hopefully those projects paid well, at least, to make up for all the frustration. :)

The best general strategy may be simply "tit for tat". Try going the high road first; if you see positive reaction, keep at it; if you see dysfunctional reaction (like parent here had), revert to doing it without asking for permission.

> implementing features exactly as they define and "are paying for".

The reason they're paying so much for it is that you didn't do the refactoring last time. Every time they refuse a refactor, all their future costs genuinely go up.

If they ask why the refactor is needed, why you didn't do it properly first time round: “You're constantly refining your business processes to satisfy ever-changing business needs; that's what I need to do to the code.”

> I'm constantly thanking "myself from the past" when I go to implement some new feature and find that the surrounding code is clean and well organised and ready for that new feature to be easily implemented.

The more experience you have with the reverse of that situation ("Dammit past koolba, what the hell were you thinking?!"), the more you value dedicating time to both doing things right and going back to progressively clean them up.

The real skill to learn is to properly isolate quick and dirty solutions so that they can be easily replaced down the road. The sausage factory does not need to be spotless on day one, just the entrance and exit doors.

There's a stigma that offering a candidate a 3-month temporary offer (or any such short time length) will make them not want to accept. However, I've had success is using temporary employment as a great way to figure out if the candidates would work out or not.

Main issue is not for the company, but the candidate. If he is a senior developer currently working elsewhere and you are trying to convince him to join, a 3 month temporary offer is a hard sell.

A probation period of three months is pretty common here in the UK, even for senior people. I've got 20 years experience and just checked my current employment contract, and I had one. Nobody seems bothered by it. Remember that if the company wants you gone, you're gone regardless of any probation period. The probation period only determines how many steps they have to go through to do it and how much notice you are given.

Yeah, not a chance I'd leave my current job for that kind of instability.

Pretty sure no one would. You'll only manage to get unemployed people. Who will bail if they get a full time offer during that three months.

I would. Why? Because I'm confident that they won't want to get rid of me at the end of that 3 month period. Hiring is expensive, and unless I mess up badly, there's no incentive for them to fire me. If they wanted someone temporary, why would they not just advertise for a contractor?

I wonder how much you'd have to pay someone in severance to make it worth it. If there's typically a 20% yearly salary piece for a recruiter, paying 10% direct to the employee in severance if their 3 months doesn't work out might make it work for a subset of people.

You know that all jobs have a probation period even more so in the UK.

Then why bother with the song and dance?

Could ask for a three month leave from current job. To travel the world or what not.

Even in EU it's a tough sell. Your current employer has to agree to it. Why should they, since you're leaving? It only complicates counting employees.

Better to have an employee that knows the grass is not greener on the other side, thus he/she has been there. A good employer will let you take a leave, its even a right in some EU states.

Doesn't mean you can go and work for potentially a competitor

I don't know that a 3-month temporary offer is really necessary. In California at least, where employment is "at-will", you can fire an employee at any time for almost any reason. My expectation when accepting a job offer is that if I am not successful in my role, I will be fired. Most jobs I have worked even have an official "probation period" for new employees where you have a set of goals you need to accomplish in your first 3 months of work, followed by formal review process with your manager and HR.

It's rare to fire new employees in their first few months, but it does happen. Similarly I have seen people join a company, and leave after their first week because a better job offer came in. It sucks when it happens... but overall I'd say the system works pretty well.

> I don't know that a 3-month temporary offer is really necessary. In California at least, where employment is "at-will",

Yeah, in an at-will state you might as well consider the "trial" period to be in place no matter what. If things don't work out well they'll just toss your ass to the curb. Maybe if you're lucky like me your boss will have a soul and give you some amount of severance at least.

When I took my first job I just assumed that it was a sort of trial.

Two people were hired. Me and another dude.

The other dude was invited to look elsewhere (they let him stay and work while he looked for a job so that was very nice), and I got a series of raises after they clearly were comfortable with me. They then started looking for a replacement for the other dude.

Effectively I assumed (correctly) I was on a sort of "trial" anyway.