Tag: perspective

Weekly Article Dump

Here’s the collection of articles I’ve shared on social media outlets over the past week:

  • Why Innovation Is So Hard: A few good points on why innovating sometimes feels like it’s a difficult thing to do and what you can do to improve!
  • Present Slides, Distribute Documents: Do your meetings sometimes feel like someone is just reading you a slide show? You can read a slide show yourself, can’t you? Why not distribute the slide show ahead of time?!
  • How to Evaluate Personal Characteristics When Hiring: Being a good fit is incredibly important when hiring someone. How can you improve gauging how good of a fit someone will be with your work culture? This article gives you a few strategies.
  • Look Out! When the Visible Becomes Invisible: Invisible work “clutter” can be holding your efficiency back at work. Check out this article for why ignoring things at work and letting them build up can get dangerous… and of course, how to avoid it 🙂
  • The Single Most Essential Building Block of Success: This article talks discusses how your mindset and perspective on challenges can gear you toward success. Complete with 10 tips for becoming more resilient!
  • Having a Really Lousy Day? Some Ways to Feel Better: We all have bad days. This article has some great practical tips (13 of them!) for you to improve your day. My favourite is number 2: do something nice for someone else. Definitely a great way to make your day better.
  • Are You a Workaholic or an Outlier?: This article discusses what being a workaholic means and the differences between when it may be a good thing versus a bad thing. The real takeaway point is to remember to do what you love.
  • 29 Reasons to Start a Bog Today: Ever considered starting a blog? For me, it kind of happened over night… but I’m betting there are lots of people at least on the fence about it. Why not give it a shot? Check out this article and you might get that little nudge you need to take the plunge!
  • Why I Wake Up Early and 3 Reasons You Should Too: In this article, Julia Boorstin touches on 3 reasons why she’s a morning person. For some people, it’s a matter of playing catch-up with the other side of the world but for others, it’s just a way to become more productive.
  • 5 Ways To Lead No Matter Your Title: Some of the best leaders at a company are home-grown and not brought in from somewhere else just because they were good leaders. In this article, Angie Hicks talks about 5 different ways you can put leadership skills into play even if you don’t have “Leader” in your job title.
  • So You Want To Pick Someone’s Brain? Do It Right: Sometimes I think this kind of stuff is common sense, but I’m definitely being proven wrong on this one! In this article, Linda Coles talks about a handful of things to consider when reaching out to someone to ask them for their opinion on something. Think about it… Why would you do it differently than if you had the opportunity to do it in person?!
  • Be SMARTe: How to Clarify Confusion:  This article focuses on hiring and resumes, but I think the concept applies in the more general sense. Lou Adler puts it well right at the beginning, “if you can’t describe exactly what you want, don’t be surprised if you don’t get it”. Using a simple set of guidelines, you can formulate what you’re looking for in a clear and concise manner that helps reduce assumptions and confusion.
  • To Become An Expert, Do This One Thing: In this article, Whitney Johnson makes a great point: you need to leave your ego at the door if you want to build up your skill set in an area where you’re a beginner. Just because you might be accomplished at some things, you need to get into the beginner mindset.
  • Are You Grounded in Trust?: Stan McChrystal writes about a parallel to trust in your business and team. Trust is incredibly important, especially in small businesses, because it let’s people focus on what they are experts at. In order to keep your team operating efficiently, everyone should feel like they can trust the other team members.
  • How to Focus Innovation: This article identifies the 6 ‘W’s that you need to answer when considering innovation. Gijs van Wulfen describes these steps as the necessary formula for innovation. He then outlines a group of questions that you should ask about your innovation in terms of it’s placement in the market. Certainly a lot of things to consider, but they all seem worthwhile.
  • The Joys Of Screwing Up: Being fearless is neccessary for innovation according to Jeff DeGraff. When we become afraid of taking risks and pushing the boundaries, innovation stagnates. How can you innovate if you’re never willing to take risks?
  • 7 Tips for Surviving Life As a Middle Manager: Nothing I would consider ground breaking here, but Dennis Berman has done an awesome job of summarizing a lot of excellent middle management tips. You may have read about some of these in some of the articles I’ve shared, but it’s certainly a great list to refer to!

Hope you enjoyed! Remember to follow on popular social media outlets to get these updates through the week!

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+

Singletons: Why Are They “Bad”?


The very first thing I want to say is that I don’t think singletons are inherently bad–even if it means I am cast away from the rest of the programming world. There’s a time and a place for the singleton. It’s really common for people to get caught up with their perspective on something that they outright refuse to acknowledge the other side of it. I’d also like to point out that if you have a strong opinion on something and you find that other people also have a strongly opposing opinion on the same thing, there’s probably good take away points from either side. In this post though, I’m going to focus on why singletons are “bad”, because for me it means acknowledging one of the two main perspectives–that they are the best thing since cat videos met The Internet or they are the worst thing since Justin Bieber.

Let’s clarify what a singleton is here so we’re all on the same page. Maybe you’re under the impression it’s something slightly different than what I’m about to be talking about, so I’d rather make it clear from the beginning. And for what it’s worth, if this isn’t the exact meaning as set in stone by the singleton gods, then that’s sort of unfortunate… because this is going to be what I’m discussing.  From Design Patterns: Elements of Reusable Object-Oriented Software by the Gang of Four, a singleton must:

Ensure a class has only one instance and provide a global point of access to it.

So, with that incredibly complex definition, let’s get into it.


Global Dependencies

There’s approximately 3.2 billion articles on The Internet that will tell you that global variables are the enemy. I mean, I could do some of the work for you, but you could check out this, or this, or this… There’s still billions more. Usually when we have ~99% of people agreeing on something, they probably have a pretty good point, right? You’ll notice after a bit of searching that one *big* problem with singletons is the fact that they are just a different way to dress a global variable. Thus, all of the arguments for why global variables are bad could be used against singletons.

There are a few (quite a few) major problems with having global dependencies:

  • You’ll be putting yourself at risk for dealing with deadlocks if you need to lock your resources
  • Your singleton can become the resource bottleneck in your application
  • It’s hard to know who you’ll affect by modifying the global variable
  • Testing becomes difficult because the tests may depend on the state of the singleton
  • Dependencies aren’t obvious from examining the API

Quite simply, global dependencies can be pretty scary. If you and you’re team are experienced enough, trying to weave in some new features or heavily modify code relying on singletons may not be that challenging for you. Maybe. But testing can get super messy.

When you write unit tests, you want to ensure that each test can be run independently of the others. You need complete control over your state. This can be a big problem if you run two tests in a row that depend on state provided by a singleton. Consider the following set of tests that depend on a singleton in a sample run:

  • Test1 increases the count property on a singleton by 1 as part of the side effect of the test.
  • Test2 also increases the count property of the same singleton instance by 1, just as Test1 did. However, Test2 is explicitly testing this property as part of it’s validation to ensure the value transitioned from 0 to 1.

When you run Test1 all by itself, it behaves as you expect. Great! Now you move onto Test2. Simple. You got it working. You’re all excited so you run them all together. Uh oh… The tests failed! But how? You don’t believe it, so you run them all again. Now they pass! This is a crappy spot to be in. If the test suite executes Test2 before Test1, your tests will work. If the test suite executes them in the opposite order, your tests will fail because the singleton instance will have had its count property increased twice. The global state of the singleton comes back to haunt you.


Tight Coupling

Most experienced developers know that you want to decrease coupling and increase cohesion because this, generally speaking, makes for a good API and extensible code base. Now this point is related to the global dependency points I was previously stating, but it deserves to be addressed on it’s own. The global dependency topic was more of a focus on the application at run time. That is, it becomes difficult to know and manage how your application behaves at run time when you share global state across the entire thing. It’s challenging to to start adding new functionality to your application or modify existing components of your application that depend on the global state because the dependencies just keep growing.

Coupling, in my opinion, is more of an issue with compile time. With singletons, you start to design classes that depend on singletons and thus you are relying on a specific implementation (Maybe you could check out dependency injected singletons?). Singletons, generally speaking, are a single instance of a concrete class. You start to code classes and object hierarchies that are then depending on this concrete class, and this can potentially (and I say potentially, because I would never claim it’s “always”) lead you to a dead end. Let’s consider a scenario:

We’re coding an application that uses a singleton for the data access layer of our application. We have a MySQL data model that we’ve coded as a singleton. We expose a few methods to read and write records to the database using some SQL, and things are great. Then, one day, we speak to our customers like we usually do to ensure we’re meeting their expectations. They inform us that we really need to be able to support a document database like MongoDB in addition to MySQL. Hold on. Wait. You mean our code that uses our data layer needs to be agnostic to the database under the hood?! But… But our singleton is only able to deal with MySQL… (I wrote about how to get yourself out of this situation here, although I would not claim it’s the ideal scenario). If we would have been passing around references to something that met a nice and clean model interface spec, we’d likely be able to hide the implementation details and completely avoid this problem.


Singletons Disrupt The API

Because I like to design complex systems in code, API and architecture is something I like to focus on. There’s an awesome posting over here by Miško Hevery about this very problem. He does a great job describing the problem with examples, so I’ll only try to summarize some of the main take-away points I got from it.

There’s nothing to stop someone from putting some heavy initialization logic in a singleton. I mean, you shouldn’t (because you can’t guarantee when this is going to happen!) but there’s nothing that prevents it. As such, simply calling a constructor on some class (which you might assume to happen pretty quickly) actually ends up taking seconds. Not a couple milliseconds… But seconds. Oh. I guess you didn’t realize your class was trying to call a singleton instance that was connecting over The Internet to some host on the other side of the planet during its initialization. Surprise. Singletons can mask this kind of stuff because it’s not explicit in the API. It kind of goes back to coupling but I wanted to point out that this kind of stuff can get scary.

This can be completely mitigated by incorporating the dependencies right into the API. There’s no hiding crazy database initialization or downloading data from the internet in a constructor (well… it just reduces the likelihood of you doing it so easily I guess). You use interfaces and construct classes in the order that you need them, and this doesn’t end up being some magical process that happens behind a curtain. If one class depends on another, so be it (it’d be nice if it just depended on the interface…), but pass in the reference that you require. Singletons often end up being the shortcut, but what’s easier for you to code now may not be easier for someone to extend upon and understand in the future.



Singletons. You’ve likely seen them. You’ve likely heard bad things about them. You may have even used one yourself. Shame on you. Like all debatable things though, there’s always going to be another side to it. If you take away anything from reading this, I hope it’s that you question what the other perspective is. Fully understanding something requires you to look at all sides.



This article was based on information I obtained from the following sources (as well as my own experiences, of course!):

Listen First: The Human Sounding Board


In the company I work at, Magnet Forensics, I’ve gotten myself into a leadership role. I wasn’t hired for this position (I’m a programmer at heart) but I’ve managed to stumble my way into it! As a young leader, I think one thing is really obvious for me in my daily leadership tasks: I don’t have all of the answers. Hell, I don’t even have a lot of the answers! So what keeps me from being entirely useless as a leader then?

I know who has the answers. My team.

The most important leadership lesson that I’ve learned (and I’m glad I learned it early) is to listen. The benefits to listening, and I mean actually listening, can be beneficial to the person asking as well as yourself as the leader.

How Can Listening Help Me?

Let’s be honest here. You’re a leader. You have things to do. How is sitting around listening to other people going to help you?

I briefly mentioned it already, but as a leader, I don’t have all of the answers. I’m also willing to bet that you don’t have all of the answers. In the end, probably nobody has all of them. The group of people you lead, collectively, probably have the best bet at having the answers though. Your team is not only core to production at work, but they’re also a great source of insight. Provided you have hired people from a variety of backgrounds, everyone has different experiences and perspectives to share.

Say you’ve run into a problem where developers can’t code things in parallel because everyone has different versions of the source code. Someone on your team suggests source control software. Cool. What the heck is it? Let’s ask a couple other people for their perspective on it. Now you know that some people have used Subversion, some Git, and others CVS. You still may not know what they are, but you know that introducing one of these could solve the problem at hand. But which one? Ask. What are people comfortable with? What are the pros and cons? What are people’s person experiences with these? Use the information provided by your team to guide your decision making process.

That’s Great, But… I Knew That. What Else?

If you’re a leader in your place of work, you may have encountered a situation like the following. You have a junior staff member come to you to ask questions. Like anyone else, you’re busy with your own stuff to do, but it’s your responsibility to help out your staff (and junior staff need the most assistance)! So, you do the obvious thing: give them the answer.

Sound familiar? It’s a common situation and it probably doesn’t seem out of the ordinary. Sometimes after a handful of questions, these junior staff members get up to speed and the questions cease or slow down. Other times, you might notice a bigger problem. That junior staff member becomes a bit more of a familiar face. You actually see a lot more of him or her now. And the questions? Don’t you worry. He or she has tons of them. In fact, they have an unlimited list of them.

If you listen to what these people are asking you, you can better shift the solution to long term. Don’t instinctively spit out the right answer. Let them ask you. Then ask them some questions back. Listen to their responses. If listen to what their problem is, you can find out where their pain points are. Guide them through it by asking them more questions and using their responses to steer the conversation.

This is beneficial for you because you’ll start seeing less of this person for asking questions. But why? What have you started doing?

Benefiting The Person With The Questions

And now we’ve arrived at the other core point: become the human sounding board. By listening (and listening well) you can actually let other people answer their own problems. They really just need some guidance in the whole process. It’s really similar to rubber duck problem solving (from the programming world). People often come to you with questions, and they’re on the verge of arriving at the answer.

You end up conditioning people on your team (that sounds king of wrong I guess, but let’s roll with it) to think first. People won’t come to you because they know they can get a quick answer from you. It’s not like doing a search on The Internet and relying on the first result anymore. Problem solving often doesn’t have a simple instant answer so don’t teach people to use you for that.

How Can I Listen Better?

Stop talking. It’s that easy. When someone comes to you with a question, don’t interrupt them with the answer before they’re done. Shush your lips. Besides, nobody likes being interrupted. You’re also demonstrating you’re not listening if you wan to interrupt them to answer. They could throw in a curve ball at the end that completely changes the context. So… hold your horses, zip your lips, and open your ears. If you find it hard to do this, actually shut up and count to 3 before you respond. You might get some funny looks for a week or so, but you’ll be listening a lot better after that.

Give your full attention to the person asking you questions. If you’re typing 3 emails, checking your facebook and twitter accounts, programming and interrupting the person asking you questions, you’re doing it wrong. When someone comes up to ask you a question, provided you aren’t in the middle of something that you can’t get away form momentarily, lock your computer. Lock it, turn to the person, and give them your full attention. You certainly aren’t listening well if you’re multi-tasking while someone is asking you questions. How do I know? Well, I guess I don’t. But I’d be confident in saying that you could listen better if you gave him or her your undivided attention. This also makes the person asking you feel more engaged. They know that you’re listening.

Reword people’s questions back to them. When someone asks you something, paraphrase it and ask it back. Confirm that what you’re hearing is what they’re asking. Why does this matter? It ensures you that you’re not misinterpreting something and it ensures him or her that you know what they are asking. It engages the person asking the question and it forces you to actually listen. It’s pretty hard to paraphrase something if you’re only hearing words and not getting any meaning from it.


By acting as a human sounding board, you:

  • Need to listen to what people are saying. Actually listen to the meaning.
  • Need to practice giving full attention.
  • Need to bite your tongue. Just. Stop. Talking.
  • Paraphrase what people ask. Boost engagement from both sides of the conversation.
  • Empower other people to make decisions better.
  • Utilize your number one information resource: your own team.

There are many benefits to listening. Start now to help yourself and help your team. You’ll see the results of this immediately. Try it out!

Why Events? Flexibility.


There are many different approaches to developing software, but in my opinion, the opposite ends of the spectrum end up being:

  • Knowing how the whole system looks, feels, and operates before coding a single line.
  • Having an idea of what the user wants and coding to make it happen.

Although I’m generalizing a lot here, it’s sort of like the battle between Waterfall and Agile. Okay, great. So what am I rambling on about here?

Well, in the first case, you know all the ins and outs of the system. You can structure your system so that almost no matter how complex it is, you can ensure that method A is always run immediately after method B which is etc… The design is completely controlled. You have a spec for how all the components work together. The problem? Well, most of this will be reserved for another write-up, but in our case there’s no flexibility. If that spec changes after your complicated system is already in place, how much code do you have to go change?


Enter: Events

Okay, so I hinted at why something like Waterfall might cause some headaches, but you don’t need to develop your software in an agile fashion to have flexibility. Events can help you with that!

If you’re not already familiar with what an event is, it’s simply a delegate that one would call when some particular criteria is met. In C#, which is what I’ll be assuming for this write-up, you add event handlers to an event so that when the event is invoked, the event handlers get called (and they get called in the order that they were “hooked” onto the event). Splendid.

So what’s great about events? How are they going to fix your brittle code? Well, if you approach software design in terms of components in a system and how they interact, it’s really beneficial to think about how certain things react to each other. If you’re planning your whole system out ahead of time, you could just always call method A, then method B, and then method C in order every time you want something in particular to happen. But is that flexible? What happens when method B now calls an additional method, let’s say method D, due to some architectural changes that had to be made. Well… That’s all fine and dandy unless you have scenarios where you don’t want to run D in your A,B,C method calls you have everywhere.

So, what if you had thought about it this way:

  • I want B to run once A is run.
  • I need an event for A
  • I need to call method B in my event handler for event A
  • I want C to be run once B is run.
  • I need an event for B
  • I need to call method C in my event handler for event B
And then someone comes along and throws method D into the mix. Well, you know that there is at least one particular case where you want D to be run after B is run… So make another event handler! Your listing now changes to:
  • I want B to run once A is run.
  • I need an event for A
  • I need to call method B in my event handler for event A
  • I want C to be run once B is run.
  • I need an event for B
  • I need to call method C in my event handler for event B
  • I want D to be run when condition X is met after B is run
  • I need an event for B (which I already have!)
  • I need to call method C in my event handler for event B
    • I can add a whole second event handler for event B (so I get C then D called)
    • OR I can modify the existing event handler that calls method C to conditionally call method D when necessary

And now how do you check the condition? Pass in some fancy event args with your state.



Events can help you keep your code flexible when your structure is changing because they provide hooks into the code when certain conditions are met. You don’t need to rely on a firmed-up design for how methods are required to be called in some particular order. If your design changes because you want something to execute under different conditions, just hook up to the event that meets those conditions instead and re-write minimal code.

I’m huge on using events in my architectures, so I’ll try to write up a few more posts on events and why I like them. The flexibility I just described is only one very small part of it, and it certainly requires that you shift your perspective on how components in a system interact.

  • Nick Cosentino

    Nick Cosentino

    I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress