3 ms·
Of course. I guess I can give some examples. One developer writes huge methods or functions with a tangled mass of if-else. The inevitable result is that an el
by justin_oaks 10y ago
Of course. I guess I can give some examples.
One developer writes huge methods or functions with a tangled mass of if-else. The inevitable result is that an else case missed and the whole thing fails spectacularly in some situations. Discussions with the developer are basically "That's how I've always done it and I don't want to change. I'll just add that missing else".
Another developer constantly forgets to terminate servers that he started in our cloud hosting provider. This costs the company money and thus should be avoided. When its noticed that they're still running, he gets asked to terminate them but he doesn't do it right away and forgets again. Someone else ends up doing it. He's been asked repeatedly to make sure to terminate the servers. Suggestions to help include setting a timer, writing a script that will check for unused servers, etc. Those suggestions aren't heeded or I guess he forgets to remember to set the timer.
Another developer says in a meeting that he'll perform a task, but forgets before he gets out of the meeting. When he's asked to write it down, he does so, but never looks at the paper later.
There are more cases, but it seems to boil down to people not learning. You need to learn how to structure your code, you need to learn how to manage your time, you need to learn how to remember to do something.
But maybe I'm the slow learner and I'm missing something. Thus I'm open to suggestions. So far my strategy is to accept that these other developers behave this way, and setup ways to protect myself from their failures.
- lotyrin 10y agoTeams are made of people, and people are made of animals stretched to purposes far beyond any resemblance to the environment they were designed for / by. Animals will have ingrained habits, many of these will be maladaptive. People though can create systems and systems can adapt for those habits. Do some cost/benefit analysis to enacting policies within the system that is your software development lifecycle. Assign people tickets, tag machines with their desired longevity and kill machines past their designated life span (or a default minimum), hold code reviews for new highly conditional methods and include drawing out truth tables and checking the desired behavior for each row. Lots of teams either expect everyone to be be an ideal spherical engineer and stumble when that proves not to be, or expect nothing of anyone and are doomed to achieve that expectation. The middle path of expecting excellence but tolerating failure is a lot of work but has plentiful advantages. How much failure you have to tolerate and how complex the systems designed to provide that tolerance are depend on the makeup of your team and its size (the larger your team the closer to the mean you'll have to be, and with more individuals a wider variety of behaviors will be represented).
- justin_oaks 10y agoWell put. I prefer enforcing things by technical means when possible and via policy and process at other times. Sadly I see a lot of policy and process that isn't enforced, thus it might as well not be there. Nevertheless, I'll just attempt to improve that which is within my sphere of influence. I suppose I'll just have to do my best to expect excellence and tolerate failure. I appreciate the insight.