IronPython: A Quick WinForms Introduction

IronPython: A Quick WinForms Introduction

Background

A few months ago I wrote up an article on using PyTools, Visual Studio, and Python all together. I received some much appreciated positive feedback for it, but really for me it was about exploring. I had dabbled with Python a few years back and hadn’t really touched it much since. I spend the bulk of my programming time in Visual Studio, so it was a great opportunity to try and bridge that gap.

I had an individual contact me via the Dev Leader Facebook group that had come across my original article. However, he wanted a little bit more out of it. Since I had my initial exploring out of the way, I figured it was probably worth trying to come up with a semi-useful example. I could get two birds with one stone here–Help out at least one person, and get another blog post written up!

The request was really around taking the output from a Python script and being able to display it in a WinForm application. I took it one step further and created an application that either lets you choose a Python script from your file system or let you type in a basic script directly on the form. There isn’t any fancy editor tools on the form, but someone could easily take this application and extend it into a little Python editor if they wanted to.

Leveraging IronPython

In my original PyTools article, I mention how to get IronPython installed into your Visual Studio project. In Visual Studio 2012 (and likely a very similar approach for other versions of Visual Studio), the following steps should get you setup with IronPython in your project:

  • Open an existing project or start a new one.
  • Make sure your project is set to be at least .NET 4.0
    • Right click on the project within your solution explorer and select “Properties”
    • Switch to the “Application” tab.
    • Under “Target framework”, select  “.NET Framework 4.0″.
  • Right click on the project within your solution explorer and select “Manage NuGet Packages…”.
  • In the “Search Online” text field on the top right, search for “IronPython”.
  • Select “IronPython” from within the search results and press the “Install” button.
  • Follow the instructions, and you should be good to go!

Now that we have IronPython in a project, we’ll need to actually look at some code that gets us up and running with executing Python code from within C#. If you followed my original post, you’ll know that it’s pretty simple:


var py = Python.CreateEngine();
py.Execute("your python code here");

And there you have it. If it seems easy, that’s because it is. But what about the part about getting the output from Python? What if I wanted to print something to the console in Python and see what it spits out? After all, that’s the goal I was setting out to accomplish with this article. If you try the following code, you’ll notice you see a whole lot of nothing:


var py = Python.CreateEngine();
py.Execute("print('I wish I could see this in the console...')");

What gives? How are we supposed to see the output from IronPython? Well, it all has to do with setting the output Stream of the IronPython engine. It has a nice little method for letting you specify what stream to output to:


var py = Python.CreateEngine();
py.Runtime.IO.SetOutput(yourStreamInstanceHere);

In this example, I wanted to output the stream directly into my own TextBox. To accomplish this, I wrote up my own little stream wrapper that takes in a TextBox and appends the stream contents directly to the Text property of the TextBox. Here’s what my stream implementation looks like:


private class ScriptOutputStream : Stream
{
  #region Fields
  private readonly TextBox _control;
  #endregion

  #region Constructors
  public ScriptOutputStream(TextBox control)
  {
    _control = control;
  }
  #endregion

  #region Properties
  public override bool CanRead
  {
    get { return false; }
  }

  public override bool CanSeek
  {
    get { return false; }
  }

  public override bool CanWrite
  {
    get { return true; }
  }

  public override long Length
  {
    get { throw new NotImplementedException(); }
  }

  public override long Position
  {
    get { throw new NotImplementedException(); }
    set { throw new NotImplementedException(); }
  }
  #endregion

  #region Exposed Members
  public override void Flush()
  {
  }

  public override int Read(byte[] buffer, int offset, int count)
  {
    throw new NotImplementedException();
  }

  public override long Seek(long offset, SeekOrigin origin)
  {
    throw new NotImplementedException();
  }

  public override void SetLength(long value)
  {
    throw new NotImplementedException();
  }

  public override void Write(byte[] buffer, int offset, int count)
  {
    _control.Text += Encoding.GetEncoding(1252).GetString(buffer, offset, count);
  }
  #endregion
}

Now while this isn’t pretty, it serves one purpose: Use the stream API to allow binary data to be appended to a TextBox. The magic is happening inside of the Write() method where I take the binary data that IronPython will be providing to us, convert it to a string via code page 1252 encoding, and then append that directly to the control’s Text property. In order to use this, we just need to set it up on our IronPython engine:


var py = Python.CreateEngine();
py.Runtime.IO.SetOutput(new ScriptOutputStream(txtYourTextBoxInstance), Encoding.GetEncoding(1252));

Now, any time you output to the console in IronPython you’ll get your console output directly in your TextBox! The ScriptOutputStream implementation and calling SetOutput() are really the key points in getting output from IronPython.

The Application at a Glance

I wanted to take this example a little bit further than the initial request. I didn’t just want to show that I could take the IronPython output and put it in a form control, I wanted to demonstrate being able to pick the Python code to run too!

Firstly, you’re able to browse for Python scripts using the default radio button. Just type in the path to your script or use the browse button:

IronPython - Run script from file

Enter a path or browse for your script. Press “Run Script” to see the output of your script in the bottom TextBox.

Next, press “Run Script”, and you’re off! This simply uses a StreamReader to get the contents of the file and then once in the contents are stored in a string, they are passed into the IronPython engine’s Execute() method. As you might have guessed, my “helloworld.py” script just contains a single line that prints out “Hello, World!”. Nothing too fancy in there!

Let’s try running a script that we type into the input TextBox instead. There’s some basic error handling so if your script doesn’t execute, I’ll print out the exception and the stack trace to go along with it. In this case, I tried executing a Python script that was just “asd”. Clearly, this is invalid and shouldn’t run:

python_error_asd

Python interpreted the input we provided but, as expected, could not find a definition for “asd”.

That should be along the lines of what we expected–The script isn’t valid, and IronPython tells us why. What other errors can we see? Well, the IronPython engine will also let you know if you have bad syntax:

python_error_bad_syntax

Python interpreted the script, but found a syntax error in our silly input.

Finally, if we want to see some working Python we can do some console printing. Let’s try a little HelloWorld-esque script:

python_pass_hello_world

Python interpreted our simple Hello World script.

Summary

This sample was pretty short but that just demonstrates how easy it is! Passing in a script from C# into the IronPython is straight forward, but getting the output from IronPython is a bit trickier. If you’re not familiar with the different parts of the IronPython engine, it can be difficult to find the things you need to get this working. With a simple custom stream implementation we’re able to get the output from IronPython easily. All we had to do was create our own stream implementation and pass it into the SetOutput() method that’s available via the IronPython engine class. Now we can easily hook the output of our Python scripts!

As always, all of the source for you to try this out is available online:

Some next steps might include:

  • Creating your own Python IDE. Figure out some nice text-editing features and you can run Python scripts right from your application.
  • Creating a test script dashboard. Do you write test scripts for other applications in Python? Why not have a dashboard that can report on the results of these scripts?
  • Add in some game scripting! Sure, you could have done this with IronPython alone, but maybe now you can skip the WinForms part of this and just make your own stream wrapper for getting script output. Cook up some simple scripts in a scripting engine and voila! You can easily pass information into Python and get the results back out.

Let me know in the comments if you come up with some other cool ideas for how you can leverage this!


Happy St. Patty’s Day – Weekly Article Dump

Happy St. Patty's Day - Weekly Article Dump (Image by http://www.sxc.hu/)

Happy St. Patty’s Day!

I hope everyone who was celebrating St. Patrick’s Day was able to not only have fun but stay safe doing so. Of course, when there is drinking associated with a holiday it can be easy to get carried away. It’s always a great idea to have driving arrangements or the option to sleep at a friend’s place set up before you head out to celebrate.

This year I was able to celebrate with a handful of my university friends that I don’t get to see as often as I’d like. I haven’t been drinking much at all now for nearly half a year, so I stuck to my one Irish coffee to meet my liquor allowance. We all had a blast discussing where our lives have taken us so far, and it’s great to see everyone doing so well. I was excited to hear that more people are hoping to relocate into or closer to Waterloo!

Happy (belated) St. Patty’s Day everyone, and I hope the recovery has gone smoothly today.

Articles

  • Empower Your Visionaries: Steve Faktor talks to us about who the visionaries are in your company and why you should be empowering them. Steve says that the visionaries within our organizations are frustrated by bureaucracy and will often leave to go start their own Next-Big-Thing. So what should we be doing with them? What can we do with them? Well… challenge them! Challenge them to make their radical ideas a reality. Extend the boundaries you’ve placed on them so that they can try to make their vision a reality and make them feel comfortable with the possibility of failure. Wouldn’t it be great if they’re next big thing was the next big thing for your organization?
  • Don’t Forget Me! Ensuring Distributed Team Members Aren’t Left Out: In this article, Gary Swart touches on how to make sure remote employees are kept engaged. Working remotely can be difficult not only for the person offsite, but for the people that are supposed to interface with the person offsite. Timezone differences, cultural differences (i.e. different holidays, for example), and the fact that you can’t interact in person are all things that make remote team members a lot trickier to work with. Gary suggests using the ICE (Identify, Clarify, and Extend) principle, which he outlines in his post. He also suggests using things like video conferencing so that you can pick up more on body language when you’re meeting remotely and even ensuring that you try to keep your technology homogeneous so that information can be shared easily.
  • Inspire Creativity at Work With All 5 of Your Senses: A good friend of mine shared this with me the other day, and I thought it was worth passing along. Many people don’t pay attention to it, but if you work a traditional office job, you spend a lot of time in the office. Even if you can get a little boost from your environment, it can potentially go a long way over time. This mashable is an infographic about how different colors and ambience in the office can be used to enhance (or restrict) different aspects of your thinking and interaction. If your work environment isn’t playing into your senses, you may be missing out on a positive effect!
  • Great leaders aren’t afraid to take risks: According to Alex Malley, risk taking is a very important part of leadership. He has a handful of suggestions for gearing yourself up for taking risks in your leadership role such as separating the personal aspect of failure from your role. If you’ve set yourself up with talented people, you have open communication with your manager, and you’re prepared for the “worst case”, then you should feel more comfortable taking risks.
  • The complete guide to listening to music at work: I’ve personally given up on listening to music at work during core hours due to the nature of my role (I’ve been told this is “humblebragging“, but realistically I’m just making myself more approachable). However, when I’m cranking through some development work on my own and I know I’m not going to be approached by anyone, I love to turn up some tunes. I thought Adam Pasick had a pretty cool write up about the different aspects of listening to music at work. Essentially, different styles of music may be better for different tasks at work.  I think it’s worth a read if one of the first things you do when you get into the office is strap on your headphones!

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


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!


Swamped But Ready To Push Forward

Swamped But Ready To Push Forward (Image by http://www.sxc.hu/)

Mini Update

Just thought I’d get a quick one out there to say I’m still here. To be honest, I haven’t kept up to speed with my weekly updates or even sharing articles on social media like I try to do on a regular basis. But that’s just how life has been the past few weeks, and there’s no sense beating myself up over it. Time to acknowledge it, and time to push forward.

Work has kept me swamped with things to do. I’ve been busier than normal the past few weeks and it’s largely due to things going on at work. But I’m not complaining. I actually prefer times at work when I feel nearly overwhelmed. The added pressure (whether artificially inflated by my own doing or not) really helps me buckle down and become productive. It’s a great feeling to be able to reflect on a week’s worth of work and know that a lot got done. It’s even better to see the culmination of your work after several months and how far it’s come. If work weren’t enjoyable, I’m sure I’d have a completely different take on this one!

I’ve noticed that my post on creating a tabbed Android user interface has still kept up with a ton of traffic. I’m actually getting some private requests for help outside of public forums regarding this post, and I’ve been falling a bit behind on those too. It’s great to see people are actually benefiting from this blog post though!

What I’ve Been Doing

Not blogging. But you already knew that!

Well I mentioned work has been pretty busy. Magnet Forensics has launched another update to Internet Evidence Finder, so we’re now on version 6.3 of the product. Even though our process for launching a new release has come a long way, there’s still a ton of extra work and stress that comes with any release. Any potential bug that shows its face has to be closely considered for whether or not it should block the software from being released. Any odd behaviour with the application needs to be acknowledged and documented if it won’t be fixed for the release–So if customers contact us, our tech support can easily guide them through workarounds. Of course while that’s happening, the development team is already hashing out how to solve it for the next release.

There’s a lot involved for a release. It’s hectic but it’s exciting. Reflecting on everything that went into the latest release of our software, I’m still amazed. Every time we put out a new version we always make the previous release seem like it was a minor update. I’m extremely proud of the development team at Magnet for being able to rally and put together an awesome product, and of everyone at Magnet for being able to have an awesome version launch.

Thanks Team Magnet!

What’s Around The Corner

So I had actually started on a few things–I swear. I just didn’t get around to finishing them:

  • I have a recognition blog post I want to rework and get put out. This one is long overdue, but it’s near completion.
  • Two assorted leadership/startup-esque blog posts are in the works. These ones still need a ton of work.
  • My leadership blueprint blog post! I mentioned a while back now that I wanted to do a post on this, but I haven’t started yet. I’m really looking forward to this one.
  • Actually posting and sharing on social media again. Sorry!
  • Weekly article dumps. Again, once I start sharing, I can get back on track with these!

There’s a whole lot on the way!


Article Dump #24 – Weekly Article Dump

Article Dump #24 - Dev Leader (Image by http://www.sxc.hu)

Article Dump #24

Welcome to the 24th issue of my (nearly) weekly article dumps. I don’t have a theme or an update this week, so it’s kept pretty short. I hope you find the following articles interesting though! Leave me a comment if you have any opinions on these

Articles

  • The 7 Values That Drive IDEO: In this article, the CEO of IDEO Tim Brown talks about the various values that his organization embraces to have a creative culture. Some of the ideas in the slides seem really high level or like generic fluff, but try thinking about what they would mean in your organization. It’s one thing to glance at IDEO’s list and say “Yeah, yeah… That’s nice…” but when you actually think about how that fits in with your organization, you might actually realize you don’t embody those values. Do you learn from failure? Does your organization promote an ask for forgiveness not permission approach? Would this make sense in your organization? Just some food for thought, but I thought a lot of these values were interesting to think about and how embracing them might change the organization I work in.
  • The 15 Most Annoying Coworkers of All Time: Ilya Pozin put together a pretty funny article on different types of coworkers you’ll encounter in your career. I got worried that I might be #13 on the list… The office comedian who isn’t actually funny. Apparently this post got a lot of flack in the comments on LinkedIn. I guess people were expecting a really serious article on how to deal with these different types of problems in the workplace. I didn’t really have expectations when I read it, aside from not wanting to find myself on the list. Maybe the main take away point here is… don’t annoy your colleagues!
  • Companies Frustrate Innovative Employees: Gijs van Wulfen takes a different perspective on innovation. So many people now are writing about embracing failure (so far as you learn from it). I’m actually a big believer in that approach–take controlled risks and learn from things that don’t go as expected. Gijs’ perspective is a little bit different: forget embracing failure; boost the innovation effectiveness rate! Gijs goes through a workflow for trying to improve innovation at various steps in the process. Pretty interesting!
  • Your Boss is Happier Than You (But Shouldn’t Be): Jeff Haden tells us something we probably all (let’s say in the majority of circumstances) know: your boss is happier than you. Big surprise right? They get to make decisions, have fewer bosses than you, and they make more money. Sounds like a good reason to be happier, no? But if your boss is happier than you, those probably aren’t the exact reasons. Your superiors are likely happier than you because of autonomy. They get a bit more freedom to do accomplish goals in their own way. Jeff has a big list of reasons why your boss is probably happier… and none of them are about money.
  • When is it a Good Idea to write Bad Code?: Rejoice in the first programming article for this week! Tech debt. Ever heard of it? If not, it’s not likely that you’ve never encountered it in your programming career. I’d wager at least one of the last handful of big features you implemented in your code base either had to deal with some tech debt or perhaps even introduced some tech debt. Brad Carleton has put together a big list of different types of tech debt and what they mean in your project. I highly suggest you read it if your a programmer. There’s a lot of things to be aware of with tech debt but it’s important to remember that tech debt isn’t always the worst thing that could happen. Sometimes it’s okay to sacrifice a sub-par design now in order to get some software out the door. Your users might try it out and decide they don’t like the functionality anyway, and you’d end up re-writing it again!
  • “Happiness” vs “Meaningfulness” — The Surprising DifferenceAlex Banayan‘s article discusses the difference between happiness and meaningfulness. It appears as though often happiness and meaningfulness are not necessarily aligned. For example, it might be easy to chase a life of happiness that lacks meaning, or dedicate your life to something meaningful but not be very happy while doing it. The real question is, is it possible to achieve a balance where you’re leading a fulfilling life that keeps you happy? Alex talks briefly about five different categories and how each can sway to something more meaningful or something that provides more happiness. Are you living a happy and fulfilling life? Do you have to balance these five categories carefully?

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


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


  • 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