We overestimate what we can do in a month and under estimate what we can do in a year. Love that.
Yes, very very nice summary.
The Art of Thinking Long-Term Even When Money Is Running Out
21–30 of 43 posts
Re: The Art of Thinking Long-Term Even When Money Is Running Out
#22Earlier quoted context omitted.
>> 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…
> 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 refa…
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.
Re: The Art of Thinking Long-Term Even When Money Is Running Out
#23"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…
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.
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.
Re: The Art of Thinking Long-Term Even When Money Is Running Out
#24FWIW the "marshmallow experiment" failed when it was reproduced with more participants from wider backgrounds. Probably not something you want to hook your ideas onto.
https://www.theatlantic.com/family/archive/2018/06/marshmall...
Re: The Art of Thinking Long-Term Even When Money Is Running Out
#25Earlier quoted context omitted.
> 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 refa…
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 t…
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. :)
Re: The Art of Thinking Long-Term Even When Money Is Running Out
#26We overestimate what we can do in a month and under estimate what we can do in a year. Love that.
It's basically Amara's law in action: We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
Re: The Art of Thinking Long-Term Even When Money Is Running Out
#27Paywall in front of such article looks especially funny.
Re: The Art of Thinking Long-Term Even When Money Is Running Out
#28"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…
> 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.
Re: The Art of Thinking Long-Term Even When Money Is Running Out
#29Earlier quoted context omitted.
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 t…
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.
Re: The Art of Thinking Long-Term Even When Money Is Running Out
#30Earlier 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.
You know that all jobs have a probation period even more so in the UK.