I really liked that article was short and to the point!
Be Kind
151–160 of 458 posts
Re: Be Kind
#152I heard a story about Pepsi (dont recall the names), where an executive made a decisiom that lost them 10 Million dollars. The CEO called the executive into his office... The executive shuffled into the office, head down, and meekly said, I guess you called me in here to fire me." To which the CEO replied, "FIRE YOU?! I just spent $10,000,000 educating you!
I recall that from Thomas Watson Jr's autobiography about his life working for his father at IBM.
https://www.amazon.com/Father-Son-Co-Life-Beyond-ebook/dp/B0...
Re: Be Kind
#153Nice little read. There is that little answer in the back of my head of: "It is a good question why I caused this problem. It is weird to think there is a competent company that has been around for so many years, yet they have no procedures in place to stop this from happening. You would think that any changes that could cause downtime on a clients website would go through an automatic test suite and only after passi…
There is a cost in not having certain procedures in place. On the other hand the red tape has a cost too.
A single mistake shouldn't lead unconditionally to a mandatory multi-step process that involves multiple people and may take several months to finish. The examples of the "cover your ass" decision making overpowering the common sense engineering are abundant.
Re: Be Kind
#154Earlier quoted context omitted.
Easier said than done. It's best avoided, of course. But when on a startup you generally cannot afford to be an idealist.
Because missing three days of velocity will definitely cause your growth hacking to fall off the hockey stick and reduce the tempo of your disruption of unique hackathons for people with a left little toe deficiency?
Nothing of that. The reason has nothing to do with "startup culture", head in the clouds buzzword crap, quite the opposite.
The changes are pushed and working in staging, the tests are passing, Q&A is done. Why hold off? So that you get your Good Practices™ badge? I'd say it's better that you don't have to deal with last week's work on a Monday if at all possible.
I think being down to earth, and keeping your good judgement is key. I don't recommend making world-shattering changes on a Friday, but even then, well, it really depends on the circumstances.
Re: Be Kind
#155Earlier quoted context omitted.
Best way not to sound harsh is to ask questions. "What are your thoughts on ...?", "Is this really what you meant to do?", "Do you think there is a better way to handle...?". It puts the power and learning opportunity back to the other person and lets them feel the accomplishment of improving. To the junior devs, when you screw up (and you will) own it and learn from it. Like public scandals, the cover up is almost a…
I find that tone works when the developer has clearly thought things through. Other times, though, some developers need a very stern review. Things like: "Don't name your tests test1, test2, test3. Give them descriptive names," "Follow style," and "this does not belong in the dependency injector," and "don't screw with event publishing logic, filter this out in the event handler in the UI" are warranted when a develo…
Or... bring the team in to review some old code that no one has touched in a while and give everyone the opportunity to critique it. Set those critiques as the bar for everyone's code review. Then, when you review the JD, if he has made those mistakes, you don't have to be stern, you just have to remind him (or her).
Re: Be Kind
#156Earlier quoted context omitted.
My company just had to do it today in response to a critical security issue we identified in production. Saying that nobody should ever do it isn't realistic, sometimes things go wrong on a Friday, sometimes you can't afford to wait 3 days to watch them become even worse.
Yay pedantry!
I don't think I was being pedantic. The parent poster was very clear, there was nothing there for me to overstate.
Re: Be Kind
#157A mistake is an education. If you fire someone after they make a mistake then you are throwing away your investment in their growth.
Re: Be Kind
#158Junior developers who make a mistake? Cut them some slack and teach them. Senior developers who make the same mistakes over and over and never learn? I've kindly pointed out the mistake and invited them to avoid it in future. After a few more failures, I sometimes talk to them sternly, but the sad thing is that they won't learn from either kindness or harshness. I'm not in a position to fire them. Does anyone have an…
Aren't you interested to find out why they're making those mistakes?
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.
Re: Be Kind
#159Great anecdote. We've all done it. Another thing I learned really early on - never deploy code on a Friday. Especially not Friday afternoon/evening. And definitely not if you're leaving for the weekend :)
Re: Be Kind
#160> I walked into the office certain I was about to be fired. Wait, can you be fired that easily ?
Many US states are "At Will" employment. You can be fired for almost any reason, at any time. At the same time, you can quit at any time. Giving notice is a professional courtesy, but not strictly required.