11–20 of 43 posts
Earlier quoted context omitted.
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.
Yeah, not a chance I'd leave my current job for that kind of instability.
I was under a lot of pressure to increase sales. To boost the next month’s sales, I pushed the button on a big marketing campaign in which we reached out to a hundred potential clients with a time-limited promotion. The results were disappointing. [..] I realised that sales are about relationships 3) Tolerating a bad employee versus firing and rehiring. There is always a short-term reason not to fire someone who’s un…
I was under a lot of pressure to increase sales. To boost the next month’s sales, I pushed the button on a big marketing campaign in which we reached out to a hundred potential clients with a time-limited promotion. The results were disappointing. [..] I realised that sales are about relationships 3) Tolerating a bad employee versus firing and rehiring. There is always a short-term reason not to fire someone who’s un…
Underperforming is not about making mistakes. It is consistently being unable to learn and adapt. It is being unable to mesh with the rest of the team. It is feeling like "I wish I had not hired this person".
But in a startup situation where every new hire is going to make a huge impact on the team, and "money is running out" (as the article is titled), you might necessarily need to be less forgiving.
"Developing new features versus refactoring existing code" 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. "Tolerating a bad employee versus firing and rehiring" Inversely this also gets into something I often see where companies sit and wait for the best possible candidate (everyone claims to hire the best...) and so rather…
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Yeah, not a chance I'd leave my current job for that kind of instability.
Earlier quoted context omitted.
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.
Could ask for a three month leave from current job. To travel the world or what not.
Earlier quoted context omitted.
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.
"Developing new features versus refactoring existing code" 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. "Tolerating a bad employee versus firing and rehiring" Inversely this also gets into something I often see where companies sit and wait for the best possible candidate (everyone claims to hire the best...) and so rather…
>> 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 surroundi…
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.