Perspective

Snow Tubing with Team Magnet – Weekly Article Dump

Snow Tubing with Team Magnet - Weekly Article Dump

Snow Tubing

First off… If you haven’t ever gone snow tubing, get off your computer and get to your nearest snow tubing park.

Now that you’re back from that, we’re all on the same page. Friday was another one of Magnet Forensics‘ staff events and we were fortunate enough to go tubing at Chicopee Tube Park. I hadn’t been snow tubing before–only water tubing–and I haven’t even been on a ski hill or anything for years. To be honest, snow tubing to me seemed like a bit of a glorified crazy-carpet experience which would be fun, but get boring after a couple of runs.

I’ll be the first to admit I was dead wrong. Snow tubing was probably the most awesome way for the entire Magnet family to cut loose this quarter. Most people either love or hate the snow, so finding a big group activity for a company to participate in outside in the Canadian winter can be tricky. Snow tubing was perfect though. It wasn’t too intense that people had to shy away from it and it was exciting enough to keep us entertained for the few hours we were there.

Kelly, you did a great job coordinating the staff event! It was great to see everyone come out and have a blast. Thanks for being awesome, Team Magnet.

Articles

  • The Difference Between Managers and Leaders: In this article by Ilya Pozin, he touches on some of the differences between managing and leading. In my opinion, there’s often the idea that managing people is terrible and leading people is the best thing you can ever do. I get that kind of vibe from this article, so I wanted to point it out right at the beginning. I think that a good way to look at it is like this: Being a manager does not make you a leader, but being a good leader sets you up to be a great manager. Leading and managing are different things, and the better you get at leading the better you can become at managing. With that said, I think the article touches on a lot of great leadership points.
  • 5 Ways to Finish What You Start (and Why You Often Don’t)Susan Perry writes about something that a lot of us likely experience pretty regularly. You pick up something new only to end up abandoning it not too much later. Starting a new project or hobby is exciting and it can be really easy to dive head first into something for this very reason. However, if you find that you always start things and never finish them, it might be worth paying attention to some of Susan’s suggestions.
  • 15 Benefits Of Being An Intelligent Misfit: Isaiah Hankel talks to us about what an “intelligent misfit” is in this article. The idea is that swarm thinking is more about just reacting to things, and that’s not overly beneficial. By being unique and standing out, you actually attract others that are unique like yourself with shared interests. As a result, you end up building a network of people that are truly like you instead of conforming to a group. Isaiah goes on to list 15 benefits to standing out in his article and it’s certainly worth the read.
  • Build the perfect teamPeter Mitchell talks about what ingredients you need to build your perfect team. Establishing a common culture and attitude are things that are definitely among the top. Creating clear goals and objectives for your team will also help pave the way for success. One of the most important parts of creating a team is coming up with complementary skill sets. This can be difficult because you want to create a team with people that think alike but have different skills–and often this is hard for people to separate.
  • Fire, Being Tired.: John Hope Bryant gives us a different perspective on what it means to be tired. He says that it’s not just about lacking energy to do something or not getting enough sleep. Being tired is more about losing interest in something. Why? Well even when you’re run down or low on sleep the things that you’re truly interested in can get you excited. John’s suggestion is stick to things that truly interest you–be honest with yourself. Don’t stay in a job where you’re watching the clock for the end of the day. Find your drive and your motivation.

Follow Dev Leader on social media outlets to get these updates through the week. Thanks!


Recognition: One of Team Magnet’s Masterminds

Recognition: One of Team Magnet's Masterminds (Image by http://www.sxc.hu/)

Background

At Magnet Forensics, I lead an awesome team of people with the mission of creating forensics software to help investigators around the world solve crimes. We’re stacked with incredible people–and not only on the team I’m on, but company-wide. We do a great job of recognizing our achievements as an organization and as a team, but also on an individual level. If someone has gone above and beyond, we don’t keep that a secret.

I’ve been trying to make more of a conscious effort to recognize the people I work with, especially in ways that are unique to my own style. I think recognizing people in person is important, but you also need to consider your setting. Sometimes recognition in a public forum isn’t actually appreciated or isn’t nearly as effective as appreciating in a one-on-one setting. I find even for myself that I get uncomfortable when being recognized in a public setting.

With that said, I wanted to recognize an individual I work with without shining too much of a spotlight directly her. Thank you, Christine, for all of your hard work.

Broken Retrospectives

At Magnet, we try to adhere to some agile philosophies.  It lets us pivot pretty quickly to customer needs–which keeps them quite happy–and still lets us deliver rock solid software. We develop in short cycles called “sprints” and at the end of every sprint we have a retrospective to look back at what worked well and what didn’t. That way in the next sprint we can make improvements. Keep the good stuff, drop the broken stuff and try out a thing or two that’s new. This is excellent for continuous improvement unless…

They don’t work.

We would run our retrospectives religiously, but it seemed like nobody really wanted to be there. It was a seemingly forced meeting where I felt a lot of the time I was trying to stir up conversation. By the end of the meeting, just about everyone would have chimed in, but there weren’t a lot of ideas being generated. It was long, boring, and didn’t accomplish any of the goals we wanted it to. Thus, our development cycles stayed basically the same for a while. They worked and they didn’t appear to be broken enough that people wanted to see change.

Things remained the same until I received some input from Christine. When Christine read an article on LinkedIn called I Like, I Wish, I Wonder, she thought it might have some positive carry-over to our development process. If Christine thought that it might spark a change in our retrospectives, that was more change than I was hearing from the team in general (including myself, to be fair). So I decided we’d give it a shot.

Annnd we haven’t looked back since.

I won’t go too in-depth on how I Like, I Wish, I Wonder has rocked our retrospective world because I want to save that for a separate write-up. The point is that it did, and it’s all thanks to Christine for digging it up for us. We’ve started to completely overhaul different aspects of our development process now that retrospectives are effective. I really started to realize just how big of an impact it had when I was explaining some of the development process changes to our CEO. I remember thinking “Wow… If we wouldn’t have switched our retrospective process, we’d be nowhere near as efficient”.

So, thank you for the retrospective idea, Christine. For anyone else looking to flip retrospectives around, try out the I Like, I Wish, I Wonder scheme.

Personalities

I can imagine a lot of people in the development world don’t think too much about personalities. I know I didn’t. Sure, everyone is different. Everyone has their own effective ways of communicating, things they like, things they don’t like, and optimal situations for working. I get it. Now let me go do my work and you go do your work. In an ideal world, you just assume everyone can figure out everyone else that they’re working with, and things will just be fine. Except things are never ideal, and it never hurts to put in a bit more effort to make sure you can get your team up to speed.

So we tried something out. I worked with my HR manager (read: communicated a potential scenario for our development team, let her run free with her awesome creative ideas, and then helped her where she needed it) to roll out a Myers-Briggs personality test for a small sub-team of our development team. If you aren’t familiar with the tests or the concept, check out the link and read up on it! We figured it would be best to try this kind of thing out on a small part of the team to see if they would find value in it, and if so, we’d try the whole team.

After we rolled out the Myers-Briggs results with the small team, the benefits were immediately noticeable. We didn’t even have to leave the room before seeing the benefits. We knew there was some potential here, so we were already excited to try it out with the rest of the team. With everyone being aware of how other individuals may act and react when communicating and working, it makes a big difference in how particular scenarios are approached.

Thank you, Christine, for making differences in personality something to be cognizant of and then supporting our roll-out of Myers-Briggs. For anyone reading this that manages a team or is part of one… Consider the personality types of the people you work with. Maybe you don’t need a formalized Myers-Briggs plan, but it’s worth raising awareness of it.

Thank You, Christine

Christine, you’ve made a lot of great contributions to the team and I’d like to thank you for them. Our development processes have been able to greatly improve thanks to your initial suggestion. I’m sure we would have adapted over time, but your suggested tweaks have certainly acted as a catalyst. Your furthered support with the personality type analysis and subsequent rollout was also greatly appreciated. You were able to participate in our mini-experiment and offered great feedback to turn it into a success for the entire team.

Thank you. I’m looking forward to what this year will bring!


Be a Better Programmer – Weekly Article Dump

Be a Better Programmer - Weekly Article Dump (Image by http://www.sxc.hu/)

Be a Better Programmer

It’s a new year and that means it’s all about resolutions, right? Well, I’m not a huge fan of keeping around a resolution that needs to wait for a new year, but I am a fan of reflecting on your goals and your skills. If you’re a programmer like me, then maybe this will be a great starting point. In my weekly article dumps I usually would just provide a couple of comments on a link like this, but I felt I should dive in a little bit more. You can find the original article by Amy Jollymore over here. Please have a look! I shared it with the whole dev team at Magnet Forensics because I felt there was a little bit of something for everyone.

Number one on this list, and perhaps the one I’d personally like to focus on more out of this list, is checking your code before blaming others. Blaming other people–in general, not just programming–is an easy way out. When a problem occurs, it’s simple to assume that all of your work is right and that it must be someone else’s fault. But if everyone starts thinking like this, it turns into a nasty blame war. So next time the build breaks or your shiny new feature stops working as expected, don’t go blaming other people. Investigate what the problem is. See what your most recent changes were and if they could have caused the problem. As you start to gain confidence that your changes aren’t responsible for the issue, try sitting down with one or two other people you think might have been around the problem area recently–But don’t go accusing them! Putting your heads together to figure out the problem can speed up the process and might even shed some light on some miscommunication over a design or some assumptions in the code that don’t actually hold true. It’s a lot more embarrassing to blame someone when it’s actually your fault compared to putting in the effort and admitting you might have goofed up. Try it out!

Number two is also a great item. You should never put an end to your learning… especially as an individual in a technology space. There are so many great suggestions listed for this point that there’s no point in me repeating them. Just go read them! An interesting point worth mentioning is using podcasts for learning. This is a great option if you find you’re brain is still spinning when you lay down in bed or if you have a long commute to work (or something else you’re involved in). The author also mentions that you don’t need to be learning programming… What about domain expertise? If you’re writing code for banks, lawyers, or digital forensics… Why  not learn about that too?!

The last point I’ll touch on from the article is number three: don’t be afraid to break things. I love this point. If you’re working on a big piece of software, there are almost certainly areas that seem brittle, scary, or just plain incomprehensible. If your project is still small, it very well get to this point. It doesn’t mean that the code is bad or that you’re working with the worst programmers… It’s just something that happens when you’re continuously trying to build on your software. The real problem occurs when nobody is willing to take the time to go change things. If you have big scary brittle parts of code, then set aside some time, take a deep breath, and go refactor it! It might seem like hell at first, but once you get into it (and especially after it’s done) you’ll feel a million times better. Plus, now your code can continue to be built upon without people running in fear when you mention that section of code. Code can get nasty, but consider using a “tech debt” system or regularly set aside time for refactoring parts of your code base.

Again, the original article is located at: 7 Ways to be a Better Programmer in 2014. Check it out!

Articles

  • How to Manage Dynamic Tensions — and Master the Balancing Act: This was an interesting article on some parts of leadership that often oppose each other. Author Chris Cancialosi does an excellent job in discussing balance between internal and external influences as well as leading and managing. A good take away from this article is at least acknowledging that there are certainly some things to balance. You may want to have the most flexible team, but have you considered if there’s a “too flexible”? Just a bit of perspective that this article might bring to light.
  • A Crash Course In Leadership For 20-Something CEOs: Barry Salzberg‘s article is geared toward young CEOs, but I think that means we can apply the lessons to anyone looking to lead! A few of the points I’d like to mention include being tough on problems and not on people. Your people are the one’s who are going to solve problems and bring great ideas to the table. They’ll invest their time into your organization in order to accomplish great things–so don’t be hard on them. Instead, acknowledge that your problems and challenges are the things you want to crush, and work with your team to make sure you conquer every challenge that gets in the way of your goal. Another point is on taking risks. Never taking risks is a great way to stagnate. You need to learn from your failures, but keep pushing the boundaries. Finally, be ready to adapt. As your organization grows or as the market you’re working within evolves, you need to be ready to adapt and change. You might get lucky and things don’t change all that much over a long period of time, but the odds of that are pretty low. Be ready to adapt so when the time comes, you don’t need to worry about everything falling apart.
  • Leading at Scale with Agility: Brad Smith has a few great points on what leading a team should encompass. First, a team should have a goal that it is trying to achieve. If that team is part of a larger organization, the team’s goal should align with the goal of the entire organization. Secondly, decisions for the team should involve those on the team. It’s easy to sit back and speculate what might be best, but why not involve the people directly affected? Of course, this is more difficult for large teams but maybe that’s an indication your teams would be more effective if they were smaller. Next, empower teams to arrive at solutions on their own. If a plan worked out well, try communicating it to others to try out. Conversely, if the plan had some problems, let others on the team (or other teams) know about the hurdles. Finally, Brad has a point on trust. Trust is arguably one of the most important parts of leading a team. Each team member needs to be able to trust the others. There should be an easy assumption that everyone is operating with best intentions.
  • For Leaders, Today is History: In this article by Steven Thompson, he gives a high-level overview of his focus. Specifically, he focuses on the future and not right now. Steven says the teams he is in charge of are often looking at the problems of “right now” and perhaps a little bit in the future. It would be counter productive for him to try and butt-in to try helping with those problems because he’s so far removed from them. Instead, those individuals have been empowered to focus on those problems. Instead, Steven focuses on the future–the direction of the teams. As a leader, it’s important to try and be thinking at least one step ahead.
  • What If You Had to Write a “User Manual” About Your Leadership Style?: After I read Adam Bryant‘s article, I thought the idea of a leadership “user manual” would be pretty cool. Even if there isn’t a single other individual who would benefit from it, at least it would help reveal to myself some of my leadership quirks. That’s useful on it’s own! I’ll be sure to post up my leadership “user manual” when I have it complete… and I imagine I’ll have to keep updating it over time as my style evolves. It’ll be really interesting to see the evolution of my leadership style! Why not consider doing one for yourself?
  • What Bosses Should Never Ask Employees to Do: Jeff Haden‘s article was a little bit controversial in my opinion–and in the opinion of some of the commenters. I think I get the underlying message behind a lot of what Jeff is saying for each of his points, but as one commenter said, it sounds like a bit of a personal complaint the whole way through. Consider the topic of donating to charities at work. The feel I get after reading that segment is that your organization should not attempt to do fundraising through employees. While I don’t actually think that’s what Jeff is saying, that’s how I feel after reading it. I know that we’ve been able to do several charity events at Magnet, and we’ve always said that they are completely voluntary. I think that’s the crucial part. It’s the holiday season and your budget is a bit tight? How could anyone get mad at you for backing out of a completely optional charity donation? Busy with some personal matters or want to focus on finishing up something at work the day we’re doing a charity event? No big deal, it’s optional. Anyway, the point is that perhaps based on the wording in the article, I felt like some of the messaging will be misinterpreted. I think there are some good points buried in there. Check it out and let me know if you agree or not!

Follow Dev Leader on social media outlets to get these updates through the week. Thanks!


Yield! Reconsidering APIs with Collections

Yield! Reconsidering APIs with Collections (Image by http://www.sxc.hu/)

Yield: A Little Background

The yield keyword in C# is pretty cool. Being used within an iterator, yield lets a function return an item as well as control of execution to the caller and upon next iteration resume where it left off. Neat, right? MSDN documentation lists these limitations surrounding the use of the yield keyword:

  • Unsafe blocks are not allowed.
  • Parameters to the method, operator, or accessor cannot be ref or out.
  • A yield return statement cannot be located anywhere inside a try-catch block. It can be located in a try block if the try block is followed by a finally block.
  • A yield break statement may be located in a try block or a catch block but not a finally block.

So what does this have to do with API specifications?

A whole lot really, especially if you’re dealing with collections. I personally haven’t been a big user of the yield keyword, but I’ve never really been forced to use it. After playing around with it for a bit, I saw a lot of potential. I’ve written before about what I think makes a good API. In my article, I was making a point to discuss two perspectives:

  • Who needs to implement your interface. You want it to be easy for them to implement.
  • Who needs to call your interface. You want it to be easy for them to use.

In my opinion, the IEnumerable<T> interface was a tricky thing to work with as a return value. You can essentially only iterate an IEnumerable, and at the time of calling a function, maybe that’s not what you want to do. The flip side is that for the person implementing the interface, IEnumerable<T> is a really easy interface to satisfy. However, the yield keyword has opened up some new doors.

In this article, I’d like to go over a couple of different approaches for an API and then explain why the yield keyword might be something you consider next time around. Disclaimer: I’m not claiming anything I’m about to present is the only way or the best way–I’m just sharing some of my own findings and perspective.

Interface For Returning Collections

The first type of API I’d like to look at is for returning collections. Based on my own API guidelines, I’d ideally choose an interface or class to return that provides a lot of information to the caller that is also easy to create for the implementer of my interface. The List<T> class is a great choice:

  • It’s easy to construct
  • It’s built-in to the .NET framework
  • It provides many handy functions (All of the IList<T> functionality as well as things like AddRange(), or functions that support delegates)

My next choice might be to have a return type of IList<T>, which would provide a little less ease of use to the caller, but make it even easier for the implementer of the interface. They could return arrays of type T, since an array implements the IList<T> interface, or their own custom list implementation that doesn’t inherit from the List<T> class. The differences between using IList<T> and List<T> are arguable pretty small.

A third alternative, which I would have avoided in the past, is to return an IEnumerable<T>. My opinion used to be that this made the life of the interface implementer a bit easier compared to returning an IList<T>, but complicated the life of the caller for a couple of reasons:

  • The caller would have to use the results of the function in a foreach loop.
  • The caller would have to add the items to their own collection to be able to do much more with the items.

My naive implementations of being forced to return an IEnumerable<T> were… well… crap. I would have constructed a collection within the function, fill it up, and then return it as an IEnumerable<T>. Then as the caller of my function, I’d have to re-enumerate the results (or add it to another collection):

public static IEnumerable<T> GetItems()
{
  var collection = new List<T>();
  // add all the items to a collection
  return collection;
}

private static void Main()
{
  var myCollection = new List<T>();
  myCollection.AddRange(GetItems());
  // use myCollection...

  // or.....
  foreach (var item in GetItems())
  {
    // use the items
  }
}

Seems like overkill to me with that implementation. However, we’ll examine how using yield can truly transform this into something… better. So to reiterate, a few potential implementations for an API involving collections might be:

  • Return a List<T> class
  • Return an IList<T> (or even an ICollection<T>) interface
  • Return an IEnumerable<T> interface

Constantly Creating Collections

My design decisions, in the past, were really driven by two guidelines:

  • Make it easier for the person implementing/extending the API
  • Make it easy for the person consuming the API

As I quickly illustrated in the first section, this meant that I would have a method where I would create a collection, fill it with items, and then return it. I could generally pick any concrete collection class and return it since I would usually pick a simple collection as the return type. Easy.

One thing that might be noticeable with this approach is that it looks pretty inefficient to keep creating new collections, fill them, and then return them. I’ll illustrate with a simple example. We’ll create a class that has a method on it called GetItems(). As per my reasoning presented earlier, we’ll have this method return a List<T> instance, and to make this example easier to work with, we’ll pass in an IEnumerable<T> instance. For what it’s worth, the input to this function is really just for demonstration purposes here–We’re really focusing on how we’re creating our return value.

public class CreateNewListApi<T>
{
  public List<T> GetItems(IEnumerable<T> input)
  {
    var newCollection = new List<T>();

    foreach (var item in input)
    {
      newCollection.Add(item);
    }

    return newCollection;
  }
}

And now that we have our simple class we can mock up a little test for performance… Just how inefficient is creating new lists every time?

internal class Program
{
  private static void Main(string[] args)
  {
    const int NUM_ITEMS = 100000000;
    var inputItems = new int[NUM_ITEMS];

    Console.WriteLine("API Creating New Collections");
    var api = new CreateNewListApi<int>();

    var watch = Stopwatch.StartNew();
    var results = api.GetItems(inputItems);

    foreach (var item in results)
    {
    }

    Console.WriteLine(watch.Elapsed);
    Console.WriteLine(Process.GetCurrentProcess().PrivateMemorySize64);
    Console.ReadLine();
  }
}

When I run this on my machine, I get an average of about 1.73 seconds. The memory printout I get when running is 1615908864 bytes. So is that slow? Is that a lot of memory usage? I think it’s pretty hard to say conclusively without being able to compare it against anything. So let’s keep this number in mind as we continue to investigate the alternatives.

Side Note: At this point, some readers may be saying “Well, if the input to our function was also a list (or if whatever our function has to work with was otherwise equivalent to our return value) then we wouldn’t have to go populate a new collection every time… We can just return the underlying collection”! And I would say you are absolutely correct. If your function has access to an instance of the same type as the return type, then you could always just return that instance. But what implications does this have? You’re now giving people access to your underlying internals, and they can go modify them as they please. So, if you need to control access to items being added or removed, then it might not make sense for you to expose your internal collections like this.

Yield to Incoming API Alternatives

We’ve seen how my past implementations may have looked, so how might we tweak this? If we tweak our API a bit, we can make our method return an IEnumerable<T> instead. Let’s see what that might look like:

public class YieldingApi<T>
{
  public IEnumerable<T> GetItems(IEnumerable<T> input)
  {
    foreach (var item in input)
    {
      yield return item;
    }
  }
}

So in this API implementation, all we’ll be doing is iterating over some type of collection and then yielding each result. If we run it through the same type of test as out previous API implementation, what kind of results do we end up with?

internal class Program
{
  private static void Main(string[] args)
  {
    const int NUM_ITEMS = 100000000;
    var inputItems = new int[NUM_ITEMS];

    Console.WriteLine("API Yielding");
    var api = new YieldingApi<int>();

    var watch = Stopwatch.StartNew();
    var results = api.GetItems(inputItems);

    foreach (var item in results)
    {
    }

    Console.WriteLine(watch.Elapsed);
    Console.WriteLine(Process.GetCurrentProcess().PrivateMemorySize64);
    Console.ReadLine();
  }
}

When I run this on my machine, I get an average of about 2.80 seconds. The memory printout I get when running is 449409024 bytes. How does this relate back to our first implementation? Well, it’s certainly slower. It takes about 1.62x as long to enumerate using the yield implementation as it did with the first API we created. However, yield also uses less than 1/3 (about 27.8%, actually) of the memory footprint when compared to the first implementation. Pretty cool results!

Site Note: So yield was a bit slower according to our results, but what happens if print the elapsed time before we run that foreach loop? Well, on my machine it averages at about one millisecond. Now that’s fast, right?! The cool thing about using yield with the IEnumerable<T> interface is that the work is deferred. That is, not until the program goes to actually run the enumeration do we get our performance hit. Try it out! Try moving the time printout from after the foreach loop to before the foreach loop. Try sticking breakpoints in on the line that yields. You’ll see what I mean.

Summary

In this article, I’ve explored two different ways of implementing an API (specifically focusing on the return value). We saw a brief performance analysis between the two and I highlighted some differences in both approaches. Let’s recap though:

  • Approach 1: Returning a List<T> and creating the collection ahead of time
    • Appeared to be overall a bit faster then yielding.
    • Consumed much more memory than yielding.
    • Callers can use the results immediately for enumeration, checking count, or as a collection to add more things to
    • The return type of List<T> is a bit more restrictive than an IEnumerable<T> like in the second API implementation
  • Approach 2: Return type of IEnumerable<T> and yielding results
    • Appeared to be overall a bit slower than the List<T> implementation
    • Lazy. We don’t actually execute any enumeration code until the caller actually enumerates
    • Consumed significantly less memory than the first approach using List<T>
    • Callers can enumerate the results immediately, but they need to add the results to a collection class to do much more than enumerate

So next time you’re designing an API for your interfaces and classes, try keeping these things in mind!

EDIT (December 30th, 2013):
As per some comments on Google+ by Dan Nemec, I figured I’d add a bit more here in the summary. IEnumerable<T> on it’s own is certainly not useless, especially if you’re leveraging LINQ or extension methods. My main beef in the past was that the consumer of an API with a IEnumerable<T> return value can only iterate over the results… And that’s just because that’s all that IEnumerable<T> lets you do. Dan made a great point though–If you are leveraging things like extension methods, or LINQ (which introduces tons of handy extension methods for working with IEnumerable<T>) then you get all of that functionality tacked on to IEnumerable<T>.

So if you’re not fortunate enough to be working with LINQ or extension methods (i.e. working with legacy code in old .NET framework versions… and yes I am familiar with the attribute you can add in to allow extension methods provided you have a compiler version high enough to support it), then IEnumerable<T> sometimes just plain sucks. I’d wager the majority of C# developers aren’t in this boat though, so I’d like to thank Dan again for his comments.


Happy Holidays – Weekly Article Dump

Happy Holidays – Weekly Article Dump

Happy Holidays

The holiday season is upon us, so I’d like to start by extending my best wishes for you to have a safe and happy holiday. I’ve personally been pretty busy the past few weeks wrapping year-end stuff up at work, so I’m looking forward to a few days of being able to catch my breath a bit. If you have some time off from work, I’m hoping you’ll get a chance to do the same over the holidays. I can’t sit idle for too long though. I don’t like not feeling productive, so once I’ve caught up a bit on some well deserved rest, I’ll be right back at it!

The holidays and end of the year are a great time to reflect on everything that’s happened in the last 12 months. Did you have goals that set you set and accomplished? What about things that you didn’t get to achieve or complete? Were you able to assist others in their goals? Maybe a year is too long for you to wait between points of reflection, but the holiday season provides the perfect opportunity for you to reflect–it’s at the end of the year, and generally you get some time off from your day-to-day!

At Magnet Forensics, we had a year-end review celebration and planning for next year. This was an incredible eye-opener for a lot of the amazing things we did this year. In fact, this last year was filled with so many exciting moments for our company that I thought around half of them were things that occurred in 2012. I was mistaken though. We’ve just been doing that much. I’m incredibly proud of the entire team and what we’ve been able to accomplish.

For my personal growth, this year certainly covered a lot of ground. I was able to work on some new exciting technologies like I had set goals for, and I had actually managed to take on more responsibilities in the workplace while reducing my perceived workload. I’m proud of what I’ve accomplished, but I’ve also been able to identify a few areas that I’d like to improve in the new year. I don’t want to call it my “New Year Resolution” for fear of it never coming to fruition, but I think by acknowledging some areas I l’d like to improve I’m setting myself up to be constantly aware of them.

Try to get some personal reflection in this holiday season. Celebrate what you’ve accomplished and raise the bar even higher for next year!

Articles

I missed an update last week, so I’ll combine both of my smaller article summaries into one!

  • How One Company Replaced Meetings And Bureaucracy With Pairs, Ceremonies, And Storytelling: When I shared this article by Drake Baer on social media, I mentioned that there was one of the three suggestions that I felt might not be met as well. Any guesses yet?

    The first suggestion in the list is working in pairs. The notion of working in pairs has some popularity in programming (i.e. Pair Programming) because you get two sets of eyes and two brains behind tackling the same problem. Partners get rotated every-so-often and you can share knowledge really well this way.

    The second suggestion was about story telling. Story telling really let’s a company philosophy or mission get spread through the organization in a natural way. This also works for receiving customer  perspective and diffusing it as requirements from the user.

    The final idea presented in the article was regarding ritualization. Taking potentially boring or inefficient meetings and transforming them into rituals can provide more meaning and structure to them.

    If you haven’t guessed yet, I figured item #1 may be met with some resistance. I personally don’t enjoy pairing past the point of brain storming ideas together. After that, it feels inefficient to me. I also believe that certain individuals have a “comfort zone” for where they feel efficient in their work. So even if pairing works well for 95% of people (let’s pretend) then for that other 5% it might really be disruptive for them. I’m starting to learn that applying practices uniformly across a team often doesn’t make sense.

  • Some Workaholics Have More Fun: A quick one from Hiroshi Mikitani, but still very worth mentioning in my opinion. When people think of a workaholic, it’s often associated with a negative perspective. But maybe it’s not so black and white. Would you say there’s a difference between someone driven by external factors (e.g. meet deadlines for the boss, make more money, etc…) or someone driven by  internal factors (e.g. create something innovative, help or make a difference in the world, etc…)? I’m not claiming that these can never overlap or anything, but perhaps it’s just a bit of a perspective tweak. Take it or leave it 🙂

  • The Art of Listening: In this article by Gurbaksh Chahal, he touches on some really important aspects of listening. And yes, while listening is definitely important in the workplace, you can likely apply his principles to other areas in life. First, you want to engage people and let them know you’re actually listening. This can be conveyed will by eye contact and body language. For me, I like to lock my computer and turn to people when they come up to talk. It’s the perfect way to let them know they have my undivided attention. The next step is actively listening. Stop thinking of your response while someone is talking. Try actually listening to the speaker the entire time and interpret their words. There are no rules that say you’re not allowed to pause for thought to formulate your response when the other person is done talking! Gurbaksh has a few more pointers, and I strongly suggest you check out his article.
  • 8 Ways Using Humor Will Make You a Better Leader: I’m a big fan of using humour in the workplace, but sometimes I’m not sure if I use it effectively or take things to far. That’s why I always jump to these humour-in-the-workplace articles when they pop up. In this article by Kevin Daum, there are two key points I wanted to address. The first is that humour really does help disarm tense situations. Sometimes there are difficult situations at work, and using humour (properly) can really help break the ice. Of course, you still need to take caution that the humour you’re using isn’t going to make the situation worse. The second point is that humour helps build a bonded community. I think humour can have a similar impact to story telling in an organization when it’s used effectively. You can always related back to “inside jokes” when you were dealing with some high pressure times, some bad code, or just because something funny came up at work. You can always bring the newbies into the inside jokes too and make them feel completely welcome.
  • The 8-Hour Workday Doesn’t Really Work: If you feel like the typical eight hour work day really isn’t your thing… You might not be alone. Jeff Haden put together this pretty informative article about workdays and productivity you might find interesting. There’s tons of ground covered, including a few tips at the end for how you can optimize our work day. For example, try focusing on four or five things in a day that take up 90 minute slots. Certainly worth the read if you’re looking to hack your work-day.
  • The Hidden Danger of Success:  Another little article from Hiroshi Mikitani. So often we’re told to learn from our failures. But how are we supposed to learn from our successes? Hiroshi suggests we treat them equally. Sure, celebrate your success, but make sure you have take-away learnings from each of your successes. Don’t let them get to your head and always stay humble!
  • Keys to Resolving Conflict: Jim Sniechowski dives into some great points in resolving conflict. I think it’s a decent read for anyone who has ever been in some sort of debate or conflict. I imagine that’s most people! Anyway, two great points to start you off: Each side of the conflict needs to understand that there’s a mutual agreement that needs to be met and willingness to accept some of the other side is necessary for coming to a positive conclusion.
  • Four Principles to Inspire Innovation: Lockheed Martin’s CEO Marillyn Hewson provides four of her principles for innovation. Firstly, ensure there’s an environment that can cultivate innovation. Next, don’t treat innovation differently depending on the source. The final two principles I like to think of as one really. You want to innovate with a mission or goal that inspires and is driven by the values your organization embraces.

Please have a safe holiday season, but remember to relax and have a bit of fun too! Follow Dev Leader on social media outlets to get these updates through the week. Thanks!


Charity Water – Weekly Article Dump

My 24th Birthday Wish - Charity: Water

Charity Water

We have a lot of pretty awesome people at Magnet Forensics, and every day I’m reminded just how awesome. A colleague of mine, Danielle Braun, had what I thought was an incredible idea for her birthday. For Danielle’s birthday, she’s not asking for more new clothes, for her parents to get her a car, for help with paying off tuition, or for some new fancy tech gadgets. But she’s not asking for nothing. Danielle is asking for your support with Charity: Water this year.

Charity: Water is a non-profit organization with the goal of bringing clean water to people in developing nations that don’t have access to it. Reading their mission page probably opens your eyes a fair bit about the lack of access to drinking water in other countries. They’re not about some complex and elaborate plan to revolutionize access to clean drinking water. However, they do have a simple and straight forward approach. Donate a little bit of money and they can install wells, rain catchments, and filters in areas without access to clean water. Your small contribution can make a huge impact on other peoples’ lives.

Please consider helping Danielle out with her goal of raising money for clean drinking water. A little bit goes a long way with Charity: Water.

Articles

  • Guest Post: 7 Deadly Sins: How to Successfully “Cross The Chasm” By Avoiding These Mistakes: In Geoffrey Moore’s article, we get to revisit some of the great learnings in Crossing the Chasm. If you haven’t read the book, although it’s a bit old now, it’s still a solid read. This post was a great reminder of a lot of the things the book talks about. It’s important to know where your business sits in the chasm model so that you know what you should be focusing on. Too many companies focus on the right things at the wrong times and have terrible missteps. Check it out (and the original book too)!
  • Holiday Gifts EVERY Employee Secretly Wants: Dharmesh Shah is a guy who always seems to have an awesome perspective to share. There are a few things that despite someone’s level of performance, length of employment, or amount of skill should be deserved.  Often these are overlooked either by grumpy managers or because perhaps the person may not have been a top performer. In Dharmesh’s opinion, that shouldn’t be a factor. The holidays are a perfect time to remind ourselves to recognize all of our employees’ accomplishments and treat them with respect. If you aren’t already, maybe this article is the little wake-up call you need.
  • 6 Things Really Thoughtful Leaders Do: Nothing groundbreaking here, but like the article says, this time of year is great for reflecting. Do you consider yourself a thoughtful leader? Do you observe the people around you, how they interact, and how things are flowing at work? Do you take the time to reflect on things you’ve done, how you’ve acted, or even how employees may have improved in areas you’ve discussed with them? There’s a handful of great reminders in this article that I would suggest you check out!
  • 14 Code Refactoring smells you can easily sense and What you can do about it?:  This week’s first programming article! Except… Well… This one is about the management side of programming. How do you know if your software team’s code is in a real stinky spot? This doesn’t necessarily mean your developers write bad code. It could just mean that you need to hit the brakes a bit and go revisit some problem areas in the code. This article talks about some of the warning signs.
  • What Makes A Good Manager? 7 Things To Ask Before You Promote: Does it make sense to give anyone you’re promoting a management position? Probably not. Seems obvious when you ask it like that, right? The unfortunate truth is that a lot of companies take the simple path and for anyone they want to promote, they throw a management position their way. Some people just don’t make great managers. This article talks about the qualities you want to look for in managers. Maybe the person you’re looking to promote won’t make a good manager *now*, but if it’s something they can put time and effort into building the skills and experience towards, it could still happen.
  • 10 Major Causes for Failure in Leadership: While lists of things to do are always nice, having a list of things to definitely not do is also helpful. Here’s one of them. Some of the leadership-don’ts I liked on this list were being too good to serve your followers, using your “authority”, and fear of competition. I think those are a few that are easy for people to forget, and there at the top of my list of leadership-don’ts. Read some more great points in the article!

Please take some time to help Danielle out with her goal. Any contribution helps. Remember to follow Dev Leader on social media outlets to get these updates through the week. Thanks!

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles


Movember Wrap-up – Weekly Article Dump

Movember Wrap-up - Weekly Article Dump

Movember Wrap-up

At the start of December, it’s time for a lot of us to shave off our glorious Movember badges from our upper lips. This year, MoMagnets did an absolutely amazing job raising money for Movember. At the time of writing, we’re sitting at just under $2400! An incredible effort by Magnet Forensics and all of those that helped with their generous contributions.

My ‘stache didn’t quite get to where I wanted to this year. It was close, but it was another connector-less Movember for me. I was almost able to get some twisting done for some not-so-legitimate connectors. Oh well… Here’s what I ended up rocking for most of the month:

Movember Wrap-up - Nick's Final 'Stache

My final Movember creation: The Anti-Connector.

Matt Chang definitely took the lead for raising the most of all the MoMagnets members at over $700! Mica Sadler is sitting in second at just under $400. That’s nearly half the team’s total between these two beauties. We also had a very gracious contribution from our CEO that I wanted to call out. Thanks so much, Adam!

There’s still a bit of time left before donations are closed for the 2013 Movember season. We have until the 9th to get some final contributions in! If you’re feeling generous, please visit our team page and make a contribution. Every little bit helps, and we greatly appreciate it!

Articles

  • Top 5 Reasons People Love Their Jobs and How You Can Love Yours, Too: Some great points on why people love their jobs. Some of these may be pretty obvious, but it’s important to be reminded about what keeps people engaged. Among the top things: the work culture, the amazing people you get to work with, and autonomy. If you’re trying to create an awesome place to work (or if you’re looking for an awesome place to work) then these are probably things you’ll want to focus on!
  • 5 Things Zapping Your Company’s Productivity: Ilya Pozin always has some interesting articles. This article takes the perspective that some of the fancy perks or awesome processes you have in place may actually be hindering productivity. One common theme that was brought up under two separate points in this article is that sometimes people need a spot where they can work in peace. People like having an fun collaborative culture, but many personality types require some quiet time in order to buckle down.
  • Reduce Your Stress in 2 Minutes a Day: I’m not the type of person that truly believes doing one tiny thing for only a moment every day is going to have an enormous positive impact on your life. However, I do think that if you can take the time to try and do a few little things here and there, that overtime, you’re likely to have more a positive outlook. In this article, Greg McKeown shares a few tips on relaxing and trying to regain some focus. I don’t think it’s anything that’s going to be life-changing, but it never hurts to think about different ways to catch your breath.
  • Building a fast-failure-friendly firm: This was a pretty cool series of slides put together by Eric Tachibana that I thought was worth sharing. There are lot’s of articles on failing and why it’s important–especially for innovating. This series of slides provides a high level perspective on how you can approach failing… the right way!
  • Code Smells – Issue Number 3: This is an article I wrote about Code Smells. This entry talks about the use of exception handlers to guide logical flow in your code and alternatives for when your class hierarchy starts to get too many very light weight classes. As always, I’d love to get your feedback. If you have other code smells, or a different perspective on the ones that I’ve posted, please share them in the comments!
  • 5 Bad Thoughts That Will Throw You Off Track: This short little list is worth a quick read through. There are a ton of things that distract us every day, but the distractions you can easily control are the ones that you cause. Examples? Don’t take on too much at once. Don’t try to make every little thing you do perfect. It’s a quick read, but well worth the reminder!
  • Not Crying Over Old Code: Another programming article for this week. As the article says, the common meme for programming is that your old code is always bad code. However, there should be a point in your programming career where old code isn’t bad, it’s just different than how you might have approached it now. If your always experiencing your old code being bad, then maybe you’re not actually that great at programming yet! Or… maybe you’re just too damn picky.
  • Things I Wish Someone Had Told Me When I Was Learning How to Code: This article by Cecily Carver is something I’ve been hoping to come across for a while now. It’s another programming article–a good read for experienced programmers but incredibly important for newbies to check out. Cecily covers some of the roadblocks you experience early on, like code never (almost never) working the first time, or things you experience throughout your programming career, like always being told of a “better” alternative. I highly recommend you read through this if you dabble in programming, or if you’ve ever considered it.

Please visit our team page for MoMagnets and make a Movember contribution if you’re able to! Remember to follow Dev Leader on social media outlets to get these updates through the week. Thanks!

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles


Code Smells – Issue Number 3

Code Smells – Issue Number 3 (Image by http://www.sxc.hu/)

Code Smells

Welcome to the third edition of Code Smells! Periodically I’ll be posting about how to detect code smells and what they mean in terms of the big picture of your code. The previous installment can be found right here.

What’s a code smell? Wikipedia says it perfectly:

In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs—they are not technically incorrect and don’t currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.

These code smells are often based on my own opinion and experience with programming. If you disagree with what I’m saying in my post, please don’t hesitate to post a comment. I’d love to clarify anything I may have worded poorly and discuss your perspective–especially if you have a completely different take on things!

The Stink List

Code Smell #7: Using exceptions to control logical flow. This is a pretty nasty path to get into and a bad code smell to stumble upon. Luckily, it’s generally relatively easy to improve. Using exception handling to control logical flow is, in general, misleading. It’s relying on a mechanism used to catch unexpected errors in order to direct the flow of your program. Often times we can use things like if statements to check for these conditions before throwing exceptions.

A common scenario where I see this is parsing. I’ll illustrate this code smell with a little C# example:


var input = "This is not a number";
try
{
  var parsed = int.Parse(input);
  DoSuccessfulStuff(parsed);
}
catch (Exception)
{
  DoFailStuff();
}

It seems a bit contrived, but I’ve seen lots of code written like this–and you know what? This works. It gets the job done. However, there are other mechanisms built-in to .NET that let us do parsing a little bit nicer:


var input = "This is not a number";
int parsed;

if (int.TryParse(input, out parsed))
{
  DoSuccessfulStuff(parsed);
}
else
{
  DoFailStuff();
}

The second set of code doesn’t need to catch exceptions to know that the parsing wasn’t successful. It may not be obvious from this example but throwing and catching exceptions can be quite expensive compared to a few logical sanity checks instead (and before getting into a debate on this, just know the impact it has on your program. I’ve had things go from taking several seconds to multiple minutes, but there are certainly cases where performance will be negligible).

The additional kicker in my contrived example is using the base Exception class to create what a colleague of mine refers to as Pokemon Exception Handlers. Thus, even if you didn’t want to restructure your code, using a specific exception type would:

  • Indicate to other programmers what you’re trying to accomplish
  • Not swallow other potential problems and have them go unseen

Now, this code smell isn’t always possible to avoid entirely. If you’re interfacing with third party components, sometimes you do have to rely on catching exceptions that you can’t otherwise check for ahead of time. If you don’t have the code, you can’t know for every path how/when/why exceptions will be thrown. The same thing could be said when running within an environment where state cannot be guaranteed. Sometimes it’s just necessary. In this case, I would suggest that instead of using Pokemon Exception Handlers, you try to catch the specific exceptions you know you need to watch out for.

Takeaway:

  • If a simple logic check can be used instead of throwing/catching exceptions, it’s likely a better bet.
  • Try to avoid exception handlers that catch all exceptions. Something nasty might sneak by as a result of it.
  • Interfacing with some code or working working in certain environments means you have to rely on exception logic. Take a deep breath and move on.

Code Smell #8: Having an object hierarchy that requires many very light weight classes. Object oriented programming and how object hierarchies are structured are pretty complicated topics of discussion, so I’m not about to try and over simplify it with discussion of this code smell. This is mostly something I’ve gathered from my own programming experience, so I’ll try to illustrate with examples that parallel things I would have come across.

When I’m building an object hierarchy, sometimes it’s not really apparent just how big and complicated it might get. I might start off with a base class and two child classes of it. Over time, the top three levels in my hierarchy have all turned into some sort of class abstraction, and I don’t hit concrete implementations until a few levels down hte hierarchy. Not a big deal–Sometimes it’s just hard to tell where things will go. When things get to the point where in order to introduce a new class and functionality all I need to do is inherit a class and override a single property or method, that’s a bit of a red flag for me.

On the surface, this seems pretty cool. The hierarchy is apparently solidified enough that extending it is really simple if all I need is a single property or method replacement. So why is this a code smell?

In my opinion, it has to do with the duplication of code. If I end up having many child classes (where child in this case represents the child-most class of my mature object hierarchy) that differ only by a single property or method, then I should look at how these classes are being constructed. I wrote recently about how I used lambda expressions to refactor similar code with classes that differed by a single method. My solution, in this case, was to examine the factory that created my classes. Instead of having 10’s of different child classes with a bunch of boilerplate code, I had one factory that could specify the code that differentiated each class.

The benefit of this?

  • Keep class hierarchies from ballooning our of control. Changing an API down the road can mean making changes in many spots.
  • Reduce duplication of boilerplate code. This might be the code required to define a simple constructor or override a getter property.

This is only one small example, but if you get into this situation in your class hierarchy, I’d recommend investigating to see if you can refactor in a similar approach. Maybe your class hierarchy is incredibly mature and isn’t changing much. If that’s the case, you may not even want to touch it. So be it. If you’re still actively adding classes to your hierarchy, it may be better to try analyzing it sooner rather than later.

Takeaway:

  • Object oriented design is a complex topic of discussion.
  • There’s no one perfect way to make your class hierarchies.
  • Having many child classes that differ by a property/method or two may be worth checking for refactoring opportunities.

Summary

I hope you enjoyed this issue of Code Smells. As always, it’d be great to open the floor to discussion. I don’t believe in absolutes, so identifying code smells is not meant to be me preaching some made up laws of programming. Let me know your thoughts on these code smells or share code smells of your own!


Performance Reviews – Weekly Article Dump

Performance Reviews - Weekly Article Dump (Image by http://www.sxc.hu/)

Performance Reviews

It’s almost the end of the year, and performance reviews for many companies are just around the corner. This will be the first time for me sitting on the other side of a performance review. I’m excited, and to be honest, a little nervous about how it will all play out. I know our HR manager has done an excellent job putting together our initial take on performance reviews, but it’s still going to be up to me to ensure that all aspects of a performance review are communicated properly to my team. It’s definitely going to be an interesting time of year!

I’ve started doing a little bit of reading on performance reviews. From what I can tell, the general consensus is that most performance review systems are flawed and nobody knows the perfect way to do them. That’s kind of scary actually. So, like anything, I started questioning all the aspects of performance reviews that I can think of. So things like: What’s stack ranking? Why do companies stack rank? What are alternatives? What about leveraging teammate-driven reviews? etc… There’s a whole lot for me to learn, so I need to start by questioning everything.

With that said, how do you do performance reviews? Have performance reviews been working at your organization? Do you stick to “the norm”, or do you have your own interesting spin on performance reviews that make them effective for your organization?

Articles

  • Employee retention is not just about pizza lunches and parties: On the surface, things like candy stashes, catered lunch, and all other shiny perks seem like a great way to get and keep employees. However, keeping employees engaged is the sum of what attracts them to the company and what keeps them motivated while they’re working. Recognizing their accomplishments and giving them challenging and meaningful work is an awesome start.
  • 7 Reasons Your Coworkers Hate You: The truth? You probably know at least one person at work who does at least one of the things on this list. The harder truth? You probably do one of these yourself. It’s a pretty cool list put together by Ilya Pozin. I’d suggest a quick look!
  • How To Inspire Your Team on a Daily Basis: In this article by James Caan, he echoes one of the things I wrote about recently. You can’t expect to have a motivated team unless you lead by example. You really shouldn’t expect anything from your tea unless you are going the lengths to demonstrate that your dedication to the team and the team’s goal.
  • humility = high performance and effective leadership: Michelle Smith write about how humility is actually a great leadership characteristic. A couple of the top points in her article include not trying to obtain your own publicity and acknowledge the things you don’t know. The most important, in my opinion, is promoting a spirit of service. You lead because you are trying to provide the team guidance and ensure every team member can work effectively.
  • The Surprising Reason To Set Extremely Short Deadlines: This one might not be the same for all people. I think that anyone that tries to apply this as a blanket statement is probably setting themselves up for failure. How do you feel about short deadlines? Some people tend to work really well under pressure and having short deadlines. For those that do, this article offers a perspective on why. Under pressure, you operate creatively given your restricted set of resources, and you don’t have time to dawdle and let things veer of track. Interesting to read.
  • Eliciting the Truth: Team Culture Surveys: Gary Swart talks about something I think is extremely important for all businesses. Maybe your work culture is established, but where did it come from? It’s easy for people to get together in a room and say “we want to have a culture that looks like X”. It’s harder to actually have the culture you say you want. Gary suggests you do a culture survey to actually see what your work culture is like because… well, who knows better? A few people sitting together in a room, or everyone in the company?
  • You Are Not a Number: With year-end performance reviews and the like coming up, I thought it would be interesting to share this short article by Dara Khosrowshahi. Do you stick to stack ranking? Do you have in-depth conversations with employees about their performance? Have you tried switching things up because the canned approach just wasn’t delivering?
  • Which Leads to More Success, Reward or Encouragement?: Deepak Chopra analyzes the positives and negatives of using rewards and using encouragement as a means of driving success. The takeaway from Deepak’s article is that using rewards is not a sustainable means to motivate your team, and actually tends to create separation within the team. By leveraging encouragement, you can empower your team to work together and self-motivate.

Remember to follow Dev Leader on social media outlets to get these updates through the week.

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles


Deloitte Companies to Watch – Weekly Article Dump

Deloitte Companies to Watch - Weekly Article Dump

Deloitte Companies to Watch

Another impressive accolade for Magnet Forensics! Deloitte has placed Magnet on their top 10 companies to watch list! To qualify for the list, the companies need to be operating for less than five years, be based out of Canada, and put a large portion of their revenue to generating intellectual property. Our CEO, Adam Belsher, had this to say about the award:

“We are honoured to be named one of Deloitte’s Companies-to-Watch. This award recognizes the hard work and dedication of our team. We’re thankful for the success we’ve achieved, and we’re incredibly proud to be contributing to the important work done by our customers who use our solutions to fight crime, enhance public safety, protect companies from fraud and theft, and ensure workplace safety and respect for their employees.”

Magnet Forensics Press & Events

The event was put together very well. It was great to be able to interact with individuals from the other companies and share success stories. I even had a chance to meet up with Stephen Lake of Thalmic Labs and have a good chat with him. I’m going to name-drop him everywhere I go because he’s my old university room/house mate! He also happens to be a incredible person that if you have the chance to meet, you absolutely should. Here’s some coverage on twitter of us talking with our founder Jad Saliba:

We enjoyed the whole night, and we were grateful for Deloitte putting on the event. The entire Magnet team is very proud of our achievements.

Articles

  • What comes first: employee engagement or great work?: A short but interesting article on employee engagement. The author claims that most employees probably start of at their position very motivated and engaged. Over time, an employees engagement drops if their leaders are not proactive in keeping their engagement levels up. By proactively acknowledging the success of your employees, you can keep your team engaged and producing great work.
  • Great Leadership Starts and Ends with This: Jeff Haden put together this quick little article about an answer an audience member gave about what the key to leading people is. Caring. Overly simplified? Well, the individual went on to say that regardless of all of your strategies, plans, and experience, if you can’t prove that you truly care about your team then they aren’t going to buy in. I’m never one to buy into something so absolute, but the takeaway for me is that team members cannot be looked at entirely as resources. Sure, the people on your team affect productivity and in that sense are resources, but forgetting to acknowledge the human side of things is a recipe for failure.
  • 9 Ways to Win Employee Trust: In his article, Geoffrey James put together a great list of nine things to help build trust with your team. I wouldn’t say these are groundbreaking things, but it’s important to be reminded about them. Try reflecting on his list and seeing if you actually do the things you think you do. You might be surprised. Some of the top things on the list for me are ensuring employees’ success is number one on your priorities, listen more than you talk, and walk the walk. Great list!
  • Lambdas: An Example in Refactoring Code: I put out this programming article earlier this week and had some great feedback. In this article, I talk about a real world example of how using lambda expressions in C# really helped when refactoring a piece of code. Some people have never heard of lambdas, and some people seem to hate them. In this case for me, it greatly simplified a set of code and reduced a bunch of extra classes. I definitely owe it to myself to start investigating them a little bit more.
  • Executive Coaching: Bringing Out Greater Leadership: This article is all about taking charge with your leadership. Judith Sherven talks about executive coaching for leaders, but the main points I see in here are around confidence. If you aren’t confident in your ability to lead, motivate, and inspire how can you expect anyone else to be? It ends up becoming a tough balance, because you need to listen and take feedback from your team, but when you make decisions you should do so with confidence.
  • Stop Worrying About Making the Right Decision: Ever heard of paralysis by analysis? This article does a great job of explaining why you shouldn’t let that creep in to your leadership approach. It’s important to make good decisions–there’s no doubt about that. But the reality is that no matter what decision you make, there are certain unknowns that can creep in and potentially have a huge effect on the choices you’ve made. So what’s more important: making the perfect decision, or being able to adapt effectively?
  • Appraising Performance Appraisal: Steven Sinofsky‘s article is a bit of a beast, but it’s a great starting point if you’re reconsidering performance appraisals. Even if you’re totally content with your performance review system, it might be worth reading to spark some ideas. Steven does a great job of pointing out some common pitfalls of typical performance appraisal systems and comments on some things you really need to try and understand before sticking to any one system. I’m not well enough versed in the performance review and/or human resources side of things, but this article certainly has enough to get you questioning the common approaches.
  • Tab Fragment Tutorial: Shameless plug for my Android application that I put out on the Google Play store. It’s the end result of the tutorial I wrote up over here. I think it’s going to blow past my legitimate application for converting units!
  • Does a Good Leader Have To Be Tough?: Deepak Chopra has some seriously great articles. In this article, he analyzes the pros and cons of being a “tough” leader. In short, there are positive takeaways from being a tough leader, but there are a lot of negative aspects to it. Deepak suggests you consider a different approach from tough-soft leadership. By focusing on a hierarchy of needs to be a successful leader, toughness is only one aspect of leadership. A pretty solid read, like all of Deepak’s articles.

Remember to follow Dev Leader on social media outlets to get these updates through the week.

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles


  • 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