I ran into a problem last week where Selenium python scripts were just opening a blank Firefox window and doing nothing. Running this from the command line fixed it:
pip install -U selenium
via python – Selenium: FirefoxProfile exception Can’t load the profile – Stack Overflow.
Whenever I talk about broken windows with respect to software development, I find myself directing people to this page. It’s an excerpt from the book The Pragmatic Programmer, which I’d definitely recommend checking out.
I like this link because it makes a pair of great points:
- Badness invites badness. A little bit of ugliness can quickly lead to the mindset of “All the rest of this code is crap, I’ll just follow suit.”
- Clean code encourages good habits. Nobody wants to be the one who introduces icky code.
So what’s the takeaway? First, you should always strive to create good, clean code. Second, and perhaps more importantly, apply the if-you-see-a-piece-of-garbage-pick-it-up principle. It’s much easier to clean up small messes now than it will be to deal with big messes later.
Article: 11 Simple Concepts to Become a Better Leader
This is a typical be-a-good-person-and-people-will-like-you article, but it’s good to remind ourselves of that from time to time. The concepts presented in the article that I feel are most important are transparency, adaptability, and gratefulness.
Transparency is a great leadership quality because it earns trust over time. I hate playing games. It doesn’t get anybody anywhere. If you told me you were going to start working on a project but got distracted, don’t tell me that it’s moving along just fine. Tell me you got distracted and haven’t started, but also tell me when you’ll be starting it and what will be the impact on the project timeline. Being transparent also drives customer satisfaction because it helps set and adjust expectations.
I presume the importance of adaptability transcends industry–hence its inclusion in the list–but it’s incredibly important for software development. In my experience, it’s pretty rare to have a project that goes 100% as planned. Next to never. And I’m talking about “next” being on the other side of never, not the side where it might actually happen. Understanding when to deviate from the plan is key. It might be to overcome a challenge: “We thought we could do X, but that’s not going to work. Let’s do Y instead.” It’s not always a problem that makes adapting advisable, though; it could be an unforeseen improvement: “We planned on doing X, but it makes more sense for the users if we do Y.”
And, finally, gratefulness. My least favorite type of co-worker is the ungrateful leech. You never hear from them until they need something. Then, you go out of your way to help them out–because you’re awesome and that’s how you roll–and you’re lucky to get an email that says, “Thanks.” When those guys come around looking for help, I don’t like to give it to them. On the other hand, you’ve got people who genuinely appreciate what you’ve done. They offer to buy you lunch or a drink. Gratefulness goes a long way, even if it’s just saying, “Seriously–thanks. You really helped.” When those guys need help, I’m happy to drop what I’m doing to give it to them. It’s not because I hope to get free stuff, it’s because I know my effort will be appreciated. As a leader, you’re playing the role of the guy who needs stuff in these scenarios. Do you want to be the guy that people do things for because they have to or because they want to?
Link: Disagreement as an Expectations Management Technique
I’ve been to mechanics. I’ve pretended to know what’s going on. I’ve been blind-sided by an actual bill that’s several times larger than what I had expected.
This article makes several great points about expectations management. Transparency and honesty improve customer satisfaction over time, even if they bring bad news. Disagreement is a part of that. When a customer comes to you with an expectation that you disagree with, you need to set them straight. If I’m the customer, I’d rather be informed and educated about the incorrectness of my assumptions than be upset and disappointed after the work is done.